Bug 501786
Summary: | bitlbee segv's when trying to connect to jabber server | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora EPEL | Reporter: | Ben Woodard <woodard> | ||||
Component: | bitlbee | Assignee: | Robert Scheck <redhat-bugzilla> | ||||
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | el5 | CC: | mastahnke, mcepl, mcepl, redhat-bugzilla, rzhou | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | x86_64 | ||||||
OS: | Linux | ||||||
Whiteboard: | ActualBug | ||||||
Fixed In Version: | 1.2.3-4.fc10 | Doc Type: | Bug Fix | ||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2009-08-16 22:50:48 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Ben Woodard
2009-05-20 17:35:24 UTC
Looks like this is an issue with the SRV thing :-( [16:12:11] < wilmer> rsc: That's on SRV lookups I think? [16:12:32] < wilmer> Someone reported a problem like that here a few days ago at least. [16:12:59] < rsc> wilmer: is it on SRV lookups? [16:13:24] < wilmer> Yeah. [16:13:40] < wilmer> It's fixed by manually setting the server variable [16:13:45] < wilmer> Which suppresses SRV lookups. [16:13:55] < wilmer> Also note that the crash happens after receiving response from the DNS server. [16:15:25] < rsc> wilmer: okay, that means for me now what? [16:35:59] < wilmer> rsc: Didn't you modify that code? [16:37:29] < rsc> wilmer: I added a contributed patch, yes. But are you sure, the SRV records are causing this? [16:40:08] < wilmer> rsc: Quite sure; the crash doesn't happen if the user sets the server variable manually. [16:40:39] < rsc> wilmer: details? I don't get your point. [16:42:49] < wilmer> rsc: What kind of details are you looking for? [16:43:05] < rsc> wilmer: What do you mean with setting server variable manually? [16:43:36] < wilmer> Oh, that; specifying the name of the server to connect to. account set x/server chat-green.llnl.gov in this case. [16:43:58] < wilmer> If that var is set, BitlBee won't try to guess/look up the servername and just use the variable instead. [16:44:49] < wilmer> rsc: Someone else reported a problem very similar to this (also on Fedora, possibly a new release?) and setting the servar var solved the problem. [16:48:29] < rsc> wilmer: mmh. Ideas how to fix that? [16:52:33] < wilmer> rsc: We should probably first get something better than a strace dump, like a full stacktrace. :-) Ben, can you test, whether setting the server variable manually solves your problem? And can you create a core dump with full backtrace/stacktrace? Matěj, any ideas? The patch (I still like it) was initially contributed by you. I think setting system to generate coredumps (e.g., it is switched off in Fedora/RHEL) and then analyze coredump with gdb postmortem is probably the easiest thing to do. And yes, that would be one more reason why this patch should be accepted upstream, so that it doesn't get out of sync with the rest of the code (which is the only reason which comes to my mind why this happens, because it is actually quite simple patch otherwise). Oh sorry, I missed that reporter of the bug isn't Robert. OK, then in order to switch on generating of coredumps, do the following: a) install bitlbee-debuginfo from http://download.fedora.redhat.com/pub/epel/5Server/i386/debug/bitlbee-debuginfo-1.2.3-1.el5.i386.rpm (or whatever is the appropriate for your system) b) edit /etc/security/limits.conf and add there two lines * soft core 0 * hard core 0 Also, you may need to comment out ulimit -c 0 in /etc/profile or somewhere else (grep -rs /etc is your friend). c) quit your IRC client and restart xinetd (or inetd) daemon When you try the connection and bitlbee crashes, you should get file name core.<number> either in / or in /usr/sbin/ (or wherever is a binary of bitlbee located). Run over that core file this gdb -nx --batch -ex 'backtrace' /usr/sbin/bitlbee core.<number> \ >/tmp/bitlbee-log.txt 2>/dev/null Please attach /tmp/bitlbee-log.txt to this bug report as an separate uncompressed attachment. We will review this issue again once you've had a chance to attach this information. Thanks in advance. BTW it is vastly easier to just have gdb attach to the running bitlbee process after xinetd runs it. Program received signal SIGSEGV, Segmentation fault. 0x0000003ed247b59b in memcpy () from /lib64/libc.so.6 (gdb) bt #0 0x0000003ed247b59b in memcpy () from /lib64/libc.so.6 #1 0x000000000041e0a8 in srv_lookup () #2 0x000000000042a118 in ?? () #3 0x0000000000415cb6 in ?? () #4 0x0000000000416268 in root_command_string () #5 0x00000000004101f9 in irc_send () #6 0x00000000004113a4 in irc_process () #7 0x000000000040d82d in bitlbee_io_current_client_read () #8 0x0000003eae62cdb4 in g_main_context_dispatch () from /lib64/libglib-2.0.so.0 #9 0x0000003eae62fc0d in ?? () from /lib64/libglib-2.0.so.0 #10 0x0000003eae62ff1a in g_main_loop_run () from /lib64/libglib-2.0.so.0 #11 0x0000000000418af9 in main () With debuginfo: (gdb) bt #0 0x0000003ed247b59b in memcpy () from /lib64/libc.so.6 #1 0x000000000041e0a8 in srv_lookup (service=<value optimized out>, protocol=<value optimized out>, domain=<value optimized out>) at srv.c:207 #2 0x000000000042a118 in jabber_login (acc=0x6d62090) at jabber.c:190 #3 0x0000000000415cb6 in cmd_account (irc=0x6d4d2d0, cmd=<value optimized out>) at root_commands.c:377 #4 0x0000000000416268 in root_command_string (irc=0x410, u=<value optimized out>, command=0x414 <Address 0x414 out of bounds>, flags=<value optimized out>) at root_commands.c:77 #5 0x00000000004101f9 in irc_send (irc=0x6d4d2d0, nick=0x6d4d280 "root", s=0x6d4d280 "root", flags=0) at irc.c:1108 #6 0x00000000004113a4 in irc_process (irc=0x6d4d2d0) at irc.c:413 #7 0x000000000040d82d in bitlbee_io_current_client_read (data=0x6d4d2d0, fd=0, cond=<value optimized out>) at bitlbee.c:184 #8 0x0000003eae62cdb4 in g_main_context_dispatch () from /lib64/libglib-2.0.so.0 #9 0x0000003eae62fc0d in ?? () from /lib64/libglib-2.0.so.0 #10 0x0000003eae62ff1a in g_main_loop_run () from /lib64/libglib-2.0.so.0 #11 0x0000000000418af9 in main (argc=<value optimized out>, argv=0x7fff290209e8) at unix.c:135 Created attachment 351711 [details]
Fix null pointer dereference.
Hi, here's a patch to srv.c which solves the issue for me. The issue is triggered for me when the conditions in
if ((((HEADER *)answer)->rcode)==NOERROR && (count=ntohs(((HEADER *)answer)->ancount))) {
are false, which causes:
*reply = *list;
with list = NULL.
This happens when no SRV records are returned.
Wow, thank you. I'll fire a new build in the next few days together with another nearly solved bitlbee packaging issue (bitlbee-devel subpackage). bitlbee-1.2.3-4.el4 has been submitted as an update for Fedora EPEL 4. http://admin.fedoraproject.org/updates/bitlbee-1.2.3-4.el4 bitlbee-1.2.3-4.el5 has been submitted as an update for Fedora EPEL 5. http://admin.fedoraproject.org/updates/bitlbee-1.2.3-4.el5 bitlbee-1.2.3-4.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/bitlbee-1.2.3-4.fc11 bitlbee-1.2.3-4.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/bitlbee-1.2.3-4.fc10 bitlbee-1.2.3-4.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report. bitlbee-1.2.3-4.el4 has been pushed to the Fedora EPEL 4 stable repository. If problems still persist, please make note of it in this bug report. bitlbee-1.2.3-4.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report. bitlbee-1.2.3-4.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report. |