Bug 248745 - /usr/bin/lldb: Dumps core when attempting to print variable with `p`, `fr v` works
Summary: /usr/bin/lldb: Dumps core when attempting to print variable with `p`, `fr v` ...
Status: In Progress
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 12.1-STABLE
Hardware: Any Any
: --- Affects Some People
Assignee: Dimitry Andric
URL: https://reviews.llvm.org/D86355
Keywords: crash
Depends on:
Blocks:
 
Reported: 2020-08-18 22:47 UTC by Dmitri Goutnik
Modified: 2020-08-24 02:42 UTC (History)
2 users (show)

See Also:
koobs: mfc-stable12?


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dmitri Goutnik freebsd_committer 2020-08-18 22:47:47 UTC
$ uname -v
FreeBSD 12.1-STABLE r364355

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

$ cat <<EOD > testcase.c
int main(int argc, char *argv[])
{
    return 0;
}
EOD

$ cc -O0 -g testcase.c

$ /usr/bin/lldb a.out
...
(lldb) b main
Breakpoint 1: where = a.out`main + 20 at testcase.c:5:5, address = 0x00000000002018d4
(lldb) r
Process 27744 launching
Process 27744 launched: '/home/dg/tmp/a.out' (x86_64)
Process 27744 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 1.1
    frame #0: 0x00000000002018d4 a.out`main(argc=1, argv=0x00007fffffffe480) at testcase.c:5:5
   2
   3    int main(int argc, char *argv[])
   4    {
-> 5        return 0;
   6    }
(lldb) p argc
Program aborted due to an unhandled Error:
Error value was Success. (Note: Success values must still be checked prior to being destroyed).
Stack dump:
0.      Program arguments: /usr/bin/lldb a.out
1.      HandleCommand(command = "p argc")
#0 0x0000000003b848de PrintStackTrace /usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:564:13
#1 0x0000000003b82b37 RunSignalHandlers /usr/src/contrib/llvm-project/llvm/lib/Support/Signals.cpp:69:18
#2 0x0000000003b851d0 SignalHandler /usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:0:3
#3 0x000000080477dd22 handle_signal /usr/src/lib/libthr/thread/thr_sig.c:0:3
Abort trap (core dumped)

What's interesting is that `fr v` works fine:

...
(lldb) b main
Breakpoint 1: where = a.out`main + 20 at testcase.c:5:5, address = 0x00000000002018d4
(lldb) r
Process 28540 launching
Process 28540 launched: '/home/dg/tmp/a.out' (x86_64)
Process 28540 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 1.1
    frame #0: 0x00000000002018d4 a.out`main(argc=1, argv=0x00007fffffffe480) at testcase.c:5:5
   2
   3    int main(int argc, char *argv[])
   4    {
-> 5        return 0;
   6    }
(lldb) fr v argc
(int) argc = 1
(lldb)
Comment 1 commit-hook freebsd_committer 2020-08-22 10:56:00 UTC
A commit references this bug:

Author: dim
Date: Sat Aug 22 10:55:55 UTC 2020
New revision: 364480
URL: https://svnweb.freebsd.org/changeset/base/364480

Log:
  Merge commit 1ce07cd614be from llvm git (by me):

    Instantiate Error in Target::GetEntryPointAddress() only when
    necessary

    When Target::GetEntryPointAddress() calls
    exe_module->GetObjectFile()->GetEntryPointAddress(), and the returned
    entry_addr is valid, it can immediately be returned.

    However, just before that, an llvm::Error value has been setup, but
    in this case it is not consumed before returning, like is done
    further below in the function.

    In https://bugs.freebsd.org/248745 we got a bug report for this,
    where a very simple test case aborts and dumps core:

    * thread #1, name = 'testcase', stop reason = breakpoint 1.1
        frame #0: 0x00000000002018d4 testcase`main(argc=1, argv=0x00007fffffffea18) at testcase.c:3:5
       1    int main(int argc, char *argv[])
       2    {
    -> 3        return 0;
       4    }
    (lldb) p argc
    Program aborted due to an unhandled Error:
    Error value was Success. (Note: Success values must still be checked prior to being destroyed).

    Thread 1 received signal SIGABRT, Aborted.
    thr_kill () at thr_kill.S:3
    3       thr_kill.S: No such file or directory.
    (gdb) bt
    #0  thr_kill () at thr_kill.S:3
    #1  0x00000008049a0004 in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52
    #2  0x0000000804916229 in abort () at /usr/src/lib/libc/stdlib/abort.c:67
    #3  0x000000000451b5f5 in fatalUncheckedError () at /usr/src/contrib/llvm-project/llvm/lib/Support/Error.cpp:112
    #4  0x00000000019cf008 in GetEntryPointAddress () at /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Error.h:267
    #5  0x0000000001bccbd8 in ConstructorSetup () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:67
    #6  0x0000000001bcd2c0 in ThreadPlanCallFunction () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:114
    #7  0x00000000020076d4 in InferiorCallMmap () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/Utility/InferiorCallPOSIX.cpp:97
    #8  0x0000000001f4be33 in DoAllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/FreeBSD/ProcessFreeBSD.cpp:604
    #9  0x0000000001fe51b9 in AllocatePage () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:347
    #10 0x0000000001fe5385 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:383
    #11 0x0000000001974da2 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2301
    #12 CanJIT () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2331
    #13 0x0000000001a1bf3d in Evaluate () at /usr/src/contrib/llvm-project/lldb/source/Expression/UserExpression.cpp:190
    #14 0x00000000019ce7a2 in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Target/Target.cpp:2372
    #15 0x0000000001ad784c in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:414
    #16 0x0000000001ad86ae in DoExecute () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:646
    #17 0x0000000001a5e3ed in Execute () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandObject.cpp:1003
    #18 0x0000000001a6c4a3 in HandleCommand () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:1762
    #19 0x0000000001a6f98c in IOHandlerInputComplete () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2760
    #20 0x0000000001a90b08 in Run () at /usr/src/contrib/llvm-project/lldb/source/Core/IOHandler.cpp:548
    #21 0x00000000019a6c6a in ExecuteIOHandlers () at /usr/src/contrib/llvm-project/lldb/source/Core/Debugger.cpp:903
    #22 0x0000000001a70337 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2946
    #23 0x0000000001d9d812 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/API/SBDebugger.cpp:1169
    #24 0x0000000001918be8 in MainLoop () at /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:675
    #25 0x000000000191a114 in main () at /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:890

    Fix the incorrect error catch by only instantiating an Error object
    if it is necessary.

    Reviewed By: JDevlieghere

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

  This should fix lldb aborting as described in the scenario above.

  Reported by:	dmgk
  PR:		248745

Changes:
  head/contrib/llvm-project/lldb/source/Target/Target.cpp