Greg Troxel <gdt%ir.bbn.com@localhost> writes: > I have a box that has been running jabberd2 mostly happily for a year. > It started acting up, per user reports, so I rebooted it. Then on start > c2s would crash; a representative backtrace is attached. I updated the > machine to netbsd-4, rebuilt all the packages, and then updated jabberd2 > to the next micro revision from what pkgsrc has. None of this has > helped. The machine is a xen2 i386 domU. > > [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 () > > The only other wrinkle is that with netbsd-4 kernel and netbsd-3 > userland, rsync also dumped core. But now it works fine. > > This crash is 100% repeatable. > > Any clues greatly appreciated. I am able to work around this by using -pthread in CFLAGS and LDFLAGS on c2s. The problem seems to be dlopening authreg_sqlite3 which is linked with pthread, but the base program is not. What I don't understand is why the unlock is blowing up but the corresponding lock did not - it doesn't seem that pthreads were initialized during the malloc call - there is only one thread. I also had to do this with sm. Is this a bug in our libc? Or jabberd2?
Attachment:
pgp_NJoWY3Bl9.pgp
Description: PGP signature