[Python-Dev] Re: various test failures - test_site, test_tempfile, test_bsddb/anydbm

Tim Peters tim.one at comcast.net
Sun Jun 6 13:22:44 EDT 2004


[Skip Montanaro]
> Regarding this message I'm seeing:
>
>     *** malloc[24360]: error for object 0x680b408: Pointer being
reallocated was not allocated
>
> a breakpoint in malloc_printf (handy that) yields this stack trace info
> near the call:
>
>     Starting program: /Users/skip/tmp/python/dist/src/python.exe
Lib/test/regrtest.py -f ~/tmp/tests
>     test_sundry
>     test_tcl
>     test_tempfile
>
>     Breakpoint 1, 0x90070ddc in malloc_printf ()
>     (gdb) bt 10
>     #0  0x90070ddc in malloc_printf ()
>     #1  0x9000de5c in szone_realloc ()
>     #2  0x9000dd70 in malloc_zone_realloc ()
>     #3  0x9000dce8 in realloc ()
>     #4  0x90010c24 in setenv ()
>     #5  0x90010a74 in putenv ()
>     #6  0x0012d280 in posix_putenv (self=0x0, args=0x130e038) at
Modules/posixmodule.c:5685

...

> It seems that the string posix_putenv() is passing to putenv() is
> properly allocated.

It is, but "new" is embedded inside a Python string object:

	new = PyString_AS_STRING(newstr);

A realloc(new) call would be insane (new isn't an address returned by
malloc; newstr is the address that was returned by malloc).

You need to look at this platform's implementation of putenv().  If it truly
tries to realloc() the string passed to it, it's insane.

But if it's not trying to realloc(new), then new is a red herring, and the
platform has gotten its pointers into the environment structure screwed up.
That could be due to a wild store anywhere (platform, Python, whatever).





More information about the Python-Dev mailing list