Heads up.. bug fix in the pipeline...
Peter Wemm
peter at wemm.org
Sat Mar 20 12:21:24 PST 2004
I have a pending commit that is going to cause quite a bit of impact..
The problem is that several bugs in the stack alignment code have
conspired to cause subtle explosions at hard-to-track times. I'm
pretty sure these are the cause of the ogg123 crashes, for example.
Here's what was wrong..
1) the /usr/lib/crti.o and crtn.o files did not have the correct stack
alignment conventions.
2) ld-elf.so.1 called its startup routine (_rtld()) with the wrong stack
alignment. Since _rtld() loads the libraries and calls their _init
functions (which come from crti/crtn.o), the two wrongs made a right
and the constructors were accidently called with the right alignment.
3) _rtld_bind() in ld-elf.so.1 was called with the wrong alignment. It
has callbacks into libpthread for the locking. Depending on kse thread
state, it could blow up. I think this was the specific cause of the
ogg123 bug.
4) dlopen() and dlclose() were called with the right alignment, but
since _init/_fini() were wrong, any constructors called from there
would be called with the wrong alignment. Even if it was the same
libraries that worked by accident in 2) above.
5) _fini() was always called with the wrong alignment.
The good news is that the fixes are small. The bad news is that
crti/crtn.o are linked into *every single shared library!*. Any
libraries that contain C++ code and use static constructors will need
to be recompiled after ld-elf.so.1 is fixed (since one of the
double-wrongs in 2) wll be corrected, leaving a single wrong).
So. that means that the fix will make some things magically start
working after a 'make world'. And it might break a few things from
ports. A recompile (portupgrade -f) should fix it.
I don't know of a good way to detect shared libraries that have static
constructors or not. But it shouldn't be hard to decode objdump etc.
Anyway, I'm planning to commit these fixes soon, after I've finished
testing to make sure that nothing new breaks.
FYI, the change so far is attached..
--
Peter Wemm - peter at wemm.org; peter at FreeBSD.org; peter at yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hammer.diff
Type: text/x-diff
Size: 3097 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-amd64/attachments/20040320/b6383e89/hammer.bin
More information about the freebsd-amd64
mailing list