[Python-Dev] problem with pymalloc on the BeOS port.
Tim Peters
tim.peters at gmail.com
Tue Aug 24 04:27:33 CEST 2004
[François Revol]
> I'm updating the BeOS port of python to include the latest version in
> Zeta, the next incarnation of BeOS.
>
> I'm having some problem when enabling pymalloc:
>
> case $MAKEFLAGS in \
> *-s*) LIBRARY_PATH=/boot/home/Python-2.3.4:%A/lib:/boot/home/config/
> lib:/boot/beos/system/lib CC='gcc' LDSHARED='./Modules/ld_so_beos
> libpython2.3.so' OPT='-O' ./python -E ./setup.py -q build;; \
> *) LIBRARY_PATH=/boot/home/Python-2.3.4:%A/lib:/boot/home/config/lib:/
> boot/beos/system/lib CC='gcc' LDSHARED='./Modules/ld_so_beos
> libpython2.3.so' OPT='-O' ./python -E ./setup.py build;; \
> esac
> running build
> running build_ext
> building 'struct' extension
> gcc -O -fno-strict-aliasing -I. -I/boot/home/Python-2.3.4/./Include -I/
> boot/home/config/include -I/boot/home/Python-2.3.4/Include -I/boot/home
> /Python-2.3.4 -c /boot/home/Python-2.3.4/Modules/structmodule.c -o
> 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.
No it wasn't. The four bytes following the 4 trailing 0xfb hold the
call number, and they're apparently corrupt too.
> Fatal Python error: bad trailing pad byte
>
> indeed, there seem to be 4 deadblock marks between the forbidden ones,
> while the len is supposed to be null:
That's reliable. If there actually was a request for 0 bytes (that
is, assuming this pointer isn't just pointing at a random memory
address), the debug pymalloc allocates 16 bytes for it, filled with
00000000 fbfbfbfb fbfbfbfb serial
where "serial" is a big-endian 4-byte "serial number" uniquely
identifying which call to malloc (or realloc) this was. The address
of the second block of fb's is returned.
> python:dm 0x80010fb8-8 32
> 80010fb0 00000000 fbfbfbfb dbdbdbdb fbfbdbdb
> .................
> 80010fc0 0100fbfb 507686ef 04000000 fbfbfbfb
> .......vP........
> 80010fd0 8013cbc8 fbfbfbfb 44ee0100 ffed0100
> ............D....
>
> Any clue ?
Try gcc without -O. Nobody has reported anything like this before --
you're in for a lot of fun <wink>.
More information about the Python-Dev
mailing list