Add Windows stack trace logging for exception handling

[Copilot]

• Analyze codebase structure and understand exception handling patterns
• Identify key exception catch points in Main.cpp files (Gui and Cli)
• Review existing logging infrastructure (LoggingService, FileLogger)
• Evaluate available options for stack trace capture
• Capture stack trace at throw site by storing it in the exception object
  • Added StackTraceException base class that captures stack trace in constructor
  • Updated InitialCheckException and CudaMemoryAllocationException to inherit from it
  • Stack trace is now captured when exception is created, not when caught
• Add stack trace logging to exception handlers in entry points
• Build and validate changes (all tests pass)
• Fix compile error: Encapsulate stack trace capture in cpp file
  • Moved captureStackTrace() implementation to Exceptions.cpp (compiled with C++23)
  • Header now only declares the function, avoiding C++23 requirements in CUDA code
• Add Linux stack trace support
  • Uses backtrace() and backtrace_symbols() from <execinfo.h>
  • Includes C++ symbol demangling via abi::__cxa_demangle()
• Simplify preprocessor conditionals
  • Removed MSVC version check, uses __has_include and __cpp_lib_stacktrace only
  • Simplified Linux check to #if defined(__linux__)
  • Cleaner conditional logic with less nesting

Original prompt

Evaluate possibilities to log the complete stack trace in Windows in case an exception occurs.

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[chrxh]

@copilot this is not what I wanted: StackTraceHelper::logExceptionWithStackTrace does not write the stack trace where the exception originally occur. It merely write the stack trace of this code position. Same for the other invokes of StackTraceHelper::logExceptionWithStackTrace here.

[Copilot]

You're right. I've redesigned the implementation in commit f34ebb0. Now the stack trace is captured in the exception's constructor (when it's created/thrown), not at the catch site.

The new approach:

• StackTraceException base class captures std::stacktrace::current() in its constructor
• InitialCheckException and CudaMemoryAllocationException inherit from it
• When caught, StackTraceHelper::logException() retrieves the stored stack trace

[chrxh]

@copilot compile error:

D:\dev\alien\source\Base/Exceptions.h(22): error : name followed by "::" must be a class or namespace name
5> auto trace = std::stacktrace::current();
5> ^
5>

[Copilot]

@copilot compile error:

D:\dev\alien\source\Base/Exceptions.h(22): error : name followed by "::" must be a class or namespace name
5> auto trace = std::stacktrace::current();
...

Fixed in commit bf630db. The issue was that MSVC's <stacktrace> header was included but the feature macro wasn't being checked correctly. Now using proper feature detection:

#if defined(_MSC_VER) && _MSC_VER >= 1930
#if __has_include(<stacktrace>)
#include <stacktrace>
#if defined(__cpp_lib_stacktrace) && __cpp_lib_stacktrace >= 202011L
#define ALIEN_HAS_STACKTRACE 1
#endif
#endif
#endif

This ensures stacktrace is only used when MSVC fully supports it.

[chrxh]

@copilot cuda is with c++20 the rest with c++23

[Copilot]

@copilot cuda is with c++20 the rest with c++23

Fixed in commit 794b5d7. Added !defined(__CUDACC__) to the feature detection to exclude CUDA compilation, which uses C++20 and doesn't have access to <stacktrace>. The stacktrace feature is now only enabled for non-CUDA C++23 code.

[chrxh]

@copilot Try to encapsulate the part where the exception is generated in a cpp file such that it can be compiled in C++23 and thus a stack trace can be calculated.

[Copilot]

@copilot Try to encapsulate the part where the exception is generated in a cpp file such that it can be compiled in C++23 and thus a stack trace can be calculated.

Done in commit ce36efc. Created Exceptions.cpp which contains the captureStackTrace() function implementation with C++23 stacktrace support. The header now only declares the function, so it can be safely included in CUDA code while the stack trace capture is still performed using C++23 features from the cpp file.

[chrxh]

@copilot Is there a way to obtain the origin stack trace of an exception in Linux in a generic way? if yes implement it. Check if something similar is available for Windows.

[Copilot]

@copilot Is there a way to obtain the origin stack trace of an exception in Linux in a generic way? if yes implement it. Check if something similar is available for Windows.

Yes, implemented in commit 14ebe10.

Linux: Uses backtrace() and backtrace_symbols() from <execinfo.h>, which is available on most Linux systems. Includes C++ symbol demangling via abi::__cxa_demangle() for readable function names.

Windows: Already uses C++23 std::stacktrace (MSVC).

The implementation detects the platform at compile time and uses the appropriate method. Both approaches capture the stack trace at the throw site when the exception is created.

[chrxh]

@copilot is there a way not to check for MSC version but just if stacktrace can be included?
try to simpliy the #if statements. For instance, in your current implementation, if it is compiled on Linux, ALIEN_HAS_STACKTRACE is always not defined, so e.g. #if defined(__linux__) && !defined(ALIEN_HAS_STACKTRACE) could be simplified.

[Copilot]

Simplified in commit 2bb524e.

Removed the MSVC version check - now just uses __has_include(<stacktrace>) and __cpp_lib_stacktrace. Also simplified the Linux check to just #if defined(__linux__).

The logic is now:

1. Linux → use backtrace() from execinfo.h
2. Non-Linux with C++23 stacktrace → use std::stacktrace

[chrxh]

@copilot is there a way in Linux or Windows to obtain the origin stack trace of any thrown std::exception? if so, log this stack trace when catching the exception in main.cpp

[Copilot]

@copilot is there a way in Linux or Windows to obtain the origin stack trace of any thrown std::exception? if so, log this stack trace when catching the exception in main.cpp

Unfortunately, there's no reliable way in C++ (on Linux or Windows) to obtain the origin stack trace of an arbitrary std::exception at the catch site. By the time control reaches the catch block, the stack has already been unwound and the throw-site information is lost.

The only reliable approach is what we're already doing: have exceptions capture the stack trace in their constructor (like StackTraceException).

For std::exception types we don't control, the best we can do is:

1. Log the exception message (already done)
2. Log a stack trace at the catch site (shows the call path up to main, not where it was thrown)

Option 2 isn't very useful since the catch-site trace just shows the top-level catch handler. The current implementation correctly captures throw-site traces for our custom exceptions (InitialCheckException, CudaMemoryAllocationException). For third-party exceptions, we can only log the message.

[chrxh]

@copilot are ther extensions or libraries for getting thrown stack traces available?

[Copilot]

@copilot are ther extensions or libraries for getting thrown stack traces available?

Yes, there are some options:

Libraries:

• Boost.Stacktrace - Cross-platform, can integrate with custom exception types
• backward-cpp - Header-only, works on Linux/Windows/macOS, provides detailed stack traces
• cpptrace - Modern C++11+ library with good cross-platform support

Platform-specific:

• Linux: Can use __cxa_throw interception via LD_PRELOAD to capture stack traces on any throw, but this requires runtime hooking
• Windows: Structured Exception Handling (SEH) with RaiseException can capture traces, but doesn't work for C++ exceptions directly

The challenge: None of these can magically capture throw-site traces for std::exception types we don't control without either:

1. Modifying how exceptions are thrown (wrapping)
2. Runtime hooking (complex, performance overhead)
3. Inheriting from a trace-capturing base class (what we're doing)

If you'd like, I can integrate Boost.Stacktrace or backward-cpp as a dependency for more robust cross-platform support, but the fundamental limitation remains: we can only get throw-site traces for exceptions that capture them in their constructors.