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, tim.peters, vstinner
Date 2013-08-26.20:09:19
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1377547759.37.0.539601032578.issue18843@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2013-08-26 20:09:19tim.peterssetrecipients: + tim.peters, amaury.forgeotdarc, mmokrejs, vstinner
2013-08-26 20:09:19tim.peterssetmessageid: <1377547759.37.0.539601032578.issue18843@psf.upfronthosting.co.za>
2013-08-26 20:09:19tim.peterslinkissue18843 messages
2013-08-26 20:09:19tim.peterscreate