> On Aug 8, 2017, at 12:02 AM, Pavel Labath via Phabricator via lldb-commits 
> <lldb-commits@lists.llvm.org> wrote:
> labath added a comment.
> In https://reviews.llvm.org/D35223#834050, @emaste wrote:
>> With this patch I observed three new failures on FreeBSD and three new 
>> unexpected passes on FreeBSD. An example of a new failure:
>>  ======================================================================
>>  FAIL: test_inferior_crashing_expr_step_and_expr_dwarf 
>> (TestInferiorCrashing.CrashingInferiorTestCase)
>>     Test that lldb expressions work before and after stepping after a crash.
>>  ----------------------------------------------------------------------
>>  Traceback (most recent call last):
>>    File 
>> "/tank/emaste/src/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbtest.py",
>>  line 1732, in dwarf_test_method
>>      return attrvalue(self)
>>    File 
>> "/tank/emaste/src/llvm/tools/lldb/packages/Python/lldbsuite/test/decorators.py",
>>  line 110, in wrapper
>>      func(*args, **kwargs)
>>    File 
>> "/tank/emaste/src/llvm/tools/lldb/packages/Python/lldbsuite/test/functionalities/inferior-crashing/TestInferiorCrashing.py",
>>  line 82, in test_inferior_crashing_expr_step_and_expr
>>      self.inferior_crashing_expr_step_expr()
>>    File 
>> "/tank/emaste/src/llvm/tools/lldb/packages/Python/lldbsuite/test/functionalities/inferior-crashing/TestInferiorCrashing.py",
>>  line 249, in inferior_crashing_expr_step_expr
>>      self.check_stop_reason()
>>    File 
>> "/tank/emaste/src/llvm/tools/lldb/packages/Python/lldbsuite/test/functionalities/inferior-crashing/TestInferiorCrashing.py",
>>  line 93, in check_stop_reason
>>  AssertionError: 0 != 1 : Process should be stopped due to bad access 
>> exception
>>  Config=x86_64-/usr/bin/cc
>>  ----------------------------------------------------------------------
>>  Ran 7 tests in 4.320s
>> From lldbsuite/test/lldbutil.py:
>>  def is_thread_crashed(test, thread):
>>      """In the test suite we dereference a null pointer to simulate a crash. 
>> The way this is
>>      reported depends on the platform."""
>>      if test.platformIsDarwin():
>>          return thread.GetStopReason(
>>          ) == lldb.eStopReasonException and "EXC_BAD_ACCESS" in 
>> thread.GetStopDescription(100)
>>      elif test.getPlatform() == "linux":
>>          return thread.GetStopReason() == lldb.eStopReasonSignal and 
>> thread.GetStopReasonDataAtIndex(
>>              0) == 
>> thread.GetProcess().GetUnixSignals().GetSignalNumberFromName("SIGSEGV")
>>      else:
>>          return "invalid address" in thread.GetStopDescription(100)
>> Presumably we want the second case to apply on FreeBSD as well when this 
>> patch is in, although I don't see why the existing else case shouldn't 
>> continue to work correctly.
> Actually, I think you probably need to extend the `@skipIfLinux` to apply to 
> freebsd as well. The reason is that the test is doing something which goes 
> fundamentally against this patch -- it expects that "step" after a "crash" is 
> a no-op, whereas the new behavior will be to let the process continue (and 
> probably exit, unless it has a SEGV handler). That behavior may make sense 
> for mach exceptions, but I don't think we should try to make posix signals 
> emulate that behavior.

Just to be clear, the behavior doesn't make sense for mach exceptions either.  
A darwin program running outside the debugger will get an EXC_BAD_ACCESS Mach 
Exception, but if that exception is unhandled at the thread & task levels the 
system handler will convert it to a BSD SIGSEGV and that will get dispatched to 
the appropriate signal handler.  So darwin and linux really should behave the 
same way in this respect.  The fact that it doesn't is a bug, so it's a little 
odd that we have a test that codifies a bug.  

For those interested, the problem is that the port you have to forward the 
exception to to trigger the Exception->Signal conversion is a privileged port, 
and lldb doesn't have permissions to send to it.  I have an idea about how to 
work around this, but I'm not 100% sure it will work and this doesn't affect 
very many folks so trying it out it hasn't bubbled to the top of my queue yet.

Anyway, stepping after a crash should either cause the program to exit, or to 
end up in the signal handler.  The macOS behavior is really wrong.  This test 
would be useful on linux too - ensuring that hitting a signal doesn't mess up 
lldb's notion of the program state.  The test isn't written right to test this 
situation on Linux, but you could add a signal handler to the main.c and in 
this test set a breakpoint there and assert that the step after the crash 
actually triggers a breakpoint in the signal handler, and you can then that run 
expressions.  If you wanted to baby lldb along, you would do the same check as 
the plain step case and excuse darwin it's inability to get into the signal 


> Repository:
>  rL LLVM
> https://reviews.llvm.org/D35223
> _______________________________________________
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

lldb-commits mailing list

Reply via email to