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.23:33:19
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Well, if you delete a giant list, and the list held the only references remaining to the objects the list contained, then the memory for those objects will be free'd, one object at a time.  A debug build would then detect the memory corruption in those objects.  But the corruption has nothing to do with deleting the list then - deleting the list would merely trigger the code that _detects_ the (pre-existing) corruption.

I can just urge you again to try to find a failing test as small and fast as possible.  You feel lost now precisely because you're wandering through a _mountain_ of code ;-)

If you want to play with the debug serial numbers, you can set a breakpoint in function bumpserialno() (in Python's Objects/obmalloc.c).  This is the entire function:

static void

The function exists so you _can_ easily set a breakpoint whenever `serialno` is increased (this function is the only place serialno is changed).

What I _expect_ you'll find is that serialno never gets anywhere near 8155854715.  If so, that just says again that the copy of serialno made when the corrupted object was created got corrupted (overwritten) by some bad C (or C++) code.  It can't tell us who overwrote it, or when.
Date User Action Args
2013-08-26 23:33:20tim.peterssetrecipients: + tim.peters, amaury.forgeotdarc, mmokrejs, vstinner
2013-08-26 23:33:19tim.peterssetmessageid: <>
2013-08-26 23:33:19tim.peterslinkissue18843 messages
2013-08-26 23:33:19tim.peterscreate