MacOS下Visual Studio Code中LLDB调试器无法捕获TRAP信号的技术问询

I’ve been working on a C++ project and hit a frustrating debugging roadblock specific to macOS when using Visual Studio Code with the default LLDB integration. Here’s the full breakdown:

Problem Details #

When running my executable (xmlpgtest_doccopy) outside the debugger, it triggers an assertion and raises a TRAP signal, with this error output:

Apr 29 08:25:21 ./xmlpgtest_doccopy[39308] : : Assert:[/Users/davidbien/dv/xmlp/xmlpinc/xml_tag.h:49],void ns_xmlp::xml_tag<ns_xmlp::xml_traits<ns_lxo::_l_transport_file<char8_t>, false, false>>::AssertValid(const ns_xmlp::xml_tag::_TyThis *) const [t_TyXmlTraits = ns_xmlp::xml_traits<ns_lxo::_l_transport_file<char8_t>, false, false>]: _ptagParent == m_ptagParent. [1] 39308 trace trap ./xmlpgtest_doccopy ~/dv/xmlp/unittests/unittest1.xml

But when debugging in VS Code with LLDB, the debugger just hangs when the signal is triggered. If I click the "Pause" button, the session terminates right away with this message:

The program '/Users/davidbien/dv/xmlp/build/xmlpgtest_doccopy' has exited with code 0 (0x00000000)

This issue doesn’t pop up on Linux (using VS Code + GDB) or Windows (using MSVC debugger). I’m running Clang 12 and the matching LLDB version from the latest Xcode release, and with 28 years of C++ development experience, I’ve tested a range of potential fixes.

My Cross-Platform Debug Break Macro #

First, here’s the debug break implementation I’m using to trigger interrupts across compilers:

#ifdef _MSC_VER
#define DEBUG_BREAK __debugbreak()
#elif defined( __clang__ )
#if __has_builtin(__builtin_debugtrap)
#define DEBUG_BREAK __builtin_debugtrap()
#else
#define DEBUG_BREAK __builtin_trap()
#endif
#elif defined( __GNUC__ )
#define DEBUG_BREAK __builtin_trap()
#else
#error Need to know the OS/compiler for breaking into the debugger.
#endif

Troubleshooting Steps I Tried #

I’ve exhausted several standard fixes with no luck:

• Swapped TRAP signals for access violations (AVs) to trigger the debugger—same hanging behavior persisted
• Ran the LLDB command process handle -p TRUE -s TRUE SIGTRAP to configure SIGTRAP to pass, stop, and notify the debugger—no change in behavior
• Added explicit code to force an AV before the debug break: *((volatile char*)0) = 0xba; DEBUG_BREAK;—the debugger still hung instead of catching the signal

Root Cause & Resolution #

After testing alternative tools, I found that the CodeLLDB extension for VS Code properly catches the assertion-triggered interrupts and even provides useful features like viewing active variant types. This led me to conclude the issue isn’t with LLDB itself, but specifically with the lldb-mi component distributed by Microsoft for the default VS Code LLDB integration.

I’m planning to file a bug report for this issue with the relevant team.

内容的提问来源于stack exchange，提问作者David Bien