App Crashing Help

I am trying to track down the source of a strange crash that is happening for a client. It is happening in a multiwindow application built with Xojo 2018 R2 (It can not be build with newer versions do to some dependency issues) running on OSX 10.14.3.

The problem does not seem seem to occur in a regular fashion, but it always coincides with a window being closed, however it is not always the same window or even same type of window. I added logging to the close events of windows to track execution, but the take down all completes and the close event ends without incidence. Then the app crashes. I have had the client send me the system crash reports and I see:

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

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_INVALID_ADDRESS at 0x0000000000000020
Exception Note:        EXC_CORPSE_NOTIFY

Termination Signal:    Segmentation fault: 11
Termination Reason:    Namespace SIGNAL, Code 0xb
Terminating Process:   exc handler [1670]

Application Specific Information:
objc_msgSend() selector name: release

as well as

Exception Type:        EXC_BAD_INSTRUCTION (SIGILL)
Exception Codes:       0x0000000000000001, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Termination Signal:    Illegal instruction: 4
Termination Reason:    Namespace SIGNAL, Code 0x4
Terminating Process:   exc handler [1353]

Application Specific Information:
*** CFRelease() called with NULL ***

Based on those reports, its not a leak, looks more like a bad reference somewhere. I have checked to see if there is some background process or asynchronous type of call that is happening that would not be caught by Xojo’s UnhandledException event, but there is none.

Any ideas on how to further try to track this down?
Thank you

Do you have Quit() in one of the window events?

As in a call to Quit()? No.

That might cause weird crashes. Maybe something else is happening do you have. More crashlog info from the macos console app?

Or perhaps you close (as in nil?) the parent window from whithin a child window?

This may be a race condition as where something that is nil is being cleaned up (while it’s already nil or null in xcode terms).

