Modify

#1249 closed defect (duplicate)

Process abort from detected double-free or corruption

Reported by: yipdw@… Owned by:
Priority: normal Milestone:
Component: BitlBee Version: devel
Keywords: Cc:
IRC client+version: Client-independent Operating System: Linux
OS version/distro:

Description

Bitlbee version: 3.4.1+20151216+master+120-gd11ccbf (from code.bitlbee.org deb repo)

Platform: Ubuntu 14.04.3 LTS x86_64

Description of problem:

Shortly after starting bitlbee, the server aborts.

I am connecting two XMPP accounts, one AIM account, and one Twitter account. One of the XMPP accounts is encountering authentication errors; I'm not sure why. However, three of the four accounts do successfully connect.

Running bitlbee in daemon no-fork mode under gdb shows a double-free and the following backtrace:

(gdb) r  -D -n -v -c /etc/bitlbee/bitlbee.conf -i localhost -p 6667
Starting program: /usr/sbin/bitlbee -D -n -v -c /etc/bitlbee/bitlbee.conf -i localhost -p 6667
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
*** Error in `/usr/sbin/bitlbee': double free or corruption (fasttop): 0x000055555592c9a0 ***

Program received signal SIGABRT, Aborted.
0x00007ffff662fcc9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56      ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x00007ffff662fcc9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x00007ffff66330d8 in __GI_abort () at abort.c:89
#2  0x00007ffff666c394 in __libc_message (do_abort=do_abort@entry=1, fmt=fmt@entry=0x7ffff677ab28 "*** Error in `%s': %s: 0x%s ***\n") at ../sysdeps/posix/libc_fatal.c:175
#3  0x00007ffff667866e in malloc_printerr (ptr=<optimized out>, str=0x7ffff677acf0 "double free or corruption (fasttop)", action=1) at malloc.c:4996
#4  _int_free (av=<optimized out>, p=<optimized out>, have_lock=0) at malloc.c:3840
#5  0x000055555558d680 in phb_free (phb=0x55555592c9a0, success=1) at /tmp/buildd/bitlbee-3.4.1+20151216+master+120-gd11ccbf/lib/proxy.c:85
#6  0x000055555558d855 in proxy_connected (data=0x55555592c9a0, source=-1, cond=B_EV_IO_WRITE) at /tmp/buildd/bitlbee-3.4.1+20151216+master+120-gd11ccbf/lib/proxy.c:128
#7  0x0000555555584f6c in b_event_passthrough (fd=15, event=4, data=0x55555584ebd0) at /tmp/buildd/bitlbee-3.4.1+20151216+master+120-gd11ccbf/lib/events_libevent.c:143
#8  0x00007ffff7391f24 in event_base_loop () from /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5
#9  0x0000555555584e6e in b_main_run () at /tmp/buildd/bitlbee-3.4.1+20151216+master+120-gd11ccbf/lib/events_libevent.c:84
#10 0x000055555558293c in main (argc=10, argv=0x7fffffffe678) at /tmp/buildd/bitlbee-3.4.1+20151216+master+120-gd11ccbf/unix.c:172

If bitlbee is running in fork mode, the process still aborts after a short time, but it looks like only the forked child dies.

I have not yet timed how long it is from successful connection to process abort, but it seems to be consistent.

Attachments (0)

Change History (5)

comment:1 Changed at 2016-02-13T04:09:05Z by yipdw@…

Turning off the AIM account and the XMPP account that encounters login failures seems to have improved stability. I'll follow up here if the process encounters the same abort errors.

comment:2 Changed at 2016-02-13T16:34:33Z by dx

This looks like a dupe of #1248 (see valgrind log in comments)

I wonder why these never appeared before.

The wip/shitty-proxy-connected-fix branch has a fix for this, c6bc434e05215b99f6ac70da7d54f8937a40a2c5

comment:3 Changed at 2016-02-13T17:07:35Z by dx

As far as I understand this issue, the problem is only with AIM. If you can reproduce the same issue with XMPP, please get a valgind log too:

Can you run it under valgrind? Just install valgrind, stop bitlbee and start it with "valgrind bitlbee -Dnv". That will give more useful output

comment:4 Changed at 2016-02-13T20:08:12Z by yipdw@…

Cool, I'll give the WIP fix a try. This does indeed look like a dupe of #1248.

My Bitlbee instance has been stable since last night, so I agree that there is something in the AIM flow that's causing this.

comment:5 Changed at 2016-02-18T11:31:32Z by dx

Resolution: duplicate
Status: newclosed

Closing as duplicate of #1248, which was fixed in 242f280339195f878973dd7f1e8c3e9233d61c0a

Modify Ticket

Action
as closed The ticket will remain with no owner.
The resolution will be deleted. Next status will be 'reopened'.

Add Comment


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

 
Note: See TracTickets for help on using tickets.