Segfault on Jabber groupchat invite

[palehose@…]

On my workplace's internal jabber server, when invited to a groupchat, bitlbee segfaults. The odd thing is that no core dump is generated, despite having them turned on.

The following is logged to syslog on my box:

Sep 15 15:19:02 localhost bitlbee[14648]: Fatal signal received: 11. That's probably a bug.

I confirmed that the bitlbee user was able to generate a coredump by creating a simple script that sleeps indefinitely, running it as the bitlbee user, and then running sudo -u bitlbee kill -11 PID. A core dump was generated.

One oddity that I noticed was that bitlbee has two PIDs running when I am connected to bitlbee in my IRC client, but only one if not.

% ps -fu bitlbee
UID        PID  PPID  C STIME TTY          TIME CMD
bitlbee  15442     1  0 15:20 ?        00:00:00 /usr/sbin/bitlbee -F
bitlbee  15532 15442  0 15:21 ?        00:00:00 /usr/sbin/bitlbee -F

Perhaps this is stated in the manpage/documentation and is expected behavior, but I haven't seen it if this is the case and it seemed like it was worth mentioning.

This is how the Arch Linux initscript starts bitlbee:

su -s /bin/sh -c '/usr/sbin/bitlbee -F' bitlbee

P.S. This seems like it might be related to an older issue (#482), which was marked fixed a while back.

[palehose@…]

Something I forgot to mention: When bitlbee segfaults, the original process remains running while the secondary one dies. The motd shows up in the main channel of my irssi session, and the control channel remains active, allowing me to log back in. However (and this may be an idiosyncrasy of irssi) the network/window_name box in irssi is blank and doesn't tell me what channel I am in, so I end up needing to disconnect and reconnect to bitlbee to resume normal operations.

[wilmer]

Sorry for the late response.

Not sure what you're describing in the comment there..

The coredump may be missing because in daemon mode bitlbee will chdir to /, and obviously it can't dump core in there. Could you try running it with -Dn instead of -F, to run in 1-proc mode and not daemonize completely?

[palehose@…]

Sorry, the email notification was flagged as spam for some reason. I do not have access to the machine right now but will test this on Sunday or Monday.

[palehose@…]

I was able to get a core dump this time, running it with -Dn instead of -F.

Core dump was too large to upload, so here's a link: ​http://ompldr.org/vYXphOA/core.bitlbee.19202

[wilmer]

Apologies for the late response..

Although a coredump is quite helpful, it's useless without the corresponding binary (hopefully with debugging symbols?) .. could you provide that one too?

Or alternatively, you can generate me a backtrace.

gdb /...pathto.../bitlbee core.bitlbee.19202 bt

That may be enough already.

[palehose@…]

Derp, sorry about that. I actually had run the backtrace and saved it to a file, but never posted it to the bug report. I went back to it and realized that debugging symbols were stripped from the binary, so I recompiled and got another core dump and backtrace.

Core dump is here: ​http://ompldr.org/vYmhzYQ/core.bitlbee.6560

And here's the backtrace:

Reading symbols from /usr/sbin/bitlbee...done. [New LWP 6560]

warning: Can't read pathname for load map: Input/output error. [Thread debugging using libthread_db enabled] Core was generated by `/usr/sbin/bitlbee -Dn'. Program terminated with signal 11, Segmentation fault. #0 irc_channel_free (ic=0x0) at irc_channel.c:121 121 if( ic->flags & IRC_CHANNEL_JOINED ) (gdb) bt #0 irc_channel_free (ic=0x0) at irc_channel.c:121 #1 0x000000000041976f in bee_irc_chat_invite (bee=<optimized out>, bu=0x1b33150, name=0x1b02590 "ops@…", msg=0x1a77bd0 "byebye") at irc_im.c:782 #2 0x0000000000441871 in jabber_pkt_message (node=0x1a77b60, data=0x1a6dea0) at message.c:118 #3 0x00000000004311b2 in xt_handle (xt=0x1b27ae0, node=<optimized out>, depth=<optimized out>) at xmltree.c:191 #4 0x0000000000431138 in xt_handle (xt=0x1b27ae0, node=<optimized out>, depth=<optimized out>) at xmltree.c:171 #5 0x000000000043cf03 in jabber_read_callback (data=0x1a6dea0, fd=7, cond=B_EV_IO_READ) at io.c:184 #6 0x000000000042ac61 in gaim_io_invoke (source=<optimized out>, condition=<optimized out>, data=0x1a29fd0) at events_glib.c:85 #7 0x00007f4ced07884d in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #8 0x00007f4ced079048 in ?? () from /usr/lib/libglib-2.0.so.0 #9 0x00007f4ced079582 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 #10 0x0000000000413a47 in main (argc=<optimized out>, argv=0x7fff9bbede48) at unix.c:177

[palehose@…]

backtrace

[palehose@…]

Yuck... that got formatted poorly. Just attached it in a text file, should be more readable.

[wilmer]

Sorry for the lack of followup for a while.. This was actually fixed about a month ago in changeset:devel,889.