RetroSearch Browse

Tue Aug 24 04:27:33 CEST 2004 · https://mail.python.org/pipermail/python-dev/2004-August/048280.html

[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>.

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

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

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