I did not write the code in question, I am looking through it.
Searching for “= nil” has not produced anything interesting. It does seem like a null reference is trying to be cleaned. As for more crash data:

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   com.apple.CoreFoundation          0x938b87b8 CFRelease + 88
1   com.apple.CoreFoundation          0x938c678e cow_cleanup + 74
2   com.apple.CoreFoundation          0x938c671d -[__NSArrayM dealloc] + 49
3   libobjc.A.dylib                   0xa6b0e77b objc_object::sidetable_release(bool) + 269
4   libobjc.A.dylib                   0xa6b0c053 -[NSObject release] + 19
5   libobjc.A.dylib                   0xa6b0b7a5 (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 721
6   com.apple.CoreFoundation          0x938bc2c4 _CFAutoreleasePoolPop + 24
7   com.apple.Foundation              0x952bb235 -[NSAutoreleasePool drain] + 120
8   com.apple.AppKit                  0x914d3054 -[NSApplication run] + 924
9   com.xojo.XojoFramework            0x04c5551a mainloop() + 46
10  com.xojo.XojoFramework            0x04c53628 RuntimeRun + 49
11  com.desertsandsoft.smartoutfitter    0x001b540d REALbasic._RuntimeRun + 145
12  com.desertsandsoft.smartoutfitter    0x0408227a _Main + 349
13  com.desertsandsoft.smartoutfitter    0x0407bd95 main + 36
14  com.desertsandsoft.smartoutfitter    0x0411bcf6 start + 53

Thread 1:: com.apple.NSEventThread
0   libsystem_kernel.dylib            0xa7b751a2 mach_msg_trap + 10
1   libsystem_kernel.dylib            0xa7b756f3 mach_msg + 47
2   com.apple.CoreFoundation          0x938ea9f9 __CFRunLoopServiceMachPort + 289
3   com.apple.CoreFoundation          0x938ea0ba __CFRunLoopRun + 3196
4   com.apple.CoreFoundation          0x938e9141 CFRunLoopRunSpecific + 584
5   com.apple.CoreFoundation          0x9390213f CFRunLoopRunInMode + 82
6   com.apple.AppKit                  0x914e2197 _NSEventThread + 165
7   libsystem_pthread.dylib           0xa7c275e8 _pthread_body + 137
8   libsystem_pthread.dylib           0xa7c2a7d7 _pthread_start + 82
9   libsystem_pthread.dylib           0xa7c267a6 thread_start + 34

Thread 2:: com.apple.coreaudio.AQClient
0   libsystem_kernel.dylib            0xa7b751a2 mach_msg_trap + 10
1   libsystem_kernel.dylib            0xa7b756f3 mach_msg + 47
2   com.apple.CoreFoundation          0x938ea9f9 __CFRunLoopServiceMachPort + 289
3   com.apple.CoreFoundation          0x938ea0ba __CFRunLoopRun + 3196
4   com.apple.CoreFoundation          0x938e9141 CFRunLoopRunSpecific + 584
5   com.apple.CoreFoundation          0x9390213f CFRunLoopRunInMode + 82
6   com.apple.audio.toolbox.AudioToolbox    0x927be896 GenericRunLoopThread::Entry(void*) + 138
7   com.apple.audio.toolbox.AudioToolbox    0x927be7d2 CAPThread::Entry(CAPThread*) + 94
8   libsystem_pthread.dylib           0xa7c275e8 _pthread_body + 137
9   libsystem_pthread.dylib           0xa7c2a7d7 _pthread_start + 82
10  libsystem_pthread.dylib           0xa7c267a6 thread_start + 34

Thread 3:: Dispatch queue: com.apple.root.user-interactive-qos
0   libsystem_kernel.dylib            0xa7b751a2 mach_msg_trap + 10
1   libsystem_kernel.dylib            0xa7b756f3 mach_msg + 47
2   com.apple.QuartzCore              0x9aa73230 CA::Render::Fence::wait(unsigned int, unsigned long) + 184
3   com.apple.QuartzCore              0x9aa16c6d CA::Context::commit_transaction(CA::Transaction*) + 1993
4   com.apple.QuartzCore              0x9aa16101 CA::Transaction::commit() + 527
5   com.apple.AppKit                  0x91510a97 NSPerformVisuallyAtomicChange + 233
6   com.apple.AppKit                  0x917aa96b __42-[NSAnimation(NSInternal) _runInNewThread]_block_invoke + 82
7   libdispatch.dylib                 0xa79e6a78 _dispatch_call_block_and_release + 15
8   libdispatch.dylib                 0xa79e6abb _dispatch_client_callout + 58
9   libdispatch.dylib                 0xa79f63f0 _dispatch_root_queue_drain + 636
10  libdispatch.dylib                 0xa79f6a86 _dispatch_worker_thread2 + 98
11  libsystem_pthread.dylib           0xa7c26a16 _pthread_wqthread + 539
12  libsystem_pthread.dylib           0xa7c26782 start_wqthread + 34

Thread 4:
0   libsystem_pthread.dylib           0xa7c26760 start_wqthread + 0
1   ???                               0x54485244 0 + 1414025796

Thread 5:
0   libsystem_pthread.dylib           0xa7c26760 start_wqthread + 0

Thread 0 crashed with X86 Thread State (32-bit):
  eax: 0xa836c984  ebx: 0x0000002e  ecx: 0x93a5b44a  edx: 0x00000000
  edi: 0x07b22180  esi: 0x00000000  ebp: 0xbffff738  esp: 0xbffff734
   ss: 0x00000023  efl: 0x00010246  eip: 0x938b87b8   cs: 0x0000001b
   ds: 0x00000023   es: 0x00000023   fs: 0x00000000   gs: 0x0000000f
  cr2: 0x68e30000
 
Logical CPU:     0
Error Code:      0x00000000
Trap Number:     6

I believe this is / was a bug in older versions where there was a possible “use after free” condition that has been remedied in newer versions

There is no workaround but to use a newer version since the code in question is in the framework itself

[quote=428299:@Norman Palardy]I believe this is / was a bug in older versions where there was a possible “use after free” condition that has been remedied in newer versions

There is no workaround but to use a newer version since the code in question is in the framework itself[/quote]

Well that clarifies the randomness

It certainly looks like one of those cases
I know travis hunted down a few like crash on quit

Well that is good to know. It did seem like a framework issue to me…
Thank you for the information. I will work with them to try and remove their dependency on that version of Xojo…

Really curious what they’ve done to make things dependent on a specific version of Xojo
That seems almost hard to do

It is nothing that can’t be undone, they rely heavily on graphics objects which they refer directly to from the built in property of a window and in later versions of Xojo those objects are no longer accessible.

In the future, is there a way capture an OSX system crash report programmatically so that users do not have to manually send them from the built in Mac crash dialogue?

For example, when someone reopens and app, have it figure out that is was not shut down properly and look for a crash report?

If it is a declares type of solution, what libraries might be the right ones to look at?

ah ok the infamous graphics object …
yeah that one bit a lot of folks
some times its easy to do something else & sometimes not

as for the Apple crash report thats captured out of process - not from the app itself
I dont know if there OS API’s that you can hook into to know one has been created
There may be
One thing to be aware of is that the Apple dialogs about “this app crashed last time you ran it” etc may happen before you ever get a chance to do anything

Yeah the timing and control of that whole process seems a bit complex… I didn’t know if someone had already looked into it or if folks request crash reports manually.

Not sure but i know for the IDE it has a linked in crash reporter that facilitate making the IDE file reports that could be useful
And its not the Apple one

After doing some looking around, on Mac at least, this seems possible.
Is there any way to access the symbol table from a Xojo build? It would be awesome to be able to symbolicate a system crash report. Sounds like a cool project too.

I know that if includefunctionnames is set to true, a xojo raised exception will be symbolicated, but the system report wont be. Is there any way to access that information from the IDE even? One could save it before a distribution and then symbolicate after the fact, similar to what XCode does.

The only symbols that would be present are from your Xojo code
Framework ones are deliberately stripped
And I know its been requested they be present but I doubt that will occur as I know why they were orignally stripped and those reasons still hold true today

Copy

And presumably, an error produced by xojo code (non-framework) could always be caught by the app?