I just had trouble with jabberd2 and mostly understand it now. Context
is netbsd-4 i386 (xen domU, but I think that doesn't matter).
c2s is a program not linked against pthreads. It loads
/usr/pkg/lib/jabberd/authreg_sqlite3.so which is linked with pthreads.
c2s crashes like this:
[Switching to Thread 1]
0xbb84223f in kill () from /usr/lib/libc.so.12
(gdb) bt
#0 0xbb84223f in kill () from /usr/lib/libc.so.12
#1 0xbb844293 in __libc_mutex_unlock () from /usr/lib/libc.so.12
#2 0xbb8de81b in malloc () from /usr/lib/libc.so.12
#3 0xbb8dbbed in calloc () from /usr/lib/libc.so.12
#4 0x0804db19 in authreg_init ()
#5 0x0805129d in main ()
I think what's going on is:
at startup __isthreaded is 0
__libc_mutex_unlock is bound to the stub
__weak_alias(__libc_mutex_unlock,__libc_mutex_catchall_stub)
the stub checks that __isthreaded is still 0
c2s dlopens authreg_sqlite3
pthread init runs, setting __isthreaded to 1
the symbol __libc_mutex_unlock does NOT get magically relinked to
point to the pthread implementation as it would have had pthread's
strong alias been found originally:
__strong_alias(__libc_mutex_unlock,pthread_mutex_unlock)
malloc does lock and unlock, but now unlock blows up because __isthreaded is
1
[I cannot explain why the corresponding lock does not fail.]
As a workaround I linked c2s with pthread.
Should this be fixed? Is it fixed in netbsd-5? If not, should it be
documented somehow? Should pthread init check the symbol binding in
libc and abort right away with a useful message if they are wrong?
(Perhaps a pthread_ok function that does printf/syslog/abort in libc,
and nothing in pthread, with the same weak symbol trick.)
Is this an upstream bug? What does POSIX say? (I asked my local C99
language lawyer, but he declined to opine on weak symbols and threads.)
Attachment:
pgpxtHtspHLzW.pgp
Description: PGP signature