我们安装了10.11.3的MacBook Pro。我们用这台机器进行测试。有些东西搞砸了这台机器,以至于我们的一个传统Carbon应用程序无法从Finder打开/启动。该应用程序坐在并在底座上反弹但从未启动。
但是,当我们使用来自我们构建的Cocoa注册实用程序的[NSWorkspace launchApplication]以编程方式启动完全相同的应用程序时,应用程序将始终启动。
尝试使用活动监视器对此失败的启动应用程序进行采样往往不会显示任何内容 - 除了看起来挂起的应用程序通常是在调用一个名为" cantTutThis"的函数。有谁听说过这个?
(注意:在我们所有其他10.11.3系统上,我们还没有看到这个问题) (注2:在没有响应的应用程序面临退出之前,控制台中不会显示任何消息)
Call graph:
2820 Thread_10759 DispatchQueue_1: com.apple.main-thread (serial)
+ 2820 _dyld_start (in dyld) + 71 [0x8fe06047]
+ 2820 dyldbootstrap::start(macho_header const*, int, char const**, long, macho_header const*, unsigned long*) (in dyld) + 427 [0x8fe06231]
+ 2820 dyld::_main(macho_header const*, unsigned long, int, char const**, char const**, char const**, unsigned long*) (in dyld) + 3514 [0x8fe0ac47]
+ 2820 dyld::initializeMainExecutable() (in dyld) + 218 [0x8fe06f7f]
+ 2820 ImageLoader::runInitializers(ImageLoader::LinkContext const&, ImageLoader::InitializerTimingList&) (in dyld) + 79 [0x8fe14ea1]
+ 2820 ImageLoader::processInitializers(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) (in dyld) + 105 [0x8fe14c41]
+ 2820 ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) (in dyld) + 296 [0x8fe14dae]
+ 2820 ImageLoaderMachO::doInitialization(ImageLoader::LinkContext const&) (in dyld) + 64 [0x8fe190a0]
+ 2820 ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) (in dyld) + 291 [0x8fe18f47]
+ 2820 ??? (in OurCarbonApp) load address 0x1000 + 0x7f9c24 [0x7fac24]
+ 2820 ??? (in OurCarbonApp) load address 0x1000 + 0x7f99b3 [0x7fa9b3]
+ 2820 NSUnLinkModule (in libdyld.dylib) + 81 [0x9a151346]
+ 2820 NSUnLinkModule (in dyld) + 344 [0x8fe10eae]
+ 2820 __cxa_finalize_ranges (in libsystem_c.dylib) + 318 [0x91779979]
+ 2820 ??? (in CantTutThis) load address 0x25f1000 + 0x2b0aec [0x28a1aec]
+ 2820 ??? (in CantTutThis) load address 0x25f1000 + 0x8912d [0x267a12d]
2820 Thread_10773 DispatchQueue_2: com.apple.libdispatch-manager (serial)
2820 _dispatch_mgr_thread (in libdispatch.dylib) + 52 [0x95eee2e2]
2820 _dispatch_mgr_invoke (in libdispatch.dylib) + 234 [0x95eee70e]
2820 kevent_qos (in libsystem_kernel.dylib) + 10 [0x9e123812]
Total number in stack (recursive counted multiple, when >=5):
Sort by top of stack, same collapsed (when >= 5):
??? (in CantTutThis) load address 0x25f1000 + 0x8912d [0x267a12d] [STACK TOP] 2820
kevent_qos (in libsystem_kernel.dylib) 2820
Binary Images:
0x1000 - 0x70aff7 +com.writebros.OurCarbonApp (6.2 - 6.2.4.7) <0577AB86-2EC7-3C26-A6DA-B514FFF48D7C> /Applications/MMOurCarbonAppTest/OurCarbonApp.app/Contents/MacOS/OurCarbonApp
0x25f1000 - 0x2991ff3 +CantTutThis (???) <44557A53-D8E2-33AB-BE43-94283F93AF19> CantTutThis
0x8fe05000 - 0x8fe3958f dyld (0.0 - ???) <8F9518A3-884D-35FF-8FD9-FB149B7F1BF2> /usr/lib/dyld
(AND LOTS MORE BINARY IMAGES...)
答案 0 :(得分:0)
我知道旧线程,但是有关上下文和未来Google员工的新信息:此应用是否受Pace的iLok系统保护?
我有一堆受iLok保护的音频插件,所有这些插件中都有“ CantTutThis”引用-可能是对试图解密包装/加密内容的黑客的一个暗淡的点头。
我刚遇到一个在启动时崩溃的插件,崩溃的插件被标识为“ CantTutThis”,大概是因为无法检索加密内容来报告实际的插件详细信息。