[Python-Dev] problem with pymalloc on the BeOS port. (original) (raw)

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) LIBRARYPATH=/boot/home/Python-2.3.4:%A/lib:/boot/home/config/ lib:/boot/beos/system/lib CC='gcc' LDSHARED='./Modules/ldsobeos _libpython2.3.so' OPT='-O' ./python -E ./setup.py -q build;; _ *) LIBRARYPATH=/boot/home/Python-2.3.4:%A/lib:/boot/home/config/lib:/ boot/beos/system/lib CC='gcc' LDSHARED='./Modules/ldsobeos _libpython2.3.so' OPT='-O' ./python -E ./setup.py build;; _ esac running build running buildext 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 .

More information about the Python-Dev mailing list