Let me move this to the forum since it's generally interesting:
Right; most odd \- still a sanitizer would catch stack corruption too I guess\. For me at least I get serious problems unwinding stacks in the Kit process locally too even after a banal assert\.
Possibly we need to build that with frame-pointers enabled?
Since online is x86_64 only and we have an embarrassment of registers there (compared to x86 at least) - I'd trade debug-ability for quite a lot. Then again ... I guess my problems occur in ENABLE_DEBUG mode where adding -fno-omit-frame-pointer would not hurt production - and oddly everything is fine if gdb catches the signal - but not if gdb is connected afterwards during the 20 second sleep for that.
Still it would of course be nicer to work out why after our signal handler triggering stack unwinding fails so horribly in many cases, but that's probably beyond us:
Suggests that costs 5-10% in the real world - and sometimes much more.