The stack and code for this Chromium Embedded Framework section are parsed below base::MessagePumpNSApplication::DoRun(base::MessagePump::Delegate*) (in Chromium Embedded Framework) (message_pump_mac.mm:0) base::MessagePumpCFRunLoopBase::Run(base::MessagePump::Delegate*) (in Chromium Embedded Framework) (message_pump_mac.mm:175) base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::Run(bool, base::TimeDelta) (in Chromium Embedded Framework) (thread_controller_with_message_pump_impl.cc:603) base::RunLoop::Run(base::Location const&) (in Chromium Embedded Framework) (run_loop.cc:143) base::RunLoop::RunUntilIdle() (in Chromium Embedded Framework) (run_loop.cc:152) CefDoMessageLoopWork() (in Chromium Embedded Framework) (context.cc:350) void MessagePumpNSApplication::DoRun(Delegate* delegate) { bool last_running_own_loop_ = running_own_loop_; // NSApp must be initialized by calling: // [{some class which implements CrAppProtocol} sharedApplication] // Most likely candidates are CrApplication or BrowserCrApplication. // These can be initialized from C++ code by calling // RegisterCrApp() or RegisterBrowserCrApp(). CHECK(NSApp); if (!NSApp.running) { running_own_loop_ = false; // NSApplication manages autorelease pools itself when run this way. [NSApp run]; } else { running_own_loop_ = true; while (keep_running()) { OptionalAutoreleasePool autorelease_pool(this); NSEvent* event = [NSApp nextEventMatchingMask:NSEventMaskAny untilDate:NSDate.distantFuture inMode:NSDefaultRunLoopMode dequeue:YES]; if (event) { [NSApp sendEvent:event]; } } } running_own_loop_ = last_running_own_loop_; }

Thank you for your answer. All my logs are attached. I didn't replicate this crash myself, but my app background gets a lot of crashes every day. My application uses QT and CEF framework, maybe there is some place did not manage the memory, but I want to know how I should locate and troubleshoot such a problem. crash.log crash2.log crash3.log