更新到macOS Mojave后崩溃[NSWindow orderFrontRegardless]

Question

更新到Mojave后得到这个奇怪的崩溃.

没有做任何特别的事情,只是创建一个NSWindow并打电话 orderFrontRegardless

之前一直很好.

1   libsystem_platform.dylib            0x00007fff6610ab5d _sigtramp + 29
2   ???                                 0x0000000000000000 0x0 + 0
3   CoreFoundation                      0x00007fff39b00bb6 __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 12
4   CoreFoundation                      0x00007fff39b00b30 ___CFXRegistrationPost_block_invoke + 63
5   CoreFoundation                      0x00007fff39b00a9a _CFXRegistrationPost + 404
6   CoreFoundation                      0x00007fff39b08f48 ___CFXNotificationPost_block_invoke + 87
7   CoreFoundation                      0x00007fff39a71994 -[_CFXNotificationRegistrar find:object:observer:enumerator:] + 1642
8   CoreFoundation                      0x00007fff39a70d47 _CFXNotificationPost + 732
9   Foundation                          0x00007fff3bdab217 -[NSNotificationCenter postNotificationName:object:userInfo:] + 66
10  AppKit                              0x00007fff3720538b -[NSWindow _setFrameCommon:display:stashSize:] + 3090
11  AppKit                              0x00007fff37204766 -[NSWindow _setFrame:display:allowImplicitAnimation:stashSize:] + 192
12  AppKit                              0x00007fff3720469f -[NSWindow setFrame:display:] + 51
13  AppKit                              0x00007fff3727aca9 -[NSWindow _reallyDoOrderWindowAboveOrBelow:relativeTo:findKey:forCounter:force:isModal:] + 1336
14  AppKit                              0x00007fff372792a0 -[NSWindow _doOrderWindow:relativeTo:findKey:forCounter:force:isModal:] + 283
15  AppKit                              0x00007fff37a0dce9 -[NSWindow orderFrontRegardless] + 40

代码(它是一个控制台应用程序):

NSWindow *window =    [[NSWindow alloc] initWithContentRect:windowRect
styleMask:windowStyle
backing:NSBackingStoreBuffered
defer:NO];

// Since Snow Leopard, programs without application bundles and Info.plist
// files don't get a menubar and can't be brought to the front unless the
// presentation option is changed
[NSApp setActivationPolicy:NSApplicationActivationPolicyRegular];

 [NSApp activateIgnoringOtherApps:YES];
 [window makeKeyAndOrderFront:nil];

Answer 1

您表明您正在取消引用未初始化的指针。但是，我从您发布的报告中没有足够的信息来知道这是（也许是幸运的）空，还是只是垃圾内存。我假设在某个时刻您因EXC_BAD_ACCESS(信号等效为SIGBUS或SIGSEGV，具体取决于)而崩溃。

这里的关键信息是您安装了信号处理程序。

信号处理程序通常（但并非总是）使用相同的堆栈在崩溃线程上运行。内核使用该函数注入处理_sigtramp程序。信号传递后，当前堆栈状态包含跟踪错误内存访问所需的信息。但是，您的信号处理程序被调用了。所以它运行了，并改变了堆栈。

然后，您的信号处理程序以某种方式完成。可以配置信号处理程序，sigaction以便将进程状态恢复到崩溃事件之前的时刻。我不确定你的信号处理程序是如何配置的。但最终，我将假设该进程被允许退出。

此时，Apple 的 ReportCrash 将被触发，并且将捕获所有线程的回溯，无论您的信号处理程序将其置于何种状态。这很重要，因为这不一定是崩溃状态。

增加了复杂性，从信号处理程序中使用backtrace_symbols_fd根本不安全。异步安全性具有挑战性，并且从信号处理程序运行代码非常困难。您可以安全地做的事情很少。另外，我很确定这backtrace_symbols_fd会分配内存。因此，如果您的崩溃发生在内存分配器的某个地方（听起来确实如此），那么您肯定面临死锁的风险。从回溯来看，这似乎正是可能发生的事情。查看man sigaction一些详细信息。

更糟糕的是，在信号处理程序框架上展开堆栈特别具有挑战性，因为内核运行处理程序的魔力很大。这就是为什么那个???框架在那里。

总结：

如果没有安装信号处理程序，Apple 的 ReportCrash 将为崩溃线程生成正确的（并且可能有用的）回溯。

您包含的堆栈跟踪不是很好，但很难确切知道原因。似乎backtrace_symbols_fd没有很好地展开，可能是因为它不适合从信号处理程序中使用，也可能是因为它没有针对这种情况的足够好的堆栈展开机制支持。但是，如果没有更多信息，我很难知道。不过，令我惊讶的是顶部框架是_sigtramp。这没有多大意义。这让我觉得信号处理程序本身可能出了问题。您的处理程序可能会第二次崩溃。

Apple 的回溯（例如，由 ReportCrash、 backtrace_symbols_fdReportCrash 或 NSThread生成的）绝对可以信任，前提是您在安全上下文中小心使用它们。callStackReturnAddresses