search

phhusson / quassel-irssi

An irssi plugin to connect to quassel core
62 stars 16 forks source link

Seg fault while exiting #3

Open synrg opened 10 years ago

synrg commented 10 years ago

When I have quassel-irssi loaded on irssi 0.8.15-5 (debian wheezy) and quit irssi, it causes a seg fault:

Please wait, waiting for servers to close connections..
Segmentation fault
TC01 commented 8 years ago

Can confirm this on Fedora 22, irssi 0.8.17 (20141011 1044), using current master.

TC01 commented 8 years ago

I poked at this a bit and attached gdb and got the following stacktrace:

#0  0x00007f0bacd2b693 in g_io_channel_read_chars (channel=0x2762430, buf=buf@entry=0x7ffc0bb9aac0 "\020\254\271\v\374\177", count=count@entry=512, bytes_read=bytes_read@entry=0x7ffc0bb9aa98, error=error@entry=0x7ffc0bb9aaa0)
    at giochannel.c:2014
#1  0x0000000000484dde in net_receive (handle=<optimized out>, buf=buf@entry=0x7ffc0bb9aac0 "\020\254\271\v\374\177", len=len@entry=512) at network.c:361
#2  0x0000000000483f18 in sig_disconnect (rec=rec@entry=0x2972b60) at net-disconnect.c:58
#3  0x0000000000484198 in net_disconnect_deinit () at net-disconnect.c:147
#4  0x000000000047c674 in core_deinit () at core.c:298
#5  0x0000000000416ded in textui_deinit () at irssi.c:261
#6  main (argc=<optimized out>, argv=0x7ffc0bb9af88) at irssi.c:386

Not sure how helpful this is?

TC01 commented 8 years ago

Can confirm this happens in irssi 0.8.18-g787956a (20151222 0018) too. A friend and I took a look and we weren't able to get very far, but we think this is some kind of bug in irssi that normal non-quassel-irssi usage never hits.

The channel->funcs member of the channel/handle passed to net_receive from either sig_disconnect or net_disconnect_remove points to unmapped memory. This is the cause of the segfault, though why it happens I couldn't begin to tell you.

TC01 commented 8 years ago

My friend adds: "well, it happens precisely because somewhere it's free'd, the reference isn't cleared, and then some code checks to see if the reference is non-null before trying to disconnect again and (luckily) segfaults in closing the connection using the free'd data structures before hitting another free()", but we're not sure where it's getting free'd.