Tim Peters added the comment:
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
bumpserialno(void)
{
++serialno;
}
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.
----------
_______________________________________
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
