[Python-Dev] problem with pymalloc on the BeOS port.
François Revol
revol at free.fr
Tue Aug 24 15:25:28 CEST 2004
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.
More information about the Python-Dev
mailing list