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

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