Bug 253881 - /usr/bin/lldb: Unable to backtrace a core dump
Summary: /usr/bin/lldb: Unable to backtrace a core dump
Status: In Progress
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: CURRENT
Hardware: amd64 Any
: --- Affects Only Me
Assignee: Dimitry Andric
URL:
Keywords:
: 257829 (view as bug list)
Depends on:
Blocks:
 
Reported: 2021-02-26 21:56 UTC by Dmitri Goutnik
Modified: 2021-12-25 11:58 UTC (History)
3 users (show)

See Also:


Attachments
Fix lldb sometimes throwing a 'unhandled Error' (4.62 KB, patch)
2021-08-15 17:47 UTC, Dimitry Andric
no flags Details | Diff
Fix lldb 11 sometimes throwing a 'unhandled Error' (8.87 KB, patch)
2021-08-16 13:31 UTC, Dimitry Andric
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Dmitri Goutnik freebsd_committer 2021-02-26 21:56:03 UTC
$ uname -v
FreeBSD 14.0-CURRENT #2 main-888ae5725: Fri Feb 26 14:32:59 -05 2021

$ /usr/bin/lldb -v
lldb version 11.0.1 (git@github.com:llvm/llvm-project.git revision llvmorg-11.0.1-0-g43ff75f2c3fe)
  clang revision llvmorg-11.0.1-0-g43ff75f2c3fe
  llvm revision llvmorg-11.0.1-0-g43ff75f2c3fe

$ cc -v
FreeBSD clang version 11.0.1 (git@github.com:llvm/llvm-project.git llvmorg-11.0.1-0-g43ff75f2c3fe)
Target: x86_64-unknown-freebsd14.0
Thread model: posix
InstalledDir: /usr/bin

$ cat <<EOD > testcase.c
#include <signal.h>

int
main(void)
{
    raise(SIGABRT);
}
EOD

$ cc -g testcase.c

$ ./a.out
Abort trap (core dumped)

$ /usr/bin/lldb a.out -c a.out.core
(lldb) target create "a.out" --core "a.out.core"
Core file '/home/dg/tmp/abort/a.out.core' (x86_64) was loaded.

(lldb) bt
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.
Stack dump:
0.      Program arguments: /usr/bin/lldb a.out -c a.out.core
1.      HandleCommand(command = "bt")
#0 0x0000000003b35a0e PrintStackTrace /usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:564:13
#1 0x0000000003b33ea7 RunSignalHandlers /usr/src/contrib/llvm-project/llvm/lib/Support/Signals.cpp:69:18
#2 0x0000000003b35f80 SignalHandler /usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:0:3
#3 0x0000000804cdde52 handle_signal /usr/src/lib/libthr/thread/thr_sig.c:0:3
Abort trap (core dumped)
Comment 1 Dimitry Andric freebsd_committer 2021-03-05 20:33:25 UTC
Interesting, this works just fine for me on 14.0-CURRENT #0 main-n245108-1bf86687c2eb (as of 2021-02-26):

% lldb a.out -c a.out.core
(lldb) target create "a.out" --core "a.out.core"
Core file '/share/dim/bugs/bug253881/a.out.core' (x86_64) was loaded.

(lldb) bt
This version of LLDB has no plugin for the mipsassem language. Inspection of frame variables will be limited.
* thread #1, name = 'a.out', stop reason = signal SIGABRT
  * frame #0: 0x000000080038437a libc.so.7`__sys_thr_kill at thr_kill.S:4
    frame #1: 0x00000008002f90f4 libc.so.7`__raise(s=6) at raise.c:52:10
    frame #2: 0x0000000000201892 a.out`main at testcase.c:6:5
    frame #3: 0x0000000000201690 a.out`_start(ap=<unavailable>, cleanup=<unavailable>) at crt1_c.c:75:7

Is it possible for you to debug the lldb.core file with, say, gdb? :)
Comment 2 ota 2021-08-14 05:20:25 UTC
This lldb's stack trace looks similar to one I just filed - https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253881

For my case, I don't use core file and lldb crashes with "run" command.
My report contains trace from gdb.
Comment 3 Dimitry Andric freebsd_committer 2021-08-15 17:43:28 UTC
*** Bug 257829 has been marked as a duplicate of this bug. ***
Comment 4 Dimitry Andric freebsd_committer 2021-08-15 17:47:49 UTC
Created attachment 227227 [details]
Fix lldb sometimes throwing a 'unhandled Error'

I've identified the problem, which only occurs when LLVM assertions are off (this is default on -STABLE and -RELEASE branches, but it can be turned off on -CURRENT using WITHOUT_LLVM_ASSERTSIONS too), and submitted a fix to upstream as: https://reviews.llvm.org/D108088

