Tim Peters added the comment:
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.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue18843>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
