Bug 254615 - lldb: Crashes debugging editors/poke (WITH_DEBUG=1) using ncurses
Summary: lldb: Crashes debugging editors/poke (WITH_DEBUG=1) using ncurses
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 13.0-STABLE
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-toolchain (Nobody)
URL:
Keywords: crash, needs-qa
Depends on:
Blocks:
 
Reported: 2021-03-27 22:12 UTC by Juraj Lutter
Modified: 2021-04-19 12:38 UTC (History)
4 users (show)

See Also:
koobs: maintainer-feedback? (bapt)
koobs: maintainer-feedback? (emaste)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Juraj Lutter freebsd_committer 2021-03-27 22:12:12 UTC
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)
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2021-03-29 02:33:09 UTC
^Triage: assign.

Note to submitter: the architecture might (or might not) be relevant here.
Comment 2 Kubilay Kocak freebsd_committer freebsd_triage 2021-03-29 02:54:00 UTC
^Triage: Loop Baptiste for potential insight
Comment 3 Kubilay Kocak freebsd_committer freebsd_triage 2021-03-29 02:59:39 UTC
@Reporter

- What is the exact FreeBSD version
- Is the debugged software available publicly for reproduction?
Comment 4 Juraj Lutter freebsd_committer 2021-03-30 06:32:54 UTC
- 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.
Comment 5 Kubilay Kocak freebsd_committer freebsd_triage 2021-04-19 03:32:15 UTC
^Triage: Ed may be able to advise here, loop in for feedback
Comment 6 Alex S 2021-04-19 12:34:11 UTC
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
Comment 7 Juraj Lutter freebsd_committer 2021-04-19 12:38:19 UTC
(In reply to Alex S from comment #6)
Yes, it was, and I was also participating in that discussion.

Followup is needed.