EXC_CRASH (SIGABRT) on app created with py2app

I have created my first app with python using py2app and it build my app successfully but when I try to open it, it crash but when I open it's package and run it from this path: myapp.app/contents/macos/myapp it open console and run my app correctly without any error. I can't understand how to read this kind of mac errors. I will be happy if you can help me with that:

Replies

Consider this snippet from the crashed thread’s backtrace:

10  Foundation     … -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 204
11  AppKit         … -[NSMenuItem initWithTitle:action:keyEquivalent:] + 384
12  libtk8.6.dylib … +[NSMenuItem(TKUtils) itemWithSubmenu:] + 80

Your code — well, library code from another third party that you’ve included in your app — (frame 12) has called -[NSMenuItem initWithTitle:action:keyEquivalent:] (frame 11) which has tripped an assertion (frame 10). There are two possible causes for this assertion:

  • The string passed to the title parameter is nil.

  • The string passed to the keyEquivalent parameter is nil.

Both are a clear error on the part of the caller.

I can’t offer any further insight because all the frames deeper the backtrace are third-party code. I recommend that you escalate this via the support challenge for that code.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

  • Thanks for your reply. Could you explain what is support challenge? and another thing, why my app works correctly when I open it's package content and run it's "Unix Executable File"? what's deference between "dmg" and "Unix Executable File" of my app?

Add a Comment

Unfortunately, the answer from Quinn "The Eskimo" is incorrect. The "third party" code he refers to is Tk. The call to the NSMenuItem constructor from Tk has been in place for decades without causing this crash. It is not passing a nil title nor a nil keyEquivalent. Since Tk is open source this last claim is easy to verify by just looking at the code.

The reason for Quinn's error was that he somehow ignored line #2, which is where the crash actually occurs. He focused instead on line #3 which was conveniently part of the "third party" code. :

2   Foundation                          0x00000001bbc2fea8 -[NSCalendarDate initWithCoder:] + 0
3   AppKit                              0x00000001bd7d0868 -[NSMenuItem initWithTitle:action:keyEquivalent:] + 384

Had Quinn looked at line #2 he would have concluded that the crash was caused by passing a nil value for the coder in the in the call to [NSCalendarDate initWithCoder:]. Tk never calls that method. It is being called from within the AppKit's implementation of [NSMenuItem initWithTitle:action:keyEquivalent:]. It would be natural to conclude that this is actually an Apple bug, most likely introduced with macOS Ventura.