Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ngets shall exit on EOF #23

Closed
wants to merge 1 commit into from
Closed

ngets shall exit on EOF #23

wants to merge 1 commit into from

Conversation

int0dh
Copy link

@int0dh int0dh commented Mar 19, 2015

Hi All,

I`ve noted that ngets() from libstand starts consuming CPU like mad when
EOF appears on stdin. I see this issue with bhyveload when forwarding "user input" over pipe.
Here is the simpliest program to reproduce:

cat > ./bget.c

include <stdint.h>

include <unistd.h>

include <stdio.h>

include <sys/file.h>

int main()
{
char str[512];

    for (;;) {
            ngets(str, sizeof(str));
            if (str[0] == '\n')
                    break;
    }
    return 0;

}

$ echo "balbalbalabl" | ./bget &
$

You will see bget consuming CPU in ngets() reading EOF, basically because getchar()
returns EOF again and again. Suggested patch fixes the problem.

@bdrewery
Copy link
Member

bdrewery commented Mar 4, 2016

@bsdimp
Copy link
Member

bsdimp commented Mar 1, 2017

Since this has moved to bugzilla, I'm going to close this pull request. It also seems to have stalled there though. Maybe this email will illicit a response and it will get going again.

@bsdimp bsdimp closed this Mar 1, 2017
kev009 pushed a commit to kev009/freebsd that referenced this pull request Aug 22, 2018
uqs pushed a commit that referenced this pull request Aug 22, 2020
  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


git-svn-id: svn+ssh://svn.freebsd.org/base/head@364480 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
uqs pushed a commit that referenced this pull request Aug 22, 2020
  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
bdrewery pushed a commit to bdrewery/freebsd that referenced this pull request Sep 25, 2020
  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 freebsd#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
  freebsd#1  0x00000008049a0004 in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52
  freebsd#2  0x0000000804916229 in abort () at /usr/src/lib/libc/stdlib/abort.c:67
  freebsd#3  0x000000000451b5f5 in fatalUncheckedError () at /usr/src/contrib/llvm-project/llvm/lib/Support/Error.cpp:112
  freebsd#4  0x00000000019cf008 in GetEntryPointAddress () at /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Error.h:267
  freebsd#5  0x0000000001bccbd8 in ConstructorSetup () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:67
  freebsd#6  0x0000000001bcd2c0 in ThreadPlanCallFunction () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:114
  freebsd#7  0x00000000020076d4 in InferiorCallMmap () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/Utility/InferiorCallPOSIX.cpp:97
  freebsd#8  0x0000000001f4be33 in DoAllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/FreeBSD/ProcessFreeBSD.cpp:604
  freebsd#9  0x0000000001fe51b9 in AllocatePage () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:347
  freebsd#10 0x0000000001fe5385 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:383
  freebsd#11 0x0000000001974da2 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2301
  freebsd#12 CanJIT () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2331
  freebsd#13 0x0000000001a1bf3d in Evaluate () at /usr/src/contrib/llvm-project/lldb/source/Expression/UserExpression.cpp:190
  freebsd#14 0x00000000019ce7a2 in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Target/Target.cpp:2372
  freebsd#15 0x0000000001ad784c in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:414
  freebsd#16 0x0000000001ad86ae in DoExecute () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:646
  freebsd#17 0x0000000001a5e3ed in Execute () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandObject.cpp:1003
  freebsd#18 0x0000000001a6c4a3 in HandleCommand () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:1762
  freebsd#19 0x0000000001a6f98c in IOHandlerInputComplete () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2760
  freebsd#20 0x0000000001a90b08 in Run () at /usr/src/contrib/llvm-project/lldb/source/Core/IOHandler.cpp:548
  freebsd#21 0x00000000019a6c6a in ExecuteIOHandlers () at /usr/src/contrib/llvm-project/lldb/source/Core/Debugger.cpp:903
  freebsd#22 0x0000000001a70337 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2946
  freebsd#23 0x0000000001d9d812 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/API/SBDebugger.cpp:1169
  freebsd#24 0x0000000001918be8 in MainLoop () at /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:675
  freebsd#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


git-svn-id: svn+ssh://svn.freebsd.org/base/head@364480 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
uqs pushed a commit that referenced this pull request Oct 31, 2020
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
uqs pushed a commit that referenced this pull request Oct 31, 2020
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
mat813 pushed a commit to mat813/freebsd that referenced this pull request Nov 28, 2020
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 freebsd#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
  freebsd#1  0x00000008049a0004 in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52
  freebsd#2  0x0000000804916229 in abort () at /usr/src/lib/libc/stdlib/abort.c:67
  freebsd#3  0x000000000451b5f5 in fatalUncheckedError () at /usr/src/contrib/llvm-project/llvm/lib/Support/Error.cpp:112
  freebsd#4  0x00000000019cf008 in GetEntryPointAddress () at /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Error.h:267
  freebsd#5  0x0000000001bccbd8 in ConstructorSetup () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:67
  freebsd#6  0x0000000001bcd2c0 in ThreadPlanCallFunction () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:114
  freebsd#7  0x00000000020076d4 in InferiorCallMmap () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/Utility/InferiorCallPOSIX.cpp:97
  freebsd#8  0x0000000001f4be33 in DoAllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/FreeBSD/ProcessFreeBSD.cpp:604
  freebsd#9  0x0000000001fe51b9 in AllocatePage () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:347
  freebsd#10 0x0000000001fe5385 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:383
  freebsd#11 0x0000000001974da2 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2301
  freebsd#12 CanJIT () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2331
  freebsd#13 0x0000000001a1bf3d in Evaluate () at /usr/src/contrib/llvm-project/lldb/source/Expression/UserExpression.cpp:190
  freebsd#14 0x00000000019ce7a2 in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Target/Target.cpp:2372
  freebsd#15 0x0000000001ad784c in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:414
  freebsd#16 0x0000000001ad86ae in DoExecute () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:646
  freebsd#17 0x0000000001a5e3ed in Execute () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandObject.cpp:1003
  freebsd#18 0x0000000001a6c4a3 in HandleCommand () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:1762
  freebsd#19 0x0000000001a6f98c in IOHandlerInputComplete () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2760
  freebsd#20 0x0000000001a90b08 in Run () at /usr/src/contrib/llvm-project/lldb/source/Core/IOHandler.cpp:548
  freebsd#21 0x00000000019a6c6a in ExecuteIOHandlers () at /usr/src/contrib/llvm-project/lldb/source/Core/Debugger.cpp:903
  freebsd#22 0x0000000001a70337 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2946
  freebsd#23 0x0000000001d9d812 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/API/SBDebugger.cpp:1169
  freebsd#24 0x0000000001918be8 in MainLoop () at /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:675
  freebsd#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


git-svn-id: https://svn.freebsd.org/base/stable/11@367228 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
mat813 pushed a commit to mat813/freebsd that referenced this pull request Nov 28, 2020
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 freebsd#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
  freebsd#1  0x00000008049a0004 in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52
  freebsd#2  0x0000000804916229 in abort () at /usr/src/lib/libc/stdlib/abort.c:67
  freebsd#3  0x000000000451b5f5 in fatalUncheckedError () at /usr/src/contrib/llvm-project/llvm/lib/Support/Error.cpp:112
  freebsd#4  0x00000000019cf008 in GetEntryPointAddress () at /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Error.h:267
  freebsd#5  0x0000000001bccbd8 in ConstructorSetup () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:67
  freebsd#6  0x0000000001bcd2c0 in ThreadPlanCallFunction () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:114
  freebsd#7  0x00000000020076d4 in InferiorCallMmap () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/Utility/InferiorCallPOSIX.cpp:97
  freebsd#8  0x0000000001f4be33 in DoAllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/FreeBSD/ProcessFreeBSD.cpp:604
  freebsd#9  0x0000000001fe51b9 in AllocatePage () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:347
  freebsd#10 0x0000000001fe5385 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:383
  freebsd#11 0x0000000001974da2 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2301
  freebsd#12 CanJIT () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2331
  freebsd#13 0x0000000001a1bf3d in Evaluate () at /usr/src/contrib/llvm-project/lldb/source/Expression/UserExpression.cpp:190
  freebsd#14 0x00000000019ce7a2 in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Target/Target.cpp:2372
  freebsd#15 0x0000000001ad784c in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:414
  freebsd#16 0x0000000001ad86ae in DoExecute () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:646
  freebsd#17 0x0000000001a5e3ed in Execute () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandObject.cpp:1003
  freebsd#18 0x0000000001a6c4a3 in HandleCommand () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:1762
  freebsd#19 0x0000000001a6f98c in IOHandlerInputComplete () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2760
  freebsd#20 0x0000000001a90b08 in Run () at /usr/src/contrib/llvm-project/lldb/source/Core/IOHandler.cpp:548
  freebsd#21 0x00000000019a6c6a in ExecuteIOHandlers () at /usr/src/contrib/llvm-project/lldb/source/Core/Debugger.cpp:903
  freebsd#22 0x0000000001a70337 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2946
  freebsd#23 0x0000000001d9d812 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/API/SBDebugger.cpp:1169
  freebsd#24 0x0000000001918be8 in MainLoop () at /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:675
  freebsd#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


git-svn-id: https://svn.freebsd.org/base/stable/12@367228 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
hardenedbsd-services referenced this pull request in HardenedBSD/hardenedBSD Dec 27, 2020
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
uqs pushed a commit that referenced this pull request Dec 30, 2020
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
freebsd-git pushed a commit that referenced this pull request Apr 6, 2021
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
Approved by:	so
Security:	FreeBSD-EN-21:07.lldb

(cherry picked from commit eb41eed)
mhorne added a commit to mhorne/freebsd that referenced this pull request Feb 21, 2022
Boottrace is a facility for capturing trace events during boot and
shutdown. This includes kernel initialization, as well as rc. It has
been used by NetApp internally for several years, for catching and
diagnosing slow devices or subsystems. It is driven from userspace by
sysctl interface, and the output is a human-readable log of events
(kern.boottrace.log).

This commit adds the core boottrace functionality implementing these
interfaces. Adding the trace annotations themselves to kernel and
userland will happen in follow-up commits. A future commit will also add
a boottrace(4) man page.

For now, boottrace is unconditionally compiled into the kernel but
disabled by default. It can be enabled by setting the
kern.boottrace.enabled tunable to 1 in loader.conf(5).

There is an existing boot-time event tracing facility, which can be
compiled into the kernel with 'options TSLOG'. While there is some
functional overlap between this and boottrace, they are distinct. TSLOG
is suitable for generating detailed timing information and flamegraphs,
and has been used to great success by cperciva@ to diagnose and reduce
the overall system boot time. Boottrace aims to more quickly provide an
overview of timing and resource usage of the boot (and shutdown) process
to a sysadmin who requires this knowledge.

Sponsored by:	NetApp, Inc.
Sponsored by:	Klara, Inc.
X-NetApp-PR:	freebsd#23
Differential Revision:	https://reviews.freebsd.org/D30184
mhorne added a commit to mhorne/freebsd that referenced this pull request Feb 21, 2022
Add trace events for execution of SYSINITs (both static and dynamically
loaded), and to the various steps in the shutdown/panic/reboot paths.

Sponsored by:	NetApp, Inc.
Sponsored by:	Klara, Inc.
X-NetApp-PR:	freebsd#23
Differential Revision:	https://reviews.freebsd.org/D30187
mhorne added a commit to mhorne/freebsd that referenced this pull request Feb 21, 2022
Add boottrace annotations to record events in init(8), shutdown(8), and
reboot(8).

Sponsored by:	NetApp, Inc.
Sponsored by:	Klara, Inc.
X-NetApp-PR:	freebsd#23
Differential Revision:	https://reviews.freebsd.org/D31928
freebsd-git pushed a commit that referenced this pull request Feb 22, 2022
Boottrace is a facility for capturing trace events during boot and
shutdown. This includes kernel initialization, as well as rc. It has
been used by NetApp internally for several years, for catching and
diagnosing slow devices or subsystems. It is driven from userspace by
sysctl interface, and the output is a human-readable log of events
(kern.boottrace.log).

This commit adds the core boottrace functionality implementing these
interfaces. Adding the trace annotations themselves to kernel and
userland will happen in follow-up commits. A future commit will also add
a boottrace(4) man page.

For now, boottrace is unconditionally compiled into the kernel but
disabled by default. It can be enabled by setting the
kern.boottrace.enabled tunable to 1 in loader.conf(5).

There is an existing boot-time event tracing facility, which can be
compiled into the kernel with 'options TSLOG'. While there is some
functional overlap between this and boottrace, they are distinct. TSLOG
is suitable for generating detailed timing information and flamegraphs,
and has been used to great success by cperciva@ to diagnose and reduce
the overall system boot time. Boottrace aims to more quickly provide an
overview of timing and resource usage of the boot (and shutdown) process
to a sysadmin who requires this knowledge.

Sponsored by:	NetApp, Inc.
Sponsored by:	Klara, Inc.
X-NetApp-PR:	#23
Differential Revision:	https://reviews.freebsd.org/D30184
freebsd-git pushed a commit that referenced this pull request Feb 22, 2022
Add trace events for execution of SYSINITs (both static and dynamically
loaded), and to the various steps in the shutdown/panic/reboot paths.

Sponsored by:	NetApp, Inc.
Sponsored by:	Klara, Inc.
X-NetApp-PR:	#23
Differential Revision:	https://reviews.freebsd.org/D30187
freebsd-git pushed a commit that referenced this pull request Feb 22, 2022
Add boottrace annotations to record events in init(8), shutdown(8), and
reboot(8).

Sponsored by:	NetApp, Inc.
Sponsored by:	Klara, Inc.
X-NetApp-PR:	#23
Differential Revision:	https://reviews.freebsd.org/D31928
zxombie pushed a commit to CTSRD-CHERI/freebsd-morello that referenced this pull request Mar 11, 2022
Boottrace is a facility for capturing trace events during boot and
shutdown. This includes kernel initialization, as well as rc. It has
been used by NetApp internally for several years, for catching and
diagnosing slow devices or subsystems. It is driven from userspace by
sysctl interface, and the output is a human-readable log of events
(kern.boottrace.log).

This commit adds the core boottrace functionality implementing these
interfaces. Adding the trace annotations themselves to kernel and
userland will happen in follow-up commits. A future commit will also add
a boottrace(4) man page.

For now, boottrace is unconditionally compiled into the kernel but
disabled by default. It can be enabled by setting the
kern.boottrace.enabled tunable to 1 in loader.conf(5).

There is an existing boot-time event tracing facility, which can be
compiled into the kernel with 'options TSLOG'. While there is some
functional overlap between this and boottrace, they are distinct. TSLOG
is suitable for generating detailed timing information and flamegraphs,
and has been used to great success by cperciva@ to diagnose and reduce
the overall system boot time. Boottrace aims to more quickly provide an
overview of timing and resource usage of the boot (and shutdown) process
to a sysadmin who requires this knowledge.

Sponsored by:	NetApp, Inc.
Sponsored by:	Klara, Inc.
X-NetApp-PR:	freebsd#23
Differential Revision:	https://reviews.freebsd.org/D30184
zxombie pushed a commit to CTSRD-CHERI/freebsd-morello that referenced this pull request Mar 11, 2022
Add trace events for execution of SYSINITs (both static and dynamically
loaded), and to the various steps in the shutdown/panic/reboot paths.

Sponsored by:	NetApp, Inc.
Sponsored by:	Klara, Inc.
X-NetApp-PR:	freebsd#23
Differential Revision:	https://reviews.freebsd.org/D30187
zxombie pushed a commit to CTSRD-CHERI/freebsd-morello that referenced this pull request Mar 11, 2022
Add boottrace annotations to record events in init(8), shutdown(8), and
reboot(8).

Sponsored by:	NetApp, Inc.
Sponsored by:	Klara, Inc.
X-NetApp-PR:	freebsd#23
Differential Revision:	https://reviews.freebsd.org/D31928
freebsd-git pushed a commit that referenced this pull request Sep 5, 2023
netlink(4) calls back into the driver during detach and it attempts to
start an internal synchronized op recursively, causing an interruptible
hang.  Fix it by failing the ioctl if the VI has been marked as DOOMED
by cxgbe_detach.

Here's the stack for the hang for reference.
 #6  begin_synchronized_op
 #7  cxgbe_media_status
 #8  ifmedia_ioctl
 #9  cxgbe_ioctl
 #10 if_ioctl
 #11 get_operstate_ether
 #12 get_operstate
 #13 dump_iface
 #14 rtnl_handle_ifevent
 #15 rtnl_handle_ifnet_event
 #16 rt_ifmsg
 #17 if_unroute
 #18 if_down
 #19 if_detach_internal
 #20 if_detach
 #21 ether_ifdetach
 #22 cxgbe_vi_detach
 #23 cxgbe_detach
 #24 DEVICE_DETACH

MFC after:	3 days
Sponsored by:	Chelsio Communications
freebsd-git pushed a commit that referenced this pull request Sep 18, 2023
netlink(4) calls back into the driver during detach and it attempts to
start an internal synchronized op recursively, causing an interruptible
hang.  Fix it by failing the ioctl if the VI has been marked as DOOMED
by cxgbe_detach.

Here's the stack for the hang for reference.
 #6  begin_synchronized_op
 #7  cxgbe_media_status
 #8  ifmedia_ioctl
 #9  cxgbe_ioctl
 #10 if_ioctl
 #11 get_operstate_ether
 #12 get_operstate
 #13 dump_iface
 #14 rtnl_handle_ifevent
 #15 rtnl_handle_ifnet_event
 #16 rt_ifmsg
 #17 if_unroute
 #18 if_down
 #19 if_detach_internal
 #20 if_detach
 #21 ether_ifdetach
 #22 cxgbe_vi_detach
 #23 cxgbe_detach
 #24 DEVICE_DETACH

MFC after:	3 days
Sponsored by:	Chelsio Communications

(cherry picked from commit 3814249)
freebsd-git pushed a commit that referenced this pull request Sep 19, 2023
netlink(4) calls back into the driver during detach and it attempts to
start an internal synchronized op recursively, causing an interruptible
hang.  Fix it by failing the ioctl if the VI has been marked as DOOMED
by cxgbe_detach.

Here's the stack for the hang for reference.
 #6  begin_synchronized_op
 #7  cxgbe_media_status
 #8  ifmedia_ioctl
 #9  cxgbe_ioctl
 #10 if_ioctl
 #11 get_operstate_ether
 #12 get_operstate
 #13 dump_iface
 #14 rtnl_handle_ifevent
 #15 rtnl_handle_ifnet_event
 #16 rt_ifmsg
 #17 if_unroute
 #18 if_down
 #19 if_detach_internal
 #20 if_detach
 #21 ether_ifdetach
 #22 cxgbe_vi_detach
 #23 cxgbe_detach
 #24 DEVICE_DETACH

Sponsored by:	Chelsio Communications
Approved by:	re (kib)

(cherry picked from commit 3814249)
(cherry picked from commit 3287f64)
freebsd-git pushed a commit that referenced this pull request Jan 25, 2024
Interesting fixes:
03c83f5 add __cxa_init_primary_exception (#23)
5d8a158 Fix two bugs in __cxa_end_cleanup()
b00c6c5 Insert padding in __cxa_dependent_exception
45ca8b1 Insert padding in __cxa_exception struct for compatibility
f2e5509 Fix unlock in two-word version and add missing comment.
6229590 Add an option for disabling emergency buffers. (#14)
freebsd-git pushed a commit that referenced this pull request Jan 25, 2024
Interesting fixes (* were already cherry-picked):
- 03c83f5 add __cxa_init_primary_exception (#23)
* 5d8a158 Fix two bugs in __cxa_end_cleanup()
* b00c6c5 Insert padding in __cxa_dependent_exception
* 45ca8b1 Insert padding in __cxa_exception struct for compatibility
* f2e5509 Fix unlock in two-word version and add missing comment.
- 6229590 Add an option for disabling emergency buffers. (#14)

MFC after:	2 weeks
freebsd-git pushed a commit that referenced this pull request Feb 8, 2024
Interesting fixes (* were already cherry-picked):
- 03c83f5 add __cxa_init_primary_exception (#23)
* 5d8a158 Fix two bugs in __cxa_end_cleanup()
* b00c6c5 Insert padding in __cxa_dependent_exception
* 45ca8b1 Insert padding in __cxa_exception struct for compatibility
* f2e5509 Fix unlock in two-word version and add missing comment.
- 6229590 Add an option for disabling emergency buffers. (#14)

MFC after:	2 weeks

(cherry picked from commit ecf4106)
freebsd-git pushed a commit that referenced this pull request Feb 8, 2024
Interesting fixes (* were already cherry-picked):
- 03c83f5 add __cxa_init_primary_exception (#23)
* 5d8a158 Fix two bugs in __cxa_end_cleanup()
* b00c6c5 Insert padding in __cxa_dependent_exception
* 45ca8b1 Insert padding in __cxa_exception struct for compatibility
* f2e5509 Fix unlock in two-word version and add missing comment.
- 6229590 Add an option for disabling emergency buffers. (#14)

MFC after:	2 weeks

(cherry picked from commit ecf4106)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants