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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4