alvinhochun added a comment. > Any reason to `#if 0` this instead of just removing it and maybe adding a one > line comment like "nested exceptions are not supported"? So that someone can > git blame that and find this commit with the removal.
I want to leave a clear note explaining what not to do with `record.ExceptionRecord`. In case someone want to implement handling of nested exceptions in the future, they will be more likely to see it and not repeat the mistake. Though I suppose just having the comment is fine and we don't really need to keep all the code in `#if 0`. > If this is not used at all this is academic, but what situation would it be > describing if it did? Is it something like if you had an exception in a > signal handler, that was handling an initial exception? I am not familiar with the inner workings of exception handling on Windows and there aren't any references I could find, so this is just speculation. In the sample program from https://github.com/mstorsjo/llvm-mingw/issues/292#issuecomment-1160239522, I am triggering an Access Violation (segfault) inside WindowProc. An Access Violation will produce the exception 0xc0000005, Debuggers will get a first chance exception at that point. (GDB and WinDbg both break execution on this, but LLDB decides to let the debuggee continue for some reason.) After this, the exception is passed to an exception handler if there is one. Because WindowProc is called by Windows, there seems to have an exception handler internally. For whatever reason it then decides to throw its own exception 0xc000041d (it seems undocumented but does have a message: "An unhandled exception was encountered during a user callback."). I suspect here the nested exception would contain info about the original exception (Access Violation 0xc0000005). There seems to be an undocumented `NtRaiseException@12` function that is used to raise the exception with a `EXCEPTION_RECORD` directly (which can contain a nested exception). The normal `RaiseException` API in kernel32 only allows specifying the exception code, flag and arguments. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D128201/new/ https://reviews.llvm.org/D128201 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
