Crash at _nextEventMatchingEventMask

I got a crash like this: Exception Type: EXC_BAD_ACCESS Exception Codes: KERN_INVALID_ADDRESS at 0x41af37daf2000000 Triggered by Thread: 0 ... can anyone tell me how to debug this:

I'd need to see a full crash report before I could speculate on whatever is gong wrong.

However, this code is definitely concerning:

my code like this while (1) { @autoreleasepool { NSEvent* event = [NSApp nextEventMatchingMask:NSEventMaskAny untilDate:NSDate.distantFuture inMode:NSDefaultRunLoopMode dequeue:YES]; if (event) { [NSApp sendEvent:event]; } } }

What are you trying to do here and why are you trying to do it? This kind of manual event dispatch is not a normal practice and can easily create all sorts of odd behavior. If your goal was to simply monitor every event your app received, why not just subclass NSApplication and override sendEvent?

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

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.

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_;
}

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.

I can't tell you how this will translate into your applications logic but, after a great deal of work mangling the crash log*, I can tell you exactly what's crashing.

*As an aside, one of the reasons we specifically ask for "Apple crash logs" is that, by their nature, any crash tools I've worked with is EXTREMELY "picky" about the precise details of how the text is formatted, failing if those details aren't exactly as it expects. As you'd expect, Apple has tools that can trace a log back to the exact line that's crashing, but it expect those logs to be formatted "correctly". Working with a non-Apple log means picking apart the altered log to figure exactly what's "wrong" and then adjusting it to get it working, which is tedious and time consuming.

In any case, NSEvent has a property "coalescedTouchesForTouch" which returns the set of touch points connected to a "main" touch. The array that property returns is eventually released when NSEvent dealloc's and that array object is what's then crashing.

How that occurred is not a question I can really answer. The only direct access you have to that object is the copy returned by "coalescedTouchesForTouch", however, that's a copy of an NSArray (immutable) which means it was "copied" using retain, not by duplicating the full object. Assuming it's overrelease issue, then that means the original issue could have occurred at a much earlier point but wasn't visible until the retain count eventually hit "0". Of course, it's also possible the event object was actually damaged by unrelated activity (like a buffer overrun).

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware