search

stephenrkell / liballocs

Meta-level run-time services for Unix processes... a.k.a. dragging Unix into the 1980s
http://humprog.org/~stephen/research/liballocs
Other
216 stars 26 forks source link

glibc 2.36 ld.so crash #81

Open stephenrkell opened 10 months ago

stephenrkell commented 10 months ago

Startup of liballocs is broken for me after the upgrade to glibc 2.36. Somehow a null link map pointer makes its way into the dynamic linker's structures early during startup, and it chokes. I'm still tracking this down.

(Even after I fix this, see #77 -- we have problems because of libdwarf. For me, our old ibdwarf can't process the separate DWARF file from my Devuan libc6-dbg package... I could forward-port to latest libdwarf, which may have fixed this, or it may be time for the big libdw transition.)

stephenrkell commented 10 months ago

This turns out to be a glibc bug.

It seems necessary to have some detection/reporting of glibc bugs like this at liballocs startup, since buggy releases can stay in circulation a long time and we have a habit of finding the interesting corners. Doing a check/warning phase in allocsld seems like the right thing, although in liballocs's global init would also be early enough to work much of the time.

stephenrkell commented 4 days ago

If we detect the present glibc bug, is there a black-box workaround?

I have confirmed the same bug on glibc 2.35 and 2.40.

stephenrkell commented 4 days ago

One workaround might be to do some "reflective access" to the link map structure. We are in the fortunate position, from liballocs, of being able to assume that we have the debug info to enable this. But what?

Perhaps the right thing is to bisect this in glibc and then revert the breaking change. Then figure out a bodge fix that we can do at run time, reflectively if need be.