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

[François Revol]

Tim Peters <tim.peters at gmail.com>:
> [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:

> > [zapped]

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

> 
> > 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.
Yes that's what I deduced from the code of pymalloc.

> 
> > 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>.
> 
OK, tried -O0 -g but same result.
I suspect it might be a bad interaction with fork(), as it crashes in a 
child, quite badly, as no images are repported as loaded in the team (= 
no binary are mapped in the process), however the areas are there (= 
pages).

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.

François.