[Lldb-commits] [PATCH] D128201: [lldb][windows] Fix crash on getting nested exception

[Alvin Wong via Phabricator via lldb-commits]

alvinhochun created this revision.
Herald added a subscriber: mstorsjo.
Herald added a project: All.
alvinhochun requested review of this revision.
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.

LLDB tries to follow `EXCEPTION_RECORD::ExceptionRecord` to follow the
nested exception chain. In practice this code just causes Access
Violation whenever there is a nested exception. Since there does not
appear to be any code in LLDB that is actually using the nested
exceptions, this change just disables the crashing code and adds a
comment to clarify the reason.

Fixes https://github.com/mstorsjo/llvm-mingw/issues/292


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D128201

Files:
  lldb/source/Plugins/Process/Windows/Common/ExceptionRecord.h


Index: lldb/source/Plugins/Process/Windows/Common/ExceptionRecord.h
===================================================================
--- lldb/source/Plugins/Process/Windows/Common/ExceptionRecord.h
+++ lldb/source/Plugins/Process/Windows/Common/ExceptionRecord.h
@@ -27,9 +27,19 @@
   ExceptionRecord(const EXCEPTION_RECORD &record, lldb::tid_t thread_id) {
     m_code = record.ExceptionCode;
     m_continuable = (record.ExceptionFlags == 0);
+    // This marks some old code which tried to parse the nested exception. In
+    // practice, this code just causes Access Violation. I suspect
+    // `ExceptionRecord` here actually points to the address space of the
+    // debuggee process. However, I did not manage to find any official or
+    // unofficial reference that clarifies this point. If anyone would like to
+    // reimplement this, please also keep in mind to check how this behaves when
+    // debugging a WOW64 process. I suspect you may have to use the explicit
+    // `EXCEPTION_RECORD32` and `EXCEPTION_RECORD64` structs.
+#if 0
     if (record.ExceptionRecord)
       m_next_exception.reset(
           new ExceptionRecord(*record.ExceptionRecord, thread_id));
+#endif
     m_exception_addr = reinterpret_cast<lldb::addr_t>(record.ExceptionAddress);
     m_thread_id = thread_id;
     m_arguments.assign(record.ExceptionInformation,
@@ -39,17 +49,18 @@
   // MINIDUMP_EXCEPTIONs are almost identical to EXCEPTION_RECORDs.
   ExceptionRecord(const MINIDUMP_EXCEPTION &record, lldb::tid_t thread_id)
       : m_code(record.ExceptionCode), m_continuable(record.ExceptionFlags == 0),
-        m_next_exception(nullptr),
         m_exception_addr(static_cast<lldb::addr_t>(record.ExceptionAddress)),
         m_thread_id(thread_id),
         m_arguments(record.ExceptionInformation,
                     record.ExceptionInformation + record.NumberParameters) {
+#if 0
     // Set up link to nested exception.
     if (record.ExceptionRecord) {
       m_next_exception.reset(new ExceptionRecord(
           *reinterpret_cast<const MINIDUMP_EXCEPTION *>(record.ExceptionRecord),
           thread_id));
     }
+#endif
   }
 
   virtual ~ExceptionRecord() {}
@@ -57,9 +68,11 @@
   DWORD
   GetExceptionCode() const { return m_code; }
   bool IsContinuable() const { return m_continuable; }
+#if 0
   const ExceptionRecord *GetNextException() const {
     return m_next_exception.get();
   }
+#endif
   lldb::addr_t GetExceptionAddress() const { return m_exception_addr; }
 
   lldb::tid_t GetThreadID() const { return m_thread_id; }
@@ -69,7 +82,9 @@
 private:
   DWORD m_code;
   bool m_continuable;
+#if 0
   std::shared_ptr<ExceptionRecord> m_next_exception;
+#endif
   lldb::addr_t m_exception_addr;
   lldb::tid_t m_thread_id;
   std::vector<ULONG_PTR> m_arguments;


-------------- next part --------------
A non-text attachment was scrubbed...
Name: D128201.438376.patch
Type: text/x-patch
Size: 2791 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20220620/66beb0d2/attachment.bin>