View Revisions: Issue #5669

Summary 0005669: Rare crash issue involving third-party channel mode with param and +P
Revision 2020-05-08 20:58 by Gottem
Description I believe GaMbiTo initially reported the issue and PeGaSuS was able to reproduce it, but I'm not. :>

Apparently when using my joinmute module (+J <seconds>) in conjunction with +P, Unreal may or may not crash when you rehash. After letting Pegasus mess with gdb we found this:

(gdb) b channel.c:707
Breakpoint 1 at 0x5555555713c8: file channel.c, line 707.
(gdb) c
Continuing.
WARNING: Time jumped ~29 seconds ahead! (1588961268 -> 1588961297)
[TimeShift] Resetting some timers!
Loading IRCd configuration..
Configuration loaded.
Loading IRCd configuration..

Thread 1 "unrealircd" hit Breakpoint 1, channel_modes (client=<optimized out>, mbuf=0x5555555f48e5 <modebuf+5> "", mbuf@entry=0x5555555f48e0 <modebuf> "+ntPJ", 
    pbuf=pbuf@entry=0x5555555f46e0 <parabuf> "", mbuf_size=507, mbuf_size@entry=512, pbuf_size=pbuf_size@entry=512, channel=channel@entry=0x555555bab4c0) at channel.c:707
707					ircsnprintf(pbuf, pbuf_size, "%s ", cm_getparameter(channel, flag));
(gdb) p channel->chname + 0
$1 = 0x555555bab628 "#test"
(gdb) p flag
$2 = 74 'J'
(gdb) p cm_getparameter(channel, flag)

Thread 1 "unrealircd" received signal SIGSEGV, Segmentation fault.


However, when I do exactly the same steps, the line that causes a segfault for him doesn't for me:
(gdb) p cm_getparameter(channel, flag)
$6 = 0x7ffff382a800 <retbuf> "10"


I checked some shit around the get_param() module API stuff but when I compare with one of your modules (chanhistory) I don't see anything out of the ordinary, so I don't think it's an issue with the module. We're both using the dev version along with the same version of this particular module. :>

Also, here's the full backtrace:
Thread 1 "unrealircd" received signal SIGSEGV, Segmentation fault.
0x00007ffff757d510 in ?? ()
(gdb) bt
#0  0x00007ffff757d510 in ?? ()
#1  0x00005555555713cd in channel_modes (client=<optimized out>, mbuf=0x5555555f48e5 <modebuf+5> "", mbuf@entry=0x5555555f48e0 <modebuf> "+ntPJ", pbuf=pbuf@entry=0x5555555f46e0 <parabuf> "", 
    mbuf_size=507, mbuf_size@entry=512, pbuf_size=pbuf_size@entry=512, channel=channel@entry=0x555555bab500) at channel.c:707
