> 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 >> STOPPED_DUE_TO_EXC_BAD_ACCESS) >> 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 handler. Jim > > > 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 lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
