BUG? PyMem_Free vs strdup

[Robin Becker]

I am trying a debugging version of Python 2.3 under win32. In my
extension I am getting a memory checking debug interrupt when attempting
to free a string that was allocated using strdup.

Upon inspection I find that there are check bytes both before and after
the allocated memory, but these aren't those needed by the PyMem_Free
routine in debug mode.

the storage is allocated and freed thusly

s = strdup(PyString_AsString(v)); 
.....
PyMem_Free(s);

I see this from the Python checking
Debug memory block at address p=00A02458:
    2836660224 bytes originally requested
    The 4 pad bytes at p-4 are not all FORBIDDENBYTE (0xfb):
        at p-4: 0xfd *** OUCH
        at p-3: 0xfd *** OUCH
        at p-2: 0xfd *** OUCH
        at p-1: 0xfd *** OUCH
    Because memory is corrupted at the start, the count of bytes
requested
       may be bogus, and checking the trailing pad bytes may segfault.
    The 4 pad bytes at tail=A9B42458 are

In my memory debugger I see

00A02444  00 00 00 00 0A 00 00 00 01 00 00 00  ............
00A02450  A9 14 00 00 FD FD FD FD 79 64 69 65  ©...ýýýýydie
00A0245C  72 65 73 69 73 00 FD FD FD FD AD BA  resis.ýýýý­º

my string starts at 00A02458 ie "ydieresis\0". It is top and tail padded
with 4 0xFD bytes. The PyMem routines seem to be using padding of 0xFB.

I don't think I've done something to change the bytes, but can I mix
strdup allocated memory with the "Python heap" which is what the manual
talks about or is this a bug? 

Is there an easy way to get a grasp on the various memory allocation
functions?
-- 
Robin Becker