Files
qelectrotech-source-mirror/sources/logging
ispyisail dad99fb08c Say what crashed and where in Windows crash reports
A Windows crash report held the header and the log and nothing else: no
exception, no address, no stack (issue #1179, two reports that could not
be traced). It now also has:

- the exception, with its name ("access violation", "stack overflow"...)
- where it happened, as module+offset, and for an access violation the
  address that was read or written
- a backtrace, one module+offset per frame, walked with the unwind
  tables every x64 image carries (RtlLookupFunctionEntry and
  RtlVirtualUnwind): no dbghelp, no symbols, no allocation. addr2line
  on the same build turns each offset into a function and line.

The dump is written by a reporter thread started at install(), not on
the crashing thread, which may have no stack left or hold the loader
lock. The crashing thread waits for it for at most ten seconds.

Two kinds of crash wrote no report at all before and now do:
- abort() (std::terminate(), a failed assert): no SEH exception, so
  SIGABRT is handled as well.
- qFatal(): Qt ends it with TerminateProcess() on Windows, so the
  message handler now asks for the dump once the message is logged.
  Elsewhere reportFatal() does nothing; SIGABRT follows there.

Tested with a cross-built RelWithDebInfo build under Wine 11, crashing
on purpose from inside the event loop: a null pointer, a call through a
null pointer, a stack overflow, abort() and qFatal(). Each report
resolved to the line that crashed. Linux reports are unchanged.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-01 07:40:57 +13:00
..