SIGSEGV backtrace with libc is repeating entries

Question

I was using libunwind prior to moving to the available execinfo backtrace. After implementing a new backtrace I was enjoying it until I removed the libunwind from the project and did a full rebuild.

Now my backtrace function refuses to produce a normal result from the SIGSEGV ( I know its not safe to do the backtrace from there ), but why was it working fine before?

I will post the output for now with incorrect results. First backtrace is an exception, second, deliberate SIGSEGV - the expected result would be a trace to the __libc_start_main

I remember I read something about signal stacking as problem?

ERROR: FatalException detected: Unable to find string Id STR_PATIENT_LIST in configuration xml file at gui.cpp +1224
===========================================
FATAL STACK BACKTRACE
[bt]: (1 ) [0x1aed350]
[bt]: (2 ) ./ambusergm(getStrIdElement(char const*)+0x1a4) [0xa3d6c]
[bt]: (3 ) ./ambusergm(getCurrentLanguageStr(char const*)+0x18) [0xa4968]
[bt]: (4 ) ./ambusergm(createDialogs+0x70) [0xa4ce4]
[bt]: (5 ) ./ambusergm(handleMenuUniqueIdEvent+0x1278) [0x90030]
[bt]: (6 ) ./ambusergm(menuSelectionInvoke(int, int)+0x278) [0xa14ac]
[bt]: (7 ) ./ambusergm(reloadMenu+0xe0) [0xab51c]
[bt]: (8 ) ./ambusergm(main+0x638) [0x600b0]
[bt]: (9 ) /lib/libc.so.6(__libc_start_main+0x120) [0x402f7fd4]
===========================================

signal 11 (Segmentation fault), address is (nil) from 0x166398
===========================================
CRASH STACK BACKTRACE
[bt]: (1 ) ./ambusergm(MessageBoxDlg::Setup(MessageBoxType, int, int, int, int, wchar_t const*, wchar_t const*)+0x10) [0x166398]
[bt]: (2 ) /lib/libc.so.6(__default_rt_sa_restorer_v2+0) [0x4030e630]
[bt]: (3 ) ./ambusergm(MessageBoxDlg::Setup(MessageBoxType, int, int, int, int, wchar_t const*, wchar_t const*)+0x10) [0x166398]

... repeated to the last entry

[bt]: (49) ./ambusergm(MessageBoxDlg::Setup(MessageBoxType, int, int, int, int, wchar_t const*, wchar_t const*)+0x10) [0x166398]
===========================================

Answer 1

The problem happened to be that the app seg faulted in the exception handler itself and recursevly called the segfault signal handler