Reported by yitz on irc (2018-08-11 03:48 UTC), happened twice, has coredumps and sent them to me.
Irssi 1.1.1-2 on arch linux, no debug symbols.
Stack traces posted: http://ix.io/1jRw http://ix.io/1jRx http://ix.io/1jRy (last one is the same but with gdb)
The shorter one:
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000555dfa3cb297 in ?? ()
[Current thread is 1 (Thread 0x7ff2de438740 (LWP 13322))]
(gdb) bt
#0 0x0000555dfa3cb297 in ?? ()
#1 0x0000555dfa3cb6c5 in textbuffer_view_scroll ()
#2 0x0000555dfa3bc74a in gui_window_scroll ()
#3 0x0000555dfa43d9e2 in ?? ()
#4 0x0000555dfa43df97 in signal_emit ()
#5 0x0000555dfa3f3d19 in ?? ()
#6 0x0000555dfa3f5832 in key_pressed ()
#7 0x0000555dfa3b9269 in ?? ()
#8 0x0000555dfa43d9e2 in ?? ()
#9 0x0000555dfa43df97 in signal_emit ()
#10 0x0000555dfa3ba7da in ?? ()
#11 0x00007ff2df3d9cb3 in ?? () from /usr/lib/libglib-2.0.so.0
#12 0x00007ff2df3d91d6 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#13 0x00007ff2df3d95b1 in ?? () from /usr/lib/libglib-2.0.so.0
#14 0x00007ff2df3d963e in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#15 0x0000555dfa3b5c42 in main ()
(gdb)
Started happening after switching to the libpurple variant of bitlbee, and three days after upgrading from 1.1.1-1 to 1.1.1-2, which is a perl 5.28 rebuild with no other changes.
00:49 <+yitz> Started playing with libpurple yesterday. Thu 2018-08-09 15:34:29 PDT & Fri 2018-08-10 20:41:51 PDT
00:50 <+yitz> So ... as of so far, I got a coredump every day I've been using it
BItlbee itself appears to not have crashed.
02:32 <+yitz> [2018-02-22 00:19] [ALPM] upgraded irssi (1.1.0-1 -> 1.1.1-1)
02:32 <+yitz> [2018-08-08 15:27] [ALPM] upgraded irssi (1.1.1-1 -> 1.1.1-2)
Script list:
20:57 Loaded scripts:
20:57 ack /home/yitz/.irssi/scripts/autorun/ack.pl
20:57 after /home/yitz/.irssi/scripts/autorun/after.pl
20:57 allwin /home/yitz/.irssi/scripts/autorun/allwin.pl
20:57 bottom /home/yitz/.irssi/scripts/autorun/bottom.pl
20:57 cleanpublic /home/yitz/.irssi/scripts/autorun/cleanpublic.pl
20:57 cron /home/yitz/.irssi/scripts/autorun/cron.pl
20:57 custom_prompt /home/yitz/.irssi/scripts/autorun/custom_prompt.pl
20:57 fifo_remote /home/yitz/.irssi/scripts/autorun/fifo_remote.pl
20:57 hilightwin /home/yitz/.irssi/scripts/autorun/hilightwin.pl
20:57 ident /home/yitz/.irssi/scripts/autorun/ident.pl
20:57 pushover /home/yitz/.irssi/scripts/autorun/pushover.pl
20:57 reorder /home/yitz/.irssi/scripts/autorun/reorder.pl
20:57 scriptassist /home/yitz/.irssi/scripts/autorun/scriptassist.pl
20:57 splitlong /home/yitz/.irssi/scripts/autorun/splitlong.pl
20:57 tab_stop /home/yitz/.irssi/scripts/autorun/tab_stop.pl
20:57 trackbar_z /home/yitz/.irssi/scripts/autorun/trackbar.z.pl
20:57 trigger /home/yitz/.irssi/scripts/autorun/trigger.pl
20:57 uberprompt /home/yitz/.irssi/scripts/autorun/uberprompt.pl
20:57 urllogger /home/yitz/.irssi/scripts/autorun/urllogger.pl
20:57 urlwin /home/yitz/.irssi/scripts/autorun/urlwin.pl
My analysis of the coredump:
#0 0x0000555dfa3cb297 in ?? ()
#1 0x0000555dfa3cb6c5 in textbuffer_view_scroll ()
Frame 0 is view_scroll, likely this line (the second "call" to view_get_linecount, not the first)
| linecount = view_get_linecount(view, *lines); |
view_get_linecount is a macro defined at the top of the same file
| #define view_get_linecount_hidden(view, line) \ | |
| textbuffer_view_get_line_cache(view, line)->count | |
| #define view_line_is_hidden(view, line) \ | |
| (((line)->info.level & (view)->hidden_level) != 0) | |
| #define view_get_linecount(view, line) \ | |
| (view_line_is_hidden(view, line) ? 0 : view_get_linecount_hidden(view, line)) |
The crash looks like it's in the ->count of textbuffer_view_get_line_cache(view, line)->count:
(gdb) disas $pc-0x20,+0x40 Dump of assembler code from 0x555dfa3cb277 to 0x555dfa3cb2b7: 0x0000555dfa3cb277: test esi,esi 0x0000555dfa3cb279: je 0x555dfa3cb1b0 0x0000555dfa3cb27f: mov QWORD PTR [rbx],rsi 0x0000555dfa3cb282: mov eax,DWORD PTR [rsi+0x18] 0x0000555dfa3cb285: test DWORD PTR [r12+0x68],eax 0x0000555dfa3cb28a: jne 0x555dfa3cb270 0x0000555dfa3cb28c: mov rdi,r12 0x0000555dfa3cb28f: call 0x555dfa3c9f40 <textbuffer_view_get_line_cache> 0x0000555dfa3cb294: mov edx,r15d => 0x0000555dfa3cb297: mov eax,DWORD PTR [rax+0x8] 0x0000555dfa3cb29a: sub edx,eax 0x0000555dfa3cb29c: add eax,r14d 0x0000555dfa3cb29f: test eax,eax 0x0000555dfa3cb2a1: jg 0x555dfa3cb2d0 0x0000555dfa3cb2a3: mov r15d,edx 0x0000555dfa3cb2a6: je 0x555dfa3cb1b0 0x0000555dfa3cb2ac: mov r14d,eax 0x0000555dfa3cb2af: jmp 0x555dfa3cb270 0x0000555dfa3cb2b1: nop DWORD PTR [rax+0x0] End of assembler dump. (gdb) p $rax $14 = 0
The definition of textbuffer_view_get_line_cache
| /* Return line cache */ | |
| LINE_CACHE_REC *textbuffer_view_get_line_cache(TEXT_BUFFER_VIEW_REC *view, | |
| LINE_REC *line) | |
| { | |
| LINE_CACHE_REC *cache; | |
| g_assert(view != NULL); | |
| g_assert(line != NULL); | |
| cache = g_hash_table_lookup(view->cache->line_cache, line); | |
| if (cache == NULL) | |
| cache = view_update_line_cache(view, line); | |
| else | |
| cache->last_access = time(NULL); | |
| return cache; | |
| } |
Stuff pending figuring out from the core dump:
- what key was pressed (my best guess is something like pageup but i can't get more than a ~ from the coredump)
- the view and line parameters to textbuffer_view_get_line_cache()
- whether any of them are null, whether the lookup of view->cache->line_cache failed
- anything in the status window (glib warnings)
- anything in rawlogs