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
Date 2013-08-26.18:04:14
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1377540255.36.0.728535437202.issue18843@psf.upfronthosting.co.za>
In-reply-to
Content
Python's debug-mode memory allocators add some "magic values" before and after each allocated chunk of memory, and check them when the chunk is freed to make sure nobody overwrote them.  In this case, someone did overwrite the byte at p-5, where p is the address of the block originally returned to the requesting program code.

It's also suspicious that it says this block was originally allocated by the 8,155,854,715th call to a debug allocation routine:  is it plausible that you (for example) allocated over 8 billion objects?  This "serial number" is also stored in bytes adjacent to (and after) the allocated block, so is also vulnerable to out-of-bounds stores by rogue code.

So we have out-of-bounds stores here both before and after the requested memory.  Sorry, but it's unlikely core Python is doing this - such errors are usually due to rogue extension modules.
History
Date User Action Args
2013-08-26 18:04:15tim.peterssetrecipients: + tim.peters, amaury.forgeotdarc, mmokrejs
2013-08-26 18:04:15tim.peterssetmessageid: <1377540255.36.0.728535437202.issue18843@psf.upfronthosting.co.za>
2013-08-26 18:04:15tim.peterslinkissue18843 messages
2013-08-26 18:04:14tim.peterscreate