gtkmm-3.0 Segmentation Fault in g_sequence_iter_get_sequence and g_sequence_iter_is_end() with corrupted backtrace

I am developing a C++ application using gtkmm-3.0 on

root@colibri-imx6ull-15625953:~# cat /etc/os-release ID=tdx-x11 NAME="TDX X11" VERSION="5.7.1-devel-20221213120311+build.0 (dunfell)" VERSION_ID=5.7.1-devel-20221213120311-build.0 PRETTY_NAME="TDX X11 5.7.1-devel-20221213120311+build.0 (dunfell)" DISTRO_CODENAME="dunfell"

My application is crashing with a segmentation fault, and I am struggling to find the source because the stack appears corrupted in GDB.

The Crash:
When the crash occurs, GDB shows the following:

"nextGEN" received signal SIGSEGV, Segmentation fault. 0x769c5dac in g_sequence_iter_get_sequence () from /usr/lib/libglib-2.0.so.0 (gdb) bt #0 0x769c5dac in g_sequence_iter_get_sequence () from /usr/lib/libglib-2.0.so.0 #1 0x7610d254 in ?? () from /usr/lib/libgtk-3.so.0 Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Environment:

Language: C++ Library: gtkmm-3.0 / glibmm-2.4 Compiler Flags: -g3 -O0 (Optimization disabled for debugging)

What I have tried:

Full Backtrace: I ran thread apply all bt, but all threads (including those involving liblog4cplus and poll) show a "corrupt stack" or stop at ?? in system libraries.

Debug Flags: I confirmed the app is compiled with -g3, but since the crash happens inside libglib, the backtrace doesn't point back to my source code.

Context: My application uses [mention if you use Gtk::TreeView, Gtk::ListBox, or background threads].

Question:
Because the backtrace is stopped due to a "corrupt stack," I cannot see which part of my C++ code is passing the invalid iterator or sequence to GLib.

Are there specific common patterns in gtkmm (like invalid TreeIter or Gtk::TreeModel::Iterator usage) that trigger g_sequence_iter_get_sequence crashes?

How can I force GDB to unwind the stack past the ?? symbols in the GTK/GLib libraries to see my own function calls?