I have a user of one of my apps who has reported to me that following his upgrading to El Capitan my software crashes on launch. I have not updated my system yet so I cannot recreate the issue. He has sent to me the crash report but I don’t know what it is saying.
Is there anybody here who can help me out by reading the report and giving me some hints?
Please PM me so I can send a copy to you.
Thanks in advance.
Simon.
Put it on pastebin, we all have different areas of expertise. It would be much easier for us to help you, and for you to get help!
OS X is licensed for use in a VM on a Mac, so for testing you could certainly download the installer and get it running in Fusion, Parallels or even VirtualBox.
Or file a bug report with the crash log privately
One issue I know of is using El Capitans full screen or split screen functionality causing issues
[quote=218300:@Norman Palardy]Or file a bug report with the crash log privately
One issue I know of is using El Capitans full screen or split screen functionality causing issues[/quote]
Oh. This is precisely a problem one of my RubberViews customer is facing. Any additional information available ?
This morning I heard from first customer reporting crash in El capitan when trying to print.
I’m in the same situation, (although the version they are using is compiled with an older RS , and is likely the carbon build.)
Expecting to see more of this soon.
Got a crash report from a customer for folderitem.nativepath:
Thread 14 Crashed:
0 com.xojo.XojoFramework 0x017a29fb FolderItemPathGetter + 11
1 com.mothsoftware.mailarchiverx 0x0009c673 FolderItem.NativePath.Get%s%oi4 + 71
2 com.mothsoftware.mailarchiverx 0x00c8713e MakeMailboxMail.TravelDownAccountMailboxes%o%ooA1s + 546
3 com.mothsoftware.mailarchiverx 0x00c83236 MakeMailboxMail.get%v%o + 3717
4 com.mothsoftware.mailarchiverx 0x00c816bf MakeMailboxFromString.get%v%o + 207
5 com.mothsoftware.mailarchiverx 0x00c753d1 MailboxIterator.nextObject%o%o + 465
6 com.mothsoftware.mailarchiverx 0x00c9ea3f ArchiveThread.DoWork%%o + 1464
7 com.mothsoftware.mailarchiverx 0x00c9e427 ArchiveThread.Event_Run%%o + 56
8 com.xojo.XojoFramework 0x017dd8ba 0x16bb000 + 1190074
9 libsystem_pthread.dylib 0x9bfa9794 _pthread_body + 138
10 libsystem_pthread.dylib 0x9bfa970a _pthread_start + 155
11 libsystem_pthread.dylib 0x9bfa6fa6 thread_start + 34
Xojo 2014r2
Everything after ‘OpenPrinterDialog’ called…
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libobjc.A.dylib 0x9d71269f objc_msgSend + 31
1 libobjc.A.dylib 0x9d7177df objc_object::sidetable_release(bool) + 239
2 libobjc.A.dylib 0x9d714d1c -[NSObject release] + 25
3 com.apple.print.framework.Print.Private 0x0c9b70d2 0xc9b5000 + 8402
4 libobjc.A.dylib 0x9d7177df objc_object::sidetable_release(bool) + 239
5 libobjc.A.dylib 0x9d714d1c -[NSObject release] + 25
6 com.apple.AppKit 0x91524f29 -[NSMenuItem dealloc] + 229
7 libobjc.A.dylib 0x9d7177df objc_object::sidetable_release(bool) + 239
8 libobjc.A.dylib 0x9d714d1c -[NSObject release] + 25
9 com.apple.AppKit 0x91524ad5 -[NSMenu removeItemAtIndex:] + 704
10 com.apple.AppKit 0x9156da20 -[NSPopUpButtonCell removeItemAtIndex:] + 60
11 com.apple.AppKit 0x9156d9bc -[NSPopUpButtonCell removeAllItems] + 65
12 com.apple.AppKit 0x9156d974 -[NSPopUpButton removeAllItems] + 52
13 com.apple.print.framework.Print.Private 0x0c9c00ec 0xc9b5000 + 45292
14 com.apple.print.framework.Print.Private 0x0c9d6786 0xc9b5000 + 137094
15 com.apple.print.framework.Print.Private 0x0c9d5d35 0xc9b5000 + 134453
16 com.apple.print.framework.Print.Private 0x0c9d16b9 0xc9b5000 + 116409
17 libobjc.A.dylib 0x9d7179e4 -[NSObject performSelector:withObject:] + 70
18 com.apple.AppKit 0x9158a776 __36-[NSApplication sendAction:to:from:]_block_invoke + 51
19 libsystem_trace.dylib 0x9953f3c9 _os_activity_initiate + 85
20 com.apple.AppKit 0x9158a697 -[NSApplication sendAction:to:from:] + 610
21 com.apple.AppKit 0x9159e089 -[NSControl sendAction:to:] + 102
22 com.apple.AppKit 0x9159df7d __26-[NSCell _sendActionFrom:]_block_invoke + 176
23 libsystem_trace.dylib 0x9953f3c9 _os_activity_initiate + 85
24 com.apple.AppKit 0x9159deac -[NSCell _sendActionFrom:] + 161
25 com.apple.AppKit 0x917fa2a9 __48-[NSCell trackMouse:inRect:ofView:untilMouseUp:]_block_invoke1010 + 43
26 libsystem_trace.dylib 0x9953f3c9 _os_activity_initiate + 85
27 com.apple.AppKit 0x9159c259 -[NSCell trackMouse:inRect:ofView:untilMouseUp:] + 2744
28 com.apple.AppKit 0x915e886b -[NSButtonCell trackMouse:inRect:ofView:untilMouseUp:] + 809
29 com.apple.AppKit 0x9159a888 -[NSControl mouseDown:] + 693
30 com.apple.AppKit 0x91b87e1b -[NSWindow _handleMouseDownEvent:isDelayedEvent:] + 6266
31 com.apple.AppKit 0x91b89622 -[NSWindow _reallySendEvent:isDelayedEvent:] + 2303
32 com.apple.AppKit 0x9152693f -[NSWindow sendEvent:] + 567
33 com.apple.AppKit 0x91bcffb1 carbonAppWindowMouseHandler + 268
34 com.apple.AppKit 0x91bce8b7 carbonAppWindowHandler + 916
35 com.apple.HIToolbox 0x9dbba68b _InvokeEventHandlerUPP(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*, long ()(OpaqueEventHandlerCallRef, OpaqueEventRef*, void*)) + 36
36 com.apple.HIToolbox 0x9db629a0 DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 1832
37 com.apple.HIToolbox 0x9db61bb4 SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*) + 402
38 com.apple.HIToolbox 0x9db74f6d SendEventToEventTarget + 34
39 com.apple.HIToolbox 0x9db9b6b1 ToolboxEventDispatcherHandler(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*) + 3177
40 com.apple.HIToolbox 0x9db62def DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 2935
41 com.apple.HIToolbox 0x9db61bb4 SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*) + 402
42 com.apple.HIToolbox 0x9db74f6d SendEventToEventTarget + 34
43 rbframework.dylib 0x00e0c4a5 SetFocusPane(SubPane*) + 489
44 rbframework.dylib 0x00e0c71d EventPump(unsigned char) + 443
45 rbframework.dylib 0x00e0d5d8 UpdateMouseCursor() + 556
46 rbframework.dylib 0x00e0d7d5 ModalEvents(unsigned char) + 75
47 rbframework.dylib 0x00e8e564 PrintSession::DoPrintDialog(PrinterSetup&) + 74
48 rbframework.dylib 0x00e99ef6 RuntimeOpenPrinterDialog + 220
Here is part of the original crash report:
[code]Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x00000000a218badc
Exception Note: EXC_CORPSE_NOTIFY
VM Regions Near 0xa218badc:
__LINKEDIT 000000008fe9a000-000000008feaf000 [ 84K] r–/rwx SM=COW /usr/lib/dyld
–> Submap 0000000090000000-00000000a2400000 [292.0M] r–/rwx SM=SHM machine-wide VM submap
mapped file 0000000090000000-0000000090010000 [ 64K] r-x/r-x SM=COW
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 com.apple.AppKit 0x9050cf71 _NSAppKitLock + 51
1 com.xojo.XojoFramework 0x009dba9e 0x9ba000 + 137886
2 com.xojo.XojoFramework 0x00b5feb0 RuntimeInitExternalClasses + 34
3 com.simcarsoftware.simplehours 0x00154805 REALbasic._RuntimeInitExternalClasses + 60
4 com.simcarsoftware.simplehours 0x00002eaa _EarlyStartup + 28
5 com.simcarsoftware.simplehours 0x0000301d _Main + 153
6 com.simcarsoftware.simplehours 0x00002764 main + 36
7 com.simcarsoftware.simplehours 0x00810b33 start + 53
[/code]
I hope someone can push me in the right direction.
Thanks.
Simon.
You have dead people in your machine? “EXC_CORPSE_NOTIFY”
That’s funny.
I’ve seen this error before but it seems to happen when the app has run out of memory.
I have noticed that there is a plist property allowing the application to be notified when it died… Which I thought was odd, because if the app died, how does it receive such notifications…
Makes sense as I understand “EXC_BAD_ACCESS” to mean that it can’t access a segment of memory.
I’ve had issues with Serial to USB Converters that for once are not purely Prolific driver related. I’ve had to turn off System Integrity Protection.
One thing I’ve been battling for the last 10 days is that OSX El Capitan seems to be much more aggressive in releasing objects. If you do not have proper retain/release semantics in your Cocoa code, you will get weird crashes like the one above.
Geeking out on Cocoa a bit (bear with me!) in the past you were able to do [view addSubview:myInstanceVariable] and only keep a weak reference to myInstanceVariable because view would retain it for you, and when view was deallocated, myInstanceVariable was released “sometime later” (probably autoreleased). Now, it appears that myInstanceVariable is released by the view immediately, so you have no time to (say) unregister an observer if you didn’t have a strong reference to begin with.
Speculation on my part is that AppKit / UIKit on El Cap / iOS9 are now built with Automatic Reference Counting (ARC), which exhibits these “immediate release because you don’t control them” behaviours.
So what I’m saying is, if you do any Cocoa work and don’t retain the stuff you care about, it may be gone before you know it even though “it worked before”.