Question Details

No question body available.

Tags

c++ debugging clion terminate static-initialization

Answers (1)

February 24, 2026 Score: 4 Rep: 138,788 Quality: Medium Completeness: 100%

(Thanks @cigien, @MarekR, @pptaszni for the comments which helped me solve this.)

tl;dr: Your IDE is "hiding" the stack; use gdb directly to get it.

Static initialization code does have a stack which a debugger can track and report. And, indeed, gdb should do so. However, it seems CLion's code is mishandling the situation of exceptions thrown in such code, and failing to show you the stack in the stack window.

So, what can you do?

First make sure you've built your repository (and dependencies) in debug mode.

Then, in your CLion, make sure a breakpoint will be triggered on exception: On the menus, choose Run | View Breakpoints..., then in the dialog, on the tree control, ensure 'Exception Breakpoints' is checked.

Now, when you hit the breakpoint, look at CLion's debugging pane on the bottom. The left side has the empty stack trace which is your problem. On the right side, switch from the 'Variables' view to the 'GDB' view; you will get a gdb command prompt, e.g.:

[Thread debugging using libthreaddb enabled]
Using host libthreaddb library "/lib64/libthreaddb.so.1".

Breakpoint 3, somecodegoeshere () at /path/to/source/file:123 123 const auto globalvalue = functioncall(); The target architecture is set to "auto" (currently "i386:x86-64").

Breakpoint 2, 0x00007ffff12345 in cxathrow () from /usr/lib64/libstdc++.so.6 (gdb)

Type bt at the prompt; this gives you the stack trace ("backtrace" in gdb parlance). That's it.


Alternatively, you could fall back on using gdb directly, in a terminal. Do you remember how this works? If not, read How to debug using gdb?. Now,

  1. Invoke gdb to run your executable (e.g. gdb --args /path/to/executable firstarg second_arg).
  2. Issue the command catch throw for a breakpoint on each exception.
  3. step once. You should get the exception thrown.
  4. bt or backtrace to get the backtrace

Once you've figured out the path through the code, you could set a breakpoint at a point you get to before triggering the exception, and then proceed with "normal" debugging, except that you may need to issue bt commands to get stack visibility.