visual C++ giving runtime heap-check error in Py_Finalize(x)

[Warren Postma]

I have managed to get a repeatable (on my machine) version of either a
reference count or other related kind of nasty bug in my embedded C++
application when I call Py_Finalize.

The error I get is when trying to malloc some memory for a new object, the
malloc call senses corruption of a previously freed block of memory, after
the time it was last freed. here is the trace message that is printed out to
the visual C++ output window:

I get the following call stack:

NTDLL! 77f9f9df()
NTDLL! 77fcc8a1()
NTDLL! 77f87aa3()
NTDLL! 77fb3c33()
NTDLL! 77fa7131()
NTDLL! 77fca4cb()
_free_base(void * 0x005d8a40) line 96
_free_dbg_lk(void * 0x005d8a60, int 0x00000001) line 1116 + 9 bytes
_free_dbg(void * 0x005d8a60, int 0x00000001) line 1001 + 13 bytes
free(void * 0x005d8a60) line 956 + 11 bytes
string_dealloc() line 175 + 9 bytes
PyString_Fini() line 1112 + 88 bytes
Py_Finalize() line 242

What is happening is this:

In PyString_Fini it is freeing the set of characters 0 to 255. When freeing
character[17] I trace in, and it is calling  the standard C method "free()"
to release PyObject characters[17] which is the PyObject (string) memory at
0x5d8a90.    As you can see above, some pointer mangling ends up happening.

The reference count for the PyObject is 1 already, and the object itself
does not appear to be corrupt.  I added the line char *c =
PyString_FromString( characters[i] ); just to see if I could still get the
character values out of the strings, and they are all still there, and this
string does not appear corrupt in any way but the heap debug code prints
this warning and throws a debug exception:

HEAP[myprogram.exe]: HEAP: Free Heap block 5d8a90 modified at 5d8ab8 after
it was freed

The funny thing is that there are no other threads in there, so if anything
is modifying anything, then it's the malloc() code itself doing it.

Has anybody else had a problem like this ever?

Trick is, it does this both with my custom (statically linked) Python 1.5.2
and with the python15.dll also, so it's either (a) a bug in my code
somewhere, probably one of my C extensions somewhere or (b) something weird
in Python itself, which my code is causing to happen, but which is
definitely a bug in 1.5.2.  I am leaning towards (A) because it is 99.9999%
of the time always my fault! :-)

Warren Postma