Meanwhile, can you please try the attached patch on a recent FreeBSD 14.0 or 13.0 source tree, and see if it resolves the problem for you? (This probably won't apply cleanly on a stable/12 tree.)
Comment 5 ota 2021-08-16 01:12:33 UTC
(In reply to Dimitry Andric from comment #4)

Hunk #1 failed against releng/13.0 unfortunately.
Do you want me to try stable/13?  I will need to setup stable/13, though.
Comment 6 Dimitry Andric freebsd_committer 2021-08-16 13:31:23 UTC
Created attachment 227244 [details]
Fix lldb 11 sometimes throwing a 'unhandled Error'

(In reply to ota from comment #5)

I added this other patch that should apply cleanly on top of the lldb version (11) that is in releng/13.0. Can you please try that one instead?
Comment 7 ota 2021-08-16 15:54:55 UTC
(In reply to Dimitry Andric from comment #6)

The lldb 11 patch applied fine.
I confirmed lldb stopped crashing for the other PR test program with this patch.
Comment 8 commit-hook freebsd_committer 2021-08-16 17:02:19 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/src/commit/?id=c1a540709a83f810aa47380b946552ab20020374

commit c1a540709a83f810aa47380b946552ab20020374
Author:     Dimitry Andric <dim@FreeBSD.org>
AuthorDate: 2021-08-16 16:56:41 +0000
Commit:     Dimitry Andric <dim@FreeBSD.org>
CommitDate: 2021-08-16 16:57:24 +0000

    Apply upstream lldb fix for unhandled Error causing abort

    Merge commit 5033f0793fe6 from llvm git (by Dimitry Andric):

      [lldb] Avoid unhandled Error in TypeSystemMap::GetTypeSystemForLanguage

      When assertions are turned off, the `llvm::Error` value created at the
      start of this function is overwritten using the move-assignment
      operator, but the success value is never checked. Whenever a TypeSystem
      cannot be found or created, this can lead to lldb core dumping with:

          Program aborted due to an unhandled Error:
          Error value was Success. (Note: Success values must still be checked prior to being destroyed).

      Fix this by not creating a `llvm::Error` value in advance, and directly
      returning the result of `llvm::make_error` instead, whenever an error is
      encountered.

      See also: <https://bugs.freebsd.org/253881> and
      <https://bugs.freebsd.org/257829>.

      Reviewed By: teemperor

      Differential Revision: https://reviews.llvm.org/D108088

    Reported by:    dmgk, ota@j.email.ne.jp
    PR:             253881, 257829
    MFC after:      3 days

 .../llvm-project/lldb/source/Symbol/TypeSystem.cpp | 90 +++++++++-------------
 1 file changed, 38 insertions(+), 52 deletions(-)
Comment 9 commit-hook freebsd_committer 2021-08-20 16:22:37 UTC
A commit in branch stable/13 references this bug:

URL: https://cgit.FreeBSD.org/src/commit/?id=a949c6a0d6c83994471e33c8ea60f1509e691f6c

commit a949c6a0d6c83994471e33c8ea60f1509e691f6c
Author:     Dimitry Andric <dim@FreeBSD.org>
AuthorDate: 2021-08-16 16:56:41 +0000
Commit:     Dimitry Andric <dim@FreeBSD.org>
CommitDate: 2021-08-20 16:21:46 +0000

    Apply upstream lldb fix for unhandled Error causing abort

    Merge commit 5033f0793fe6 from llvm git (by Dimitry Andric):

      [lldb] Avoid unhandled Error in TypeSystemMap::GetTypeSystemForLanguage

      When assertions are turned off, the `llvm::Error` value created at the
      start of this function is overwritten using the move-assignment
      operator, but the success value is never checked. Whenever a TypeSystem
      cannot be found or created, this can lead to lldb core dumping with:

          Program aborted due to an unhandled Error:
          Error value was Success. (Note: Success values must still be checked prior to being destroyed).

      Fix this by not creating a `llvm::Error` value in advance, and directly
      returning the result of `llvm::make_error` instead, whenever an error is
      encountered.

      See also: <https://bugs.freebsd.org/253881> and
      <https://bugs.freebsd.org/257829>.

      Reviewed By: teemperor

      Differential Revision: https://reviews.llvm.org/D108088

    Reported by:    dmgk, ota@j.email.ne.jp
    PR:             253881, 257829

    (cherry picked from commit c1a540709a83f810aa47380b946552ab20020374)

 .../llvm-project/lldb/source/Symbol/TypeSystem.cpp | 90 +++++++++-------------
 1 file changed, 38 insertions(+), 52 deletions(-)
Comment 10 commit-hook freebsd_committer 2021-12-25 11:58:07 UTC
A commit in branch stable/12 references this bug:

URL: https://cgit.FreeBSD.org/src/commit/?id=456e2b149ecb1ea5f9e81b9b0733c7ec9526b8c2

commit 456e2b149ecb1ea5f9e81b9b0733c7ec9526b8c2
Author:     Dimitry Andric <dim@FreeBSD.org>
AuthorDate: 2021-08-16 16:56:41 +0000
Commit:     Dimitry Andric <dim@FreeBSD.org>
CommitDate: 2021-12-25 11:51:16 +0000

    Apply upstream lldb fix for unhandled Error causing abort

    Merge commit 5033f0793fe6 from llvm git (by Dimitry Andric):

      [lldb] Avoid unhandled Error in TypeSystemMap::GetTypeSystemForLanguage

      When assertions are turned off, the `llvm::Error` value created at the
      start of this function is overwritten using the move-assignment
      operator, but the success value is never checked. Whenever a TypeSystem
      cannot be found or created, this can lead to lldb core dumping with:

          Program aborted due to an unhandled Error:
          Error value was Success. (Note: Success values must still be checked prior to being destroyed).

      Fix this by not creating a `llvm::Error` value in advance, and directly
      returning the result of `llvm::make_error` instead, whenever an error is
      encountered.

      See also: <https://bugs.freebsd.org/253881> and
      <https://bugs.freebsd.org/257829>.

      Reviewed By: teemperor

      Differential Revision: https://reviews.llvm.org/D108088

    Reported by:    dmgk, ota@j.email.ne.jp
    PR:             253881, 257829
    MFC after:      3 days

    (cherry picked from commit c1a540709a83f810aa47380b946552ab20020374)

 .../llvm-project/lldb/source/Symbol/TypeSystem.cpp | 90 +++++++++-------------
 1 file changed, 38 insertions(+), 52 deletions(-)