While debugging something that was using ncurses, lldb crashed: Process 73969 stopped * thread #1, name = 'poke', stop reason = step in frame #0: 0x00000008009edcac libncursesw.so.9`tputs(string="4f0fdc740005be8be730c32600000000", affcnt=1, outc=(libtextstyle.so.0`out_char at term-ostream.oo.c:1198)) at lib_tputs.c:443:5 440 NCURSES_EXPORT(int) 441 tputs(const char *string, int affcnt, int (*outc) (int)) 442 { -> 443 SetSafeOutcWrapper(outc); 444 return NCURSES_SP_NAME(tputs) (NCURSES_SP_ARGx string, affcnt, _nc_outc_wrapper); 445 } 446 #endif (lldb) p string (const char *) $31 = 0x00000008018a0210 "4f0fdc740005be8be730c32600000000" (lldb) p affcnt (int) $32 = 1 (lldb) p outc (int (*)(int)) $33 = 0x0000000800424c40 (libtextstyle.so.0`out_char at term-ostream.oo.c:1198) (lldb) s Program aborted due to an unhandled Error: Error value was Success. (Note: Success values must still be checked prior to being destroyed). PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the crash backtrace. #0 0x00000000037e0abe PrintStackTrace /poudriere/src-work/githead/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:564:13 #1 0x00000000037def75 RunSignalHandlers /poudriere/src-work/githead/contrib/llvm-project/llvm/lib/Support/Signals.cpp:69:18 #2 0x00000000037e1030 SignalHandler /poudriere/src-work/githead/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:0:3 #3 0x0000000804724e90 handle_signal /poudriere/src-work/githead/lib/libthr/thread/thr_sig.c:0:3 Abort (core dumped)
^Triage: assign. Note to submitter: the architecture might (or might not) be relevant here.
^Triage: Loop Baptiste for potential insight
@Reporter - What is the exact FreeBSD version - Is the debugged software available publicly for reproduction?
- System is FreeBSD b13.owbuild.lan 13.0-STABLE FreeBSD 13.0-STABLE #5 stable/13-85ad493677a2 - Software is editors/poke where a crash occurs in tputs(). The port is being built with WITH_DEBUG=1 to keep debug symbols.
^Triage: Ed may be able to advise here, loop in for feedback
I'll note here for completeness, a similar issue was discussed on freebsd-current: https://markmail.org/thread/7hbfz2uozk6byulx. The bison segfault is not particularly difficult to run into. We just need need a grammar file triggering warnings and a moderately fancy terminal (xfce4-terminal in my case): % fetch https://raw.githubusercontent.com/wine-mirror/wine/master/tools/wrc/parser.y % bison -p parser_ -o parser.tab.c -d parser.y parser.y: warning: 5 shift/reduce conflicts [ ... (lldb) bt * thread #1, name = 'bison', stop reason = signal SIGSEGV * frame #0: 0x0000000000000000 frame #1: 0x000000080082030a libncursesw.so.9`delay_output_sp(sp=0x0000000000000000, ms=<unavailable>) at lib_tputs.c:104:6 frame #2: 0x0000000800820b81 libncursesw.so.9`tputs_sp [inlined] delay_output(ms=<unavailable>) at lib_tputs.c:116:12 frame #3: 0x0000000800820b72 libncursesw.so.9`tputs_sp(sp=<unavailable>, string="", affcnt=1, outc=<unavailable>) at lib_tputs.c:422 frame #4: 0x0000000800820cfb libncursesw.so.9`tputs(string="72dd85a30005c0527fa7ae2e00000000", affcnt=1, outc=(libtextstyle.so.0`___lldb_unnamed_symbol150$$libtextstyle.so.0)) at lib_tputs.c:444:12 frame #5: 0x000000080030b81c libtextstyle.so.0`___lldb_unnamed_symbol149$$libtextstyle.so.0 + 92 frame #6: 0x000000080030c25f libtextstyle.so.0`___lldb_unnamed_symbol152$$libtextstyle.so.0 + 943 frame #7: 0x000000080030bb2f libtextstyle.so.0`___lldb_unnamed_symbol151$$libtextstyle.so.0 + 543 frame #8: 0x0000000800309790 libtextstyle.so.0`___lldb_unnamed_symbol125$$libtextstyle.so.0 + 32 frame #9: 0x0000000000223250 bison`___lldb_unnamed_symbol42$$bison + 1024 frame #10: 0x0000000000222e2f bison`___lldb_unnamed_symbol41$$bison + 127 frame #11: 0x0000000000224d43 bison`___lldb_unnamed_symbol57$$bison + 1139 frame #12: 0x000000000023641f bison`___lldb_unnamed_symbol194$$bison + 559 frame #13: 0x000000000021eeb0 bison`___lldb_unnamed_symbol1007$$bison + 256
(In reply to Alex S from comment #6) Yes, it was, and I was also participating in that discussion. Followup is needed.
Apparently, all the action is in bug 256731.
^Triage: Setting dependent, close pending issue 256731 comment 13