[Lldb-commits] [PATCH] D128410: [lldb] Add a testcase for nested exceptions on Windows

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

In D128410#3604927 <https://reviews.llvm.org/D128410#3604927>, @alvinhochun wrote:

> It may be possible to stuff a pointer to an `EXCEPTION_RECORD` into another `EXCEPTION_RECORD` and use `RtlRaiseException` to generate the exception, but you'll have to test how it actually works.

That would be pretty cool.



================
Comment at: lldb/test/Shell/Process/Windows/wndproc_exception.cpp:7
+// RUN: %clangxx_host -o %t.exe -luser32 -v -- %s
+// RUN: %lldb -f %t.exe -o "run"
+
----------------
alvinhochun wrote:
> alvinhochun wrote:
> > mstorsjo wrote:
> > > mstorsjo wrote:
> > > > labath wrote:
> > > > > Is there something reasonable we could assert here? The process exit status for instance?
> > > > This in itself requires the `%lldb` command to succeed - the exit status for each `RUN` line needs to be successful (unless a failure is expected and it can be inverted with the `not` command). Or did you mean checking the process exit code of the child process (that intentionally does crash)?
> > > > 
> > > > When this test case is run, it prints the following to the terminal:
> > > > ```
> > > > (lldb) run
> > > > Process 3168 stopped
> > > > * thread #1, stop reason = Exception 0xc000041d encountered at address 0x7ff68e6f1227
> > > >     frame #0: 0x00007ff68e6f1227 wndproc_exception.cpp.tmp.exe
> > > > ->  0x7ff68e6f1227: movl   $0x1, (%rax)
> > > >     0x7ff68e6f122d: movq   $0x0, 0x50(%rsp)
> > > >     0x7ff68e6f1236: jmp    0x7ff68e6f1259
> > > >     0x7ff68e6f123b: movq   0x48(%rsp), %r9
> > > > Process 3168 launched: 'C:\dev\llvm-project\llvm\build-msvc\tools\lldb\test\Shell\Process\Windows\Output\wndproc_exception.cpp.tmp.exe' (x86_64)
> > > > ```
> > > > I guess we could check for `Exception 0xc000041d encountered` maybe, although I'm afraid of making the testcase unnecessarily brittle too.
> > > If running with lldb-server enabled, it prints a different exception code, `0xc0000005` (which is `STATUS_ACCESS_VIOLATION`) which probably is the proper nested exception, while without lldb-server, it prints `0xc000041d` (`STATUS_FATAL_USER_CALLBACK_EXCEPTION`).
> > > 
> > > So for the purpose of this testcase, just to make sure that it doesn't crash in this case, it'd be better to not specify exactly which exception code is to be returned.
> > It may be that lldb-server is catching the first chance `STATUS_ACCESS_VIOLATION` exception before the exception is passed to the exception handler...
> If you test with windbg or gdb, you will get the access violation / sigsegv first, and only after continuing the debuggee you will get the `0xc000041d` exception.
> This in itself requires the `%lldb` command to succeed - the exit status for each `RUN` line needs to be successful (unless a failure is expected and it can be inverted with the `not` command). Or did you mean checking the process exit code of the child process (that intentionally does crash)?

Yes, that's what I mean, but I don't think we need to match the precise exception number (although probably only one of those two numbers is really "correct"). We could just match the `stop reason = Exception` part.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D128410/new/

https://reviews.llvm.org/D128410