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?

 

[Michael Hudson]

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.

In a debug build *all* allocations that Python does go via pymalloc.

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?

Doesn't look like it!

Cheers,
mwh

 

[Skip Montanaro]

Robin> the storage is allocated and freed thusly

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

...

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

Memory allocated by strdup() should almost certainly be freed with free(),
not PyMem_Free().

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

Sure. Keep your allocations and deallocations within the same family of
functions. ;-)

Skip

 

[Robin Becker]

Memory allocated by strdup() should almost certainly be freed with free(),
not PyMem_Free().

Yes you're right.

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

Sure. Keep your allocations and deallocations within the same family of
functions. ;-)

Skip

in the beginning there was only the primordial heap and now I have
PyMem_Free, art_free, free and probably gt1_free grrhhhh!

They all used to commingle quite happily and seem to do so under the
non-debug case, but now I suppose we're being stricter and stricter. I
suppose M$ spends all its money on marketing and fails to get the best
possible allocator.

 

[Christos TZOTZIOY Georgiou]

They all used to commingle quite happily and seem to do so under the
non-debug case, but now I suppose we're being stricter and stricter. I
suppose M$ spends all its money on marketing and fails to get the best
possible allocator.

Have you seen the small video files with Steve Ballmer dancing around a
podium as a monkey, then saying 'I love this company', then rhythmically
calling out (possibly begging for 'Developpers, developpers,
developpers!' ? A sight to be seen.

If you haven't and are interested, let me know by email and I'll make
them available to you.