【问题标题】:C++ program crashes before main when run from Xcode (but OK from the command line)从 Xcode 运行时,C++ 程序在 main 之前崩溃(但从命令行可以)
【发布时间】:2016-02-03 12:00:06
【问题描述】:

以下程序在调试模式和发布模式下在 OS X 10.10.5 (Yosemite) 上从 Xcode 6.3.2 运行时在调用 main 之前崩溃。

#include <boost/network/uri.hpp>

int main() 
{ 
    boost::network::uri::uri url; 
    url << boost::network::uri::scheme("http"); 
    return 0; 
}

应用程序使用 cpp-netlib v0.11.2。 cpp-netlib v0.11.0 不会发生崩溃。

Xcode 显示一个显示“Xcode 意外退出”的窗口,有 3 个选项 - “忽略”、“报告”和“重新打开”。如果我选择“报告”,则会打开另一个窗口,其中包含更多信息。我在下面包含了它的一个 sn-p。

请注意,如果我从命令行运行应用程序,则不会发生崩溃。

我如何找出确切的原因是什么?

Process:               Xcode [10190]
Path:                  /Applications/Xcode.app/Contents/MacOS/Xcode
Identifier:            com.apple.dt.Xcode
Version:               6.3.2 (7718)
Build Info:            IDEFrameworks-7718000000000000~2
App Item ID:           497799835
App External ID:       812404257
Code Type:             X86-64 (Native)
Parent Process:        ??? [1]
Responsible:           Xcode [10190]
User ID:               501

Date/Time:             2015-11-03 10:47:56.517 +0000
OS Version:            Mac OS X 10.10.5 (14F27)
Report Version:        11
Anonymous UUID:        FC1A7EB1-54F4-E985-58AC-A097ABAD05B9

Sleep/Wake UUID:       E1BB13F1-08A2-47C5-BF97-CF63B595B260

Time Awake Since Boot: 1200000 seconds
Time Since Wake:       1100 seconds

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_CRASH (SIGILL)
Exception Codes:       0x0000000000000000, 0x0000000000000000

Application Specific Information:
ProductBuildVersion: 6D2105

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib          0x00007fff8fa364de mach_msg_trap + 10
1   libsystem_kernel.dylib          0x00007fff8fa3564f mach_msg + 55
2   com.apple.CoreFoundation        0x00007fff93e43eb4 __CFRunLoopServiceMachPort + 212
3   com.apple.CoreFoundation        0x00007fff93e4337b __CFRunLoopRun + 1371
4   com.apple.CoreFoundation        0x00007fff93e42bd8 CFRunLoopRunSpecific + 296
5   com.apple.HIToolbox             0x00007fff9829256f RunCurrentEventLoopInMode + 235
6   com.apple.HIToolbox             0x00007fff982922ea ReceiveNextEventCommon + 431
7   com.apple.HIToolbox             0x00007fff9829212b _BlockUntilNextEventMatchingListInModeWithFilter + 71
8   com.apple.AppKit                0x00007fff95e678ab _DPSNextEvent + 978
9   com.apple.AppKit                0x00007fff95e66e58 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 346
10  com.apple.dt.DVTKit             0x000000010ce67aaa -[DVTApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 237
11  com.apple.AppKit                0x00007fff95e5caf3 -[NSApplication run] + 594
12  com.apple.AppKit                0x00007fff95dd9244 NSApplicationMain + 1832
13  libdyld.dylib                   0x00007fff8fac15c9 start + 1

Thread 1:: Dispatch queue: com.apple.libdispatch-manager
0   libsystem_kernel.dylib          0x00007fff8fa3c232 kevent64 + 10
1   libdispatch.dylib               0x00007fff8e89ca6a _dispatch_mgr_thread + 52

Thread 2:
0   libsystem_kernel.dylib          0x00007fff8fa3651a semaphore_wait_trap + 10
1   libdispatch.dylib               0x00007fff8e8a3b9c _dispatch_group_wait_slow + 218
2   com.apple.CFNetwork             0x00007fff942347be -[NSHost resolveCurrentHostWithHandler:] + 707
3   com.apple.CFNetwork             0x00007fff9423440c __18-[NSHost resolve:]_block_invoke + 298
4   libdispatch.dylib               0x00007fff8e89e323 _dispatch_call_block_and_release + 12
5   libdispatch.dylib               0x00007fff8e899c13 _dispatch_client_callout + 8
6   libdispatch.dylib               0x00007fff8e89d365 _dispatch_queue_drain + 1100
7   libdispatch.dylib               0x00007fff8e89eecc _dispatch_queue_invoke + 202
8   libdispatch.dylib               0x00007fff8e89c6b7 _dispatch_root_queue_drain + 463
9   libdispatch.dylib               0x00007fff8e8aafe4 _dispatch_worker_thread3 + 91
10  libsystem_pthread.dylib         0x00007fff8fdada9d _pthread_wqthread + 729
11  libsystem_pthread.dylib         0x00007fff8fdab3dd start_wqthread + 13

【问题讨论】:

  • 鉴于这不是 Cocoa 应用程序,我不明白 runloop 是如何进入其中的。堆栈跟踪与代码完全不匹配。
  • 我听不懂那个崩溃报告。
  • 你可以看到NSApplicationMain参与了;在通常是main() 内唯一调用的 Cocoa 应用程序中。我想说该项目完全配置错误(即损坏),应该被丢弃。
  • @trojanfoe:实际上看起来 Xcode 本身 正在崩溃。 (Xcode 当然是一个 Cocoa 应用程序。)我建议更新一个更新的版本(7.x)。
  • 我看不出项目如何配置错误。如果我将应用程序与 cpp-netlib 的 v0.11.0 链接,那么它运行良好。它也可以从命令行正常运行。

标签: c++ xcode c++11 osx-yosemite cpp-netlib


【解决方案1】:

这是由于调试版本中的符号过长导致 Xcode 无法从调试器加载符号。这已在项目的 master 分支中修复,应该在 0.12.0 版本中修复。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2020-06-22
    • 2011-01-31
    • 1970-01-01
    • 2017-08-09
    • 2019-12-28
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多