On Wed, 1 Nov 2000, John Polstra wrote:
> In article <[EMAIL PROTECTED]>,
> Maxim Sobolev  <[EMAIL PROTECTED]> wrote:
> > 
> > I'm not sure what exactly caused this behaviour (I can guess two potential
> > victims: O'Brien's changes in crt stuff and recent Polstra's changes in
> > libgcc_r), but it seems that some programs built on the previous -current from
> > 27 October immediately segfault when I'm trying to run then on system installed
> > from today's sources. The segfault disappeared when I recompiled affected
> > program. With this message I'm attaching short backtrace.
> [...]
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x287de417 in pthread_mutex_lock () from /usr/lib/libc_r.so.4
> > (gdb) bt
> > #0  0x287de417 in pthread_mutex_lock () from /usr/lib/libc_r.so.4
> > #1  0x806e782 in __register_frame_info ()
> > #2  0x287a3137 in _init () from /usr/lib/libc_r.so.4
> > #3  0x2879ffe5 in _init () from /usr/lib/libc_r.so.4
> > #4  0x280797fd in _rtld () from /usr/libexec/ld-elf.so.1
> Here are all the random facts which, when put together, explain what
> is going on.
> Your old application was (like all -pthread programs) linked
> with "/usr/lib/libgcc_r.a".  That library contains a function
> "__register_frame_info" which uses some of the facilities of the
> pthreads library "libc_r".
> The pthreads library has to be initialized before it can be used, by
> a call to _thread_init.  If some functions such as pthread_mutex_lock
> are called before the library has been initialized, a segmentation
> violation results.
> _thread_init is called automatically from libc_r's _init function
> when the dynamic linker loads the library.  Unfortunately, that
> isn't early enough.  libgcc_r is the first thing to be initialized,
> and it calls pthread_mutex_lock before _thread_init has been called.
> Or rather I should say that OLD versions of libgcc_r did that --
> because they were buggy.
> In other words, your old application was linked with a buggy version
> of libgcc_r, but it didn't become apparent until now.
> It didn't become apparent until now because our crtbegin.o and
> crtend.o were also buggy.  They failed to call __register_frame_info.
> This was a problem for C++ programs using exceptions, especially when
> the gcc port was used and DWARF2 exception handling was selected.
> Now we have fixed crtbegin.o and crtend.o, and we have fixed
> libgcc_r.a.  But it causes problems for your old application because
> the new crtbegin.o and crtend.o (linked into the new shared libraries
> such as libc_r) call __register_frame_info in your old, buggy,
> statically linked libgcc_r.a.
> Are you dizzy yet?

Yes ;-)

> To sum up, your old executable contains the bug but
> it wasn't triggered until the recent changes.
> Now, what can or should we do about this?  Arguably we should simply
> say in the release notes, "Relink your old multithreaded applications.
> They had a bug which is now fixed."  But if there are binary-only
> commercial apps which exhibit the problem, this solution is useless.
> I don't know whether there are any such apps, but I doubt it.  N.B.,
> Linux apps don't count because they were never linked with our
> libgcc_r in the first place.
> Or we can try to work around it, but there aren't any perfectly nice
> ways to do so.  Here are some possibilities:
> - Put a hack in the threads library so that whenever
>   pthread_mutex_lock is called it checks to make sure that the
>   threads library has been initialized, and if not, it calls
>   _thread_init.  This is a poor solution because it adds overhead to
>   a rather performance-critical function -- though admittedly the
>   overhead is very small.  Another potential problem is that there
>   could be a race condition if several threads all called
>   pthread_mutex_lock at once before the threads library had been
>   initialized.  I don't think the race condition would materialize,
>   though, since the first call would come from libgcc_r, well before
>   the application had gotten control.
> - Put a hack into the dynamic linker to call _thread_init very early
>   if that symbol was defined.  I like this solution even less,
>   because it's too hackish.  The dynamic linker isn't the place for
>   special hooks like that.
> - Put a hack into crtbegin.o or crtend.o.  But we are using the
>   standard GNU versions of these, and I really really don't want to
>   change that.  In any case, it's the wrong place for the
>   work-around.
> Overall I would lean toward putting the hack into pthread_mutex_lock.
> Comments?

If that's the lesser evil, then I guess it's OK with me.

Dan Eischen

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to