Biltbee 1.0.1 crashes a while after disconnect (msn at least)

[pasi.ov@…]

As the subject states, the program crashes 5 minutes after disconnecting from network. GDB backtrace and a partial strace log follows...

====================== GDB backtrace begins =========================

(gdb) set args -n

(gdb) run Starting program: /home/pasi/bitlbee/bitlbee -n

Program received signal SIGSEGV, Segmentation fault. 0x0804a6ed in account_on (irc=0x80784f0, a=0x8079948) at account.c:126 126 if( proto_prpl[a->protocol]->login == NULL ) (gdb) bt #0 0x0804a6ed in account_on (irc=0x80784f0, a=0x8079948) at account.c:126 #1 0x08057ed4 in auto_reconnect (data=0x8079948) at nogaim.c:314 #2 0x54656eb7 in g_main_context_wakeup () from /usr/lib/libglib-2.0.so.0 #3 0x08075ea8 in ?? () #4 0x54653388 in g_get_current_time () from /usr/lib/libglib-2.0.so.0 #5 0x546b1750 in ?? () from /usr/lib/libglib-2.0.so.0 #6 0x546b11a8 in ?? () from /usr/lib/libglib-2.0.so.0 #7 0x54656d40 in g_main_context_wakeup () from /usr/lib/libglib-2.0.so.0 #8 0x546b11a8 in ?? () from /usr/lib/libglib-2.0.so.0 #9 0x00000000 in ?? () (gdb)

======================= End of backtrace ==============================

======================= STRACE log begins =============================

... [SNIP] ...

socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3 bind(3, {sa_family=AF_INET, sin_port=htons(65535), sin_addr=inet_addr("127.0.0. 1")}, 16) = 0 listen(3, 10) = 0 fstat64(3, {st_mode=S_IFSOCK|0777, st_size=0, ...}) = 0 fcntl64(3, F_GETFL) = 0x2 (flags O_RDWR) rt_sigaction(SIGPIPE, {0x8054700, [], SA_RESTORER, 0x53dc93c8}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGINT, {0x8054700, [], SA_RESTORER|SA_ONESHOT, 0x53dc93c8}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGILL, {0x8054700, [], SA_RESTORER|SA_ONESHOT, 0x53dc93c8}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGBUS, {0x8054700, [], SA_RESTORER|SA_ONESHOT, 0x53dc93c8}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGFPE, {0x8054700, [], SA_RESTORER|SA_ONESHOT, 0x53dc93c8}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGSEGV, {0x8054700, [], SA_RESTORER|SA_ONESHOT, 0x53dc93c8}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGTERM, {0x8054700, [], SA_RESTORER|SA_ONESHOT, 0x53dc93c8}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGQUIT, {0x8054700, [], SA_RESTORER|SA_ONESHOT, 0x53dc93c8}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGXCPU, {0x8054700, [], SA_RESTORER|SA_ONESHOT, 0x53dc93c8}, {SIG_DFL}, 8) = 0 getuid32() = 1000 geteuid32() = 1000

... [CONNECT TO AND DISCONNECT FROM MSN NETWORK] ...

unlink("/home/pasi/bitlbee/pasi.accounts") = 0 rename("/home/pasi/bitlbee/pasi.accounts~", "/home/pasi/bitlbee/pasi.accounts") = 0 umask(022) = 077 close(7) = 0 gettimeofday({1141903583, 684568}, NULL) = 0 gettimeofday({1141903583, 684817}, NULL) = 0 poll([{fd=3, events=POLLIN}], 1, 300000) = 0 gettimeofday({1141903883, 706724}, NULL) = 0 --- SIGSEGV (Segmentation fault) @ 0 (0) ---

=============================== End of STRACE log ==============================

[pasi.ov@…]

My picture of the code flow is vague, but this seems to fix it.

[wilmer]

Hmm no, that part of the code can't really be related to what's in the gdb backtrace. Your patch touches code that is run at shutdown (and the strace dump also suggests that BitlBee is shutting down or at least saving settings). But that's strange, since you didn't disconnect from BitlBee, right?

Can you reproduce the problem on testing.bitlbee.org so I got a coredump for more analysis?

[pasi.ov@…]

Steps to reproduce:

1. Start bitlbee (make sure auto_reconnect = true
2. Connect to it, and identify yourself (connect to network (msn in my case))
3. Type /quit
4. After auto reconnect timeout bitlbee crashes

See protocols/nogaim.c:366 (gc->wants_to_die = FALSE, so a reconnect timeout is created). account_off sets gc->wants_to_die to TRUE and calls signoff.

I'll try testing.bitlbee.org later once I have more time (and if it's really necessary).

[wilmer]

Uhhh, how can it crash after a /quit? You're running BitlBee in daemon mode, I guess?

[pasi.ov@…]

Yes, I'm sorry I didn't realize it should've been mentioned.

Though I don't specifically use -D parameter, but just ./bitlbee.

[wilmer]

Okay, I fixed it now (see [135]). Your fix isn't enough, it'd still go wrong if the IM-server breaks the connection and you disconnect before auto-reconnect kicks in. The whole fix also deactivated the pending reconnections.

BTW, bugs specific to daemon mode don't really deserve priorities this high, unless there's a real security problem. After all, it's still officially unsupported.

But thanks for reporting it anyway. :-)