RetroSearch Browse

Thu Sep 2 12:24:07 CEST 2004 · https://mail.python.org/pipermail/python-dev/2004-September/048538.html

> [François Revol]
> > Now, I don't see why malloc itself would give such a result, it's
> > pyMalloc which places those marks, so the thing malloc does 
> > wouldn't
> > place them 4 bytes of each other for no reason, or repport 0 bytes
> > where 4 are allocated.
> 
> I think you're fooling yourself if you believe 4 *were* allocated. 
> The memory dump shows nothing but gibberish, with 4 blocks of 
> fbfbfbfb
> not a one of which makes sense in context (the numbers before and
> after them make no sense as "# of bytes allocated" or as "serial
> number" values, so these forbidden-byte blocks don't make sense as
> either end of an active pymalloc block).
> 
> You should at least try to get a C traceback at this point, on the
> chance that the routine passing the pointer is a clue.  We don't even
> know here yet whether the complaint came from a free() or realloc()
> call.

I finally found out what was making python throw up when using 
pymalloc, (and possibly why I'm getting MemoryErrors without it).
It's caused by the BeOS exec() which copies the path to argv[0] 
without telling anyone.
I noticed it was overriding argv[0] in the execed process, but didn't 
think it was doing that before actually doing the syscall.
So this results in a double-free if exec fails.

posix_fork()
posix_fork() 0
posix_fork() 637
posix_execv1
posix_execv2: path @ 0x80010fb8 ='./gcc'
posix_execv3
posix_execv4
posix_execv5: argvlist @ 0x8014f8e0
posix_execv5: argv[0] @ 0x80010fa0 = gcc
posix_execv5: argv[1] @ 0x80010e20 = -O0
posix_execv5: argv[2] @ 0x801504c0 = -g
posix_execv5: argv[3] @ 0x800193c0 = -fno-strict-aliasing
posix_execv5: argv[4] @ 0x80150400 = -I.
posix_execv5: argv[5] @ 0x80160f08 = -I/boot/home/Python-2.3.4/./
Include
posix_execv5: argv[6] @ 0x8015c028 = -I/boot/home/config/include
posix_execv5: argv[7] @ 0x80160f40 = -I/boot/home/Python-2.3.4/Include
posix_execv5: argv[8] @ 0x8015c0e8 = -I/boot/home/Python-2.3.4
posix_execv5: argv[9] @ 0x80150460 = -c
posix_execv5: argv[10] @ 0x8015e3a8 = /boot/home/Python-2.3.4/Modules/
structmodule.c
posix_execv5: argv[11] @ 0x801503b8 = -o
posix_execv5: argv[12] @ 0x8015e068 = build/temp.beos-5.1-BePC-2.3/
structmodule.o
posix_execv6
execv: No such file or directory
posix_execv7: path @ 0x80010fb8 ='./gcc'
posix_execv7: argvlist @ 0x8014f8e0
posix_execv7: argv[0] @ 0x80010fb8 = ./gcc <<<<<< that's the problem !
posix_execv7: argv[1] @ 0x80010e20 = -O0
posix_execv7: argv[2] @ 0x801504c0 = -g
posix_execv7: argv[3] @ 0x800193c0 = -fno-strict-aliasing
posix_execv7: argv[4] @ 0x80150400 = -I.
posix_execv7: argv[5] @ 0x80160f08 = -I/boot/home/Python-2.3.4/./
Include
posix_execv7: argv[6] @ 0x8015c028 = -I/boot/home/config/include
posix_execv7: argv[7] @ 0x80160f40 = -I/boot/home/Python-2.3.4/Include
posix_execv7: argv[8] @ 0x8015c0e8 = -I/boot/home/Python-2.3.4
posix_execv7: argv[9] @ 0x80150460 = -c
posix_execv7: argv[10] @ 0x8015e3a8 = /boot/home/Python-2.3.4/Modules/
structmodule.c
posix_execv7: argv[11] @ 0x801503b8 = -o
posix_execv7: argv[12] @ 0x8015e068 = build/temp.beos-5.1-BePC-2.3/
structmodule.o
Debug memory block at address p=0x80010fb8:
    0 bytes originally requested
    The 4 pad bytes at p-4 are FORBIDDENBYTE, as expected.
    The 4 pad bytes at tail=0x80010fb8 are not all FORBIDDENBYTE 
(0xfb):
        at tail+0: 0xdb *** OUCH
        at tail+1: 0xdb *** OUCH
        at tail+2: 0xdb *** OUCH
        at tail+3: 0xdb *** OUCH
    The block was made by call #3688627195 to debug malloc/realloc.
Fatal Python error: bad trailing pad byte
error: Bad thread ID

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2004-September/048538.html below:

[Python-Dev] problem with pymalloc on the BeOS port.