#832 closed defect (fixed)

Segfault on Jabber groupchat invite

Reported by: palehose@… Owned by: wilmer
Priority: normal Milestone:
Component: Jabber Version: 3.0.3
Keywords: groupchat Cc:
IRC client+version: irssi 0.8.15 Operating System: Linux
OS version/distro: Arch Linux


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
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.

Attachments (1)

backtrace.txt (1.4 KB) - added by palehose@… at 2011-11-28T17:32:00Z.

Download all attachments as: .zip

Change History (9)

comment:1 Changed at 2011-09-15T20:40:15Z by 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.

comment:2 Changed at 2011-10-20T03:21:45Z by 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?

comment:3 Changed at 2011-10-23T04:04:43Z by 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.

comment:4 Changed at 2011-10-25T20:26:49Z by 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:

comment:5 Changed at 2011-11-25T07:43:40Z by 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.

comment:6 Changed at 2011-11-28T17:29:52Z by 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:

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/ #8 0x00007f4ced079048 in ?? () from /usr/lib/ #9 0x00007f4ced079582 in g_main_loop_run () from /usr/lib/ #10 0x0000000000413a47 in main (argc=<optimized out>, argv=0x7fff9bbede48) at unix.c:177

Changed at 2011-11-28T17:32:00Z by palehose@…

Attachment: backtrace.txt added


comment:7 Changed at 2011-11-28T17:33:00Z by palehose@…

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

comment:8 Changed at 2012-03-25T15:28:14Z by wilmer

Resolution: fixed
Status: newclosed

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

Modify Ticket

as closed The owner will remain wilmer.
The resolution will be deleted.

Add Comment

E-mail address and name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.