Tim Peters added the comment:

Memory corruption can be difficult to track down.  Best thing you can do is 
strive to find a test case as small and fast as possible that shows the same 
kind of error.

By "rogue extension module" I just mean 3rd-party C code (like, for example, 
matplotlib).

I doubt it's a hardware problem.  That's possible, of course, but these kinds 
of errors are almost always the result of errors in C code.

The stacktrace probably isn't helpful.  All we know is that memory got 
corrupted _sometime_ between someone asking for a block of memory and releasing 
it.  The corruption may have happened a millisecond ago, or weeks ago (if the 
program ran that long) - there's no way to tell by the time the memory 
corruption is _detected_.

About "object counter overflows", I'm not sure what you're asking.  Python 
doesn't have an object counter.  The "serial number" in debug-mode allocators 
just counts the number of times a debug-mode malloc has been called.  If that 
overflows, it would do no harm.

Bottom line:  no matter what's to blame here, the smaller & faster a test 
program you can find, the more likely it is to get fixed.

----------

_______________________________________
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

Reply via email to