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