c – 崩溃后如何制作“不可能”的堆栈跟踪？

当发生这种情况时,Apple的崩溃报告机制可靠地报告像这样的堆栈跟踪：

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib          0x967f9a6a __pthread_kill + 10
1   libsystem_c.dylib               0x9003dacf pthread_kill + 101
2   libsystem_c.dylib               0x900744f8 abort + 168
3   com.meyersound.VirtualD-Mitri   0x0014438e muscle::CrashSignalHandler(int) + 190
4   libsystem_c.dylib               0x9002886b _sigtramp + 43
5   ???                             0xffffffff 0 + 4294967295
6   com.meyersound.VirtualD-Mitri   0x001442d0 muscle::ParsePortArg(muscle::Message const&,muscle::String const&,unsigned short&,unsigned long) + 80
7   com.meyersound.VirtualD-Mitri   0x005b3393 qnet::RepDBPeer::Pulse(muscle::PulseNode::PulseArgs const&) + 1187
8   com.meyersound.VirtualD-Mitri   0x0015717b muscle::PulseNode::PulseAux(unsigned long long) + 203
9   com.meyersound.VirtualD-Mitri   0x000cfb90 muscle::ReflectServer::ServerProcessLoop() + 3232
10  com.meyersound.VirtualD-Mitri   0x00607c7e dcasldmain(int,char**) + 2222
11  com.meyersound.VirtualD-Mitri   0x0072c14d dmitridmain(int,char**) + 4749
12  com.meyersound.VirtualD-Mitri   0x0000bc3a main + 4938
13  com.meyersound.VirtualD-Mitri   0x000061ab _start + 209
14  com.meyersound.VirtualD-Mitri   0x000060d9 start + 41

这一切都很好,除了(提示怪异的音乐) – 这在逻辑上是不可能的.特别是,我的RepDBPeer :: Pulse()方法不仅不会调用ParsePortArg,因此崩溃进程永远不会在任何地方调用ParsePortArg！ (我把我的所有源代码两次插入以确保)

所以我的问题是,这个堆栈跟踪试图告诉我什么？这很可能是一个线程0的堆栈被严重破坏的情况,以至于堆栈跟踪机制已经脱离轨道并指责一个无辜的旁观者作为罪魁祸首？或者Apple的唤醒机制是否有可能以某种方式将程序计数器“跳”到ParsePortArg()中(由此导致的混乱导致崩溃)？还是还有一些其他更深刻的魔法在这里我甚至无法想象？

有问题的崩溃过程是一个vanilla非GUI后台进程,它是一个由Qt GUI进程生成的子进程,值得的.