OS X Carbon app crashing on launch - any insights?

Customer running app on OS X is reporting a crash log on launching app. Build is Carbon, I do not build apps for Windows so this is Mac-only. I’ve gone over the report but can’t figure out what’s causing it. They were using the app just fine last week. They claim nothing has changed regarding software installed or updates. They’ve also tried rebooting the computer.

Can anyone provide some assistance in decoding this crash log? Thank you very much to anyone who can provide assistance!

Process: ApplicationName [556]
Path: /Applications/ApplicationName.app/Contents/MacOS/ApplicationName
Identifier: com.company.appname
Version: 2.9.6 (2.9.6)
Code Type: X86 (Native)
Parent Process: ??? [1]
Responsible: ApplicationName [556]
User ID: 502

Date/Time: 2016-10-03 16:03:19.905 -0400
OS Version: Mac OS X 10.11.6 (15G1004)
Report Version: 11
Anonymous UUID: 6F672F6E-3B5D-0060-C9E4-C97F2E3F6F25

Time Awake Since Boot: 390 seconds

System Integrity Protection: enabled

Crashed Thread: 0 Dispatch queue: com.apple.main-thread

Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000000

VM Regions Near 0:
__TEXT 0000000000001000-0000000002df8000 [ 46.0M] r-x/rwx SM=COW /Applications/ApplicationName/Contents/MacOS/ApplicationName

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 com.company.appname 0x02972f03 App.Event_Open%%o + 27526
1 rbframework.dylib 0x0311a4a6 RuntimeExit + 70
2 com.company.appname 0x000251ab Delegate.Invoke%% + 34
3 com.company.appname 0x000c70fa Application._CallFunctionWithExceptionHandling%%op + 584
4 rbframework.dylib 0x03166958 CallFunctionWithExceptionHandling(void (*)()) + 302
5 rbframework.dylib 0x0311a509 RuntimeExit + 169
6 rbframework.dylib 0x0311a7c7 RuntimeRegisterAppObject + 69
7 com.company.appname 0x0002966c REALbasic._RuntimeRegisterAppObject%%o + 159
8 com.company.appname 0x000027ef _NewAppInstance + 242
9 com.company.appname 0x00014703 _Startup + 81
10 rbframework.dylib 0x0311a45a RunFrameworkInitialization + 64
11 com.company.appname 0x0002a125 REALbasic._RunFrameworkInitialization%%p + 42
12 com.company.appname 0x000147a7 _Main + 106
13 com.company.appname 0x0000256c % main + 36
14 com.company.appname 0x02cb296d _start + 116
15 com.company.appname 0x02cb28c3 start + 43

Although El Capitan still supports Carbon, Apple no longer consider it a recommended platform. Things may get even worse with Sierra.

Carbon is deprecated, in fact anything other than 64-Bit Cocoa is unofficially consider deprecated (according to an Apple engineer).

IIRC the crash report is because it’s trying to access an object that doesn’t exist.

I would recommend that you start your Cocoa migration with the latest version of Xojo as soon as possible.

Thank you for the replies. I’ve already almost completed the migration to Cocoa. This is an older version of the app that is legacy for users who haven’t paid for an upgrade.

I’m running this legacy version on Sierra with zero issues and have been testing everything through the betas on multiple computers. This doesn’t mean it’s perfect but I haven’t ran into any issues, and have only had one crash report out of a fairly large user base.

So yes I already know to switch to Cocoa. Pertaining to my original question - is there anything else of relevance in the crash report? Or is it too generic?


[quote=289708:@C Mana]Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 com.company.appname 0x02972f03 App.Event_Open%%o + 27526[/quote]
Doesn’t this mean something in App.Open is causing the crash?

I’d put System.Debuglogs every other line in there then have the customer run it and send back what’s in the Console. The debuglog that doesn’t make it to Console tells you which line crashes.

This is a good idea, if in fact a single line of code in the app’s open event is causing the crash. I assumed that might be the case, but wondered if someone smarter than I could confirm that.

Thank you for the advice!

Carbon applications work without problems, even if Carbon is deprecated since OS X 10.7. It is just not developed further anymore.

Yes. Some object accessed in App.Open is Nil.

Thank you both. I will try to debug the line of code. Very strange that this happened randomly for this one person. They’ve used the app for years, and even last Friday was having no issues.

I hope the line of code that ends up being the culprit makes sense. If it seems like a benign instruction with no obvious cause as to what could be nil or why, that will be a head scratcher.

Fingers crossed. Thanks again gents.

Can you post the line?

Is there a window assigned to App.DefaultWindow in the IDE?
And if yes, do you use ImplicitInstance = True on the main window?

No default window. The window is opened in the open event of the application.

I will post the line of code if I can find it. Working on the debug lines now. There’s a lot going on in the app’s open event. Then I’ll send the new build to the customer and see what she reports.

I would tell the user to upgrade to the latest version, because of EC 10.16. At one point, you have to leave these people behind.

Your job is to do business, not charity legacy support. Just my 2cts.