This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author tim.peters
Recipients amaury.forgeotdarc, mmokrejs, neologix, pitrou, sjt, skrah, tim.peters, vstinner
Date 2013-08-31.17:36:18
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Someone may find the new stress.valgrind.stderr interesting, but - since I've never used valgrind - it doesn't mean much to me.

I _expected_ you'd run the little stress program under a debug Python and without valgrind, since that's the only combination you've tried so far that showed a definite problem ("pad leading pad byte" death, or the segfault in the other issue you filed).

But it doesn't much matter - this is all just thrashing at random, yes?  You need to find a reproducible test case, and/or try different hardware.  The little stress program may or may not provoke an error under a debug-build Python, and may or may not require increasing N (to consume more RAM).

If it does provoke an error, the next thing to try would be to write a little program that just writes 0xfb across a massive number of bytes, and then reads them all to verify they're still 0xfb.  Or write one like that now, and preferably in C (it may matter how quickly the bytes are written - and it may not matter).  But at this point youj're starting to write your own memory-testing program.

In any case, there's really no evidence of an error in Python so far.  Yes, Python has _detected_ a problem in some cases.  But without a reproducible test case, I don't see that there's anything more we can do for you on our end - sorry.
Date User Action Args
2013-08-31 17:36:18tim.peterssetrecipients: + tim.peters, amaury.forgeotdarc, mmokrejs, pitrou, vstinner, sjt, skrah, neologix
2013-08-31 17:36:18tim.peterssetmessageid: <>
2013-08-31 17:36:18tim.peterslinkissue18843 messages
2013-08-31 17:36:18tim.peterscreate