#2  0x00007ffff75b4dce in write_channel_entry (channel=0x555555bab500, tmpfname=0x7fffffffb9a0 "/home/unrealircd/unrealircd/data/channel.db.tmp", fd=0x55555595a450) at channeldb.c:292
#3  write_channel_entry (fd=0x55555595a450, tmpfname=0x7fffffffb9a0 "/home/unrealircd/unrealircd/data/channel.db.tmp", channel=0x555555bab500) at channeldb.c:280
#4  0x00007ffff75b502e in write_channeldb () at channeldb.c:231
#5  0x00007ffff75b5111 in Mod_Unload (modinfo=0x555555a0c448) at channeldb.c:118
#6  0x000055555557c05e in Unload_all_loaded_modules () at modules.c:592
#7  0x000055555559bcbe in init_conf (rootconf=0x5555559562a0 "/home/unrealircd/unrealircd/conf/unrealircd.conf", rehash=rehash@entry=1) at conf.c:2080
0000008  0x000055555559bef5 in rehash_internal (client=client@entry=0x7ffff74e4058, sig=<optimized out>) at conf.c:10165
#9  0x000055555559bfe8 in rehash (client=client@entry=0x7ffff74e4058, sig=<optimized out>) at conf.c:10156
#10 0x00005555555a24be in cmd_rehash (client=0x7ffff74e4058, recv_mtags=<optimized out>, parc=<optimized out>, parv=0x5555558a9c40 <para>) at serv.c:687
#11 0x000055555557de46 in parse2 (cptr=cptr@entry=0x7ffff74e4058, fromptr=fromptr@entry=0x7fffffffbf90, mtags=0x0, ch=<optimized out>) at parse.c:501
#12 0x000055555557e451 in parse (cptr=cptr@entry=0x7ffff74e4058, buffer=<optimized out>, length=<optimized out>) at parse.c:228
#13 0x000055555557e5f9 in dopacket (client=client@entry=0x7ffff74e4058, buffer=buffer@entry=0x7fffffffbfe0 "rehash", length=<optimized out>) at parse.c:159
#14 0x000055555557e6bd in parse_client_queued (client=client@entry=0x7ffff74e4058) at parse.c:120
#15 0x000055555557e757 in process_packet (client=client@entry=0x7ffff74e4058, 
    readbuf=readbuf@entry=0x5555558cdfa0 <readbuf> "rehash\r\n1588909005047\r\n2\r\n\nost cap-notify userhost-in-names multi-prefix away-notify account-notify server-time\r\n", 
    length=<optimized out>, killsafely=killsafely@entry=0) at parse.c:56
#16 0x00005555555a4471 in read_packet (fd=9, revents=<optimized out>, data=0x7ffff74e4058) at socket.c:1115
0000017 0x000055555559c687 in fd_select (delay=<optimized out>) at dispatch.c:500
#18 0x0000555555577950 in SocketLoop (dummy=<optimized out>) at ircd.c:1410
#19 0x000055555556dc09 in main (argc=<optimized out>, argv=<optimized out>) at ircd.c:1377
Revision 2020-05-08 20:33 by Gottem
Description I believe GaMbiTo initially reported the issue and PeGaSuS was able to reproduce it, but I'm not. :>

Apparently when using my joinmute module (+J <seconds>) in conjunction with +P, Unreal may or may not crash when you rehash. After letting Pegasus mess with gdb we found this:

(gdb) b channel.c:707
Breakpoint 1 at 0x5555555713c8: file channel.c, line 707.
(gdb) c
Continuing.
WARNING: Time jumped ~29 seconds ahead! (1588961268 -> 1588961297)
[TimeShift] Resetting some timers!
Loading IRCd configuration..
Configuration loaded.
Loading IRCd configuration..

Thread 1 "unrealircd" hit Breakpoint 1, channel_modes (client=<optimized out>, mbuf=0x5555555f48e5 <modebuf+5> "", mbuf@entry=0x5555555f48e0 <modebuf> "+ntPJ", 
    pbuf=pbuf@entry=0x5555555f46e0 <parabuf> "", mbuf_size=507, mbuf_size@entry=512, pbuf_size=pbuf_size@entry=512, channel=channel@entry=0x555555bab4c0) at channel.c:707
707					ircsnprintf(pbuf, pbuf_size, "%s ", cm_getparameter(channel, flag));
(gdb) p channel->chname + 0
$1 = 0x555555bab628 "#test"
(gdb) p flag
$2 = 74 'J'
(gdb) p cm_getparameter(channel, flag)

Thread 1 "unrealircd" received signal SIGSEGV, Segmentation fault.


However, when I do exactly the same steps, the line that causes a segfault for him doesn't for me:
(gdb) p cm_getparameter(channel, flag)
$6 = 0x7ffff382a800 <retbuf> "10"


I checked some shit around the get_param() module API stuff but when I compare with one of your modules (chanhistory) I don't see anything out of the ordinary, so I don't think it's an issue with the module. We're both using the dev version along with the same version of this particular module. :>