CoreAnalytics :: Client/FrameworkConfiguration :: init内部的神秘崩溃 [英] Mysterious crash inside CoreAnalytics::Client / FrameworkConfiguration::init
问题描述
我遇到了一个奇怪的崩溃，事实证明它很难调试.我可以在启动我的应用程序后立即随意触发它，只需按几次Command键即可.无需与我的应用进行其他交互.不用说，当命令键更改状态时，我的应用程序不执行任何操作.实际上，其他按键也会触发崩溃，包括字母键；除了似乎不太可能产生其他副作用外，Command没有什么特别之处.
I'm getting a strange crash that is proving difficult to debug. I can trigger it at will, immediately after launching my app, simply by pressing and releasing the Command key a couple of times; no other interaction with my app is needed. Needless to say, my app does not do anything when the command key changes state. Other keypresses also trigger the crash, actually, including letter keys; there's nothing special about Command except that it seems unlikely to have other side effects.
崩溃总是在后台线程中，并且总是具有相同的回溯，而该回溯不包含任何我的代码:
The crash is always in a background thread, always with the same backtrace that contains no code of mine whatsoever:
#0 0x00007fff603da3ec in __cxa_throw ()
#1 0x00007fff42e90492 in nlohmann::basic_json<std::__1::map, std::__1::vector, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, bool, long long, unsigned long long, double, std::__1::allocator, nlohmann::adl_serializer>::parser::unexpect(nlohmann::basic_json<std::__1::map, std::__1::vector, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, bool, long long, unsigned long long, double, std::__1::allocator, nlohmann::adl_serializer>::lexer::token_type) const ()
#2 0x00007fff42e8ccad in nlohmann::basic_json<std::__1::map, std::__1::vector, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, bool, long long, unsigned long long, double, std::__1::allocator, nlohmann::adl_serializer>::parser::parse_internal(bool) ()
#3 0x00007fff42e8fe63 in nlohmann::basic_json<std::__1::map, std::__1::vector, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, bool, long long, unsigned long long, double, std::__1::allocator, nlohmann::adl_serializer>::parser::parse() ()
#4 0x00007fff42e8fcd4 in nlohmann::basic_json<std::__1::map, std::__1::vector, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, bool, long long, unsigned long long, double, std::__1::allocator, nlohmann::adl_serializer> nlohmann::basic_json<std::__1::map, std::__1::vector, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, bool, long long, unsigned long long, double, std::__1::allocator, nlohmann::adl_serializer>::parse<char const*, 0>(char const*, char const*, std::__1::function<bool (int, nlohmann::basic_json<std::__1::map, std::__1::vector, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, bool, long long, unsigned long long, double, std::__1::allocator, nlohmann::adl_serializer>::parse_event_t, nlohmann::basic_json<std::__1::map, std::__1::vector, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, bool, long long, unsigned long long, double, std::__1::allocator, nlohmann::adl_serializer>&)>) ()
#5 0x00007fff42e826be in FrameworkConfiguration::init() ()
#6 0x00007fff42e82478 in FrameworkConfiguration::create(applesauce::xpc::object) ()
#7 0x00007fff42e82100 in CoreAnalytics::Client::handleConfigurationChange_sync(applesauce::xpc::dict const&) ()
#8 0x00007fff42e81f52 in CoreAnalytics::Client::handleServerMessage_sync(applesauce::xpc::dict) ()
#9 0x00007fff42e94039 in ___ZZN13CoreAnalytics6Client4initEvENK3$_1clEv_block_invoke ()
#10 0x00007fff634b8a54 in _xpc_connection_call_event_handler ()
#11 0x00007fff634b795c in _xpc_connection_mach_event ()
#12 0x000000010040482f in _dispatch_client_callout4 ()
#13 0x0000000100421b3a in _dispatch_mach_msg_invoke ()
#14 0x000000010040bb40 in _dispatch_lane_serial_drain ()
#15 0x0000000100422eda in _dispatch_mach_invoke ()
#16 0x000000010040bb40 in _dispatch_lane_serial_drain ()
#17 0x000000010040cae8 in _dispatch_lane_invoke ()
#18 0x0000000100419f2e in _dispatch_workloop_worker_thread ()
#19 0x000000010049002c in _pthread_wqthread ()
#20 0x000000010048f157 in start_wqthread ()
nlohmann :: stuff是我认识的JSON库，因为我在其他项目中使用过它，但是在本项目中没有使用它.根据Google的说法，FrameworkConfiguration ::和CoreAnalytics ::与我无法直接控制的内部Apple分析收集工作有关.我已经关闭了此计算机上系统偏好设置"中安全性和安全性"中的所有分析功能隐私面板，然后重新启动机器；该错误仍然可以100％复制.
The nlohmann:: stuff is a JSON library that I recognize because I've used it in other projects, but I do not use it in this project. FrameworkConfiguration:: and CoreAnalytics:: are, according to Google, related to internal Apple analytics-gathering cruft that I have no direct control over. I have turned off all analytics in System Preferences on this machine, in the Security & Privacy panel, and then rebooted the machine; the bug is still 100% reproducible.
发生这种情况时，应用程序中的主线程什么都不做；通常它位于mach_msg_trap()中.主线程上的回溯也没有我的代码，它是闲置的CFRunLoop的典型macOS回溯.
The main thread in the app is doing nothing when this occurs; typically it's sitting in mach_msg_trap(). The backtrace on the main thread also has no code of mine, and is the typical macOS backtrace for a CFRunLoop that is idling.
我尝试打开Xcode提供的各种调试功能-地址清理器，未定义的行为清理器，malloc涂抹/防护边缘/防护malloc/僵尸对象/malloc堆栈.这些都不会导致与该问题相关的任何输出. (也就是说，除了malloc东西的初始输出说它已被启用之外，没有其他输出，等等).
I have tried turning on the various debugging bells and whistles that Xcode provides – address sanitizer, undefined behavior sanitizer, malloc scribble / guard edges / guard malloc / zombie objects / malloc stack. None of those results in any output related to the problem. (I.e., no output except the initial output from the malloc stuff saying that it has been enabled, blah blah blah.)
我正在使用Catalina 10.15.3，Xcode 11.3.1.我的下一步将是同时升级这两个.我已经忘记了我已经过时了，但是只是略微过时了，所以如果这有什么不同，那将是令人惊讶的.
I'm on Catalina 10.15.3, Xcode 11.3.1. My next step will be to upgrade both of those; I had forgotten that I was out of date, but only slightly, so it'll be surprising if that makes any difference.
很显然，当我按下键时，系统上的其他应用程序不会崩溃，因此，我的应用程序一定在执行某些操作会触发此问题，但是我无法想象是什么，而且我对如何操作一无所知调试一下.我猜如果升级没有帮助，我将复制我的项目并开始删除大量代码，直到不再重现该错误为止，并尝试缩小该应用程序负责的部分.我以为我会先在这里检查一下，看看是否有人看过.谢谢.
Obviously other apps on my system don't crash when I press keys, so there must be something my app is doing that triggers this problem, but I can't imagine what, and I'm at a loss as to how to debug this. I guess if upgrading doesn't help I'll make a copy of my project and start ripping out big chunks of code until the bug no longer reproduces, and try to narrow down what part of the app is responsible. I thought I'd check here first to see if anybody has seen this, though. Thanks.
添加:我刚刚更新到macOS 10.15.4和Xcode 11.4.1.在此崩溃中没有任何变化.是时候开始雕刻了.如果我找出原因，我将在这里发布，以便其他人查找他们是否遇到了这个问题.
ADDITION: I've just updated to macOS 10.15.4 and Xcode 11.4.1. No change in this crash. Time to start carving. I will post here if I figure out the cause, for others to find if they hit this.
推荐答案
好吧，有些令人不满意的答案是它似乎是某种损坏的Xcode项目文件的结果.我从11.4.1中创建的一个新的Cocoa应用程序项目开始，然后逐个添加源文件和资源，并在进行过程中进行测试.我最终重新创建了整个项目，该错误不再存在.遵循所有Xcode的项目升级建议，将旧的Xcode项目从较旧的版本中继承下来.我已经用细齿梳理了两个项目的所有构建设置，并且看不到任何可以解释差异的东西.这是一个谜.但为了后人:如果您遇到此问题，请从头开始重建项目.
Well, the somewhat unsatisfying answer is that it appears to be the result of some kind of corrupted Xcode project file. I started with a new Cocoa app project created in 11.4.1, and added in source files and resources one by one, testing as I went. I ended up with the full project recreated, and the bug is no longer present. The old Xcode project had been carried forward from older versions, by following all of Xcode's project upgrade recommendations. I've gone through all the build settings for the two projects with a fine-toothed comb, and can't see anything that would explain the difference. It's a mystery. But for posterity: if you see this problem, rebuild your project from scratch.
这篇关于CoreAnalytics :: Client/FrameworkConfiguration :: init内部的神秘崩溃的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
