On Mar 25, 2015, at 9:38 AM, Michael Domino <[email protected]<mailto:[email protected]>> wrote: I got a recent crash report that is exactly the problem reported at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58142.
Thanks for the link to the bug report. Is there any way you could post the actual Mac crash report? I’m curious to see how it compares to some that we’ve received against our plug-in, which was built with Xcode 3.2, GCC 4.0, and the 10.5 SDK on Mavericks, running on Yosemite. Our experience seems similar to yours, where our binaries built with those older tools have continued to pretty much work fine, up until the latest 10.10.2 version of Yosemite, where we suddenly are getting reports of sporadic crashes. Although our plug-in isn’t multi-threaded, but the host application may be doing something with threads that’s affecting our plug-in. The crash logs we’ve received all have something like this at the tops of their call stacks: Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 com.apple.CoreFoundation 0x95c54871 CFRunLoopAddTimer + 81 1 com.apple.Foundation 0x92ffbae7 -[NSObject(NSDelayedPerforming) performSelector:withObject:afterDelay:inModes:] + 991 2 com.adobe.Acrobat.framework 0x003ae62f 0x56000 + 3507759 3 com.adobe.Acrobat.framework 0x002084d7 0x56000 + 1778903 4 com.adobe.Acrobat.framework 0x003adba4 0x56000 + 3505060 5 com.apple.Foundation 0x93034486 __NSFireDelayedPerform + 489 6 com.apple.CoreFoundation 0x95c94b36 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 22 7 com.apple.CoreFoundation 0x95c945e4 __CFRunLoopDoTimer + 1316 8 com.apple.CoreFoundation 0x95d1002f __CFRunLoopDoTimers + 351 9 com.apple.CoreFoundation 0x95c4d151 __CFRunLoopRun + 2081 10 com.apple.CoreFoundation 0x95c4c6c6 CFRunLoopRunSpecific + 390 11 com.apple.CoreFoundation 0x95c4c52b CFRunLoopRunInMode + 123 12 com.apple.HIToolbox 0x9a4652d8 RunCurrentEventLoopInMode + 262 13 com.apple.HIToolbox 0x9a609d83 GetNextEventMatchingMask + 98 14 com.apple.HIToolbox 0x9a609af9 WNEInternal + 208 15 com.apple.HIToolbox 0x9a609a1e WaitNextEvent + 52 16 com.apple.HIToolbox 0x9a5e9ab6 ModalDialog + 906 17 com.apple.HIToolbox 0x9a5f21f6 RunStandardAlert + 766 This seems to point to something working differently with Core Foundation in Yosemite. I thought that the Timer stuff was a hint that the crash might be related to “App Nap,” but disabling that for the app didn’t seem to make any difference. Or perhaps it’s really something going on in the host application (Acrobat). I mean, all our plug-in is doing here is calling RunStandardAlert. If only I could somehow get engineers from Apple and Adobe in the same room with me and the debugger…. On Mar 25, 2015, at 5:37 PM, Quincey Morris <[email protected]<mailto:[email protected]>> wrote: It’s hard to predict, but the outcome is probably one of the extremes (it takes a couple of hours vs. it’s going to take weeks), and a day or two spent on finding out is not wasted. The most significant negative indicator is garbage collection. If your app uses it, there’s a good chance that a major** app redesign is needed, because you’ll have to devise strategies for preventing unwanted reference cycles in ARC. ** “Major” not so much in the sense of much code rewritten, but rather that very fundamental assumptions may have to be revised, causing outward spreading ripples. That’s actually a fairly optimistic assessment, which assumes that one is already dealing with a Cocoa/Objective-C app. For those of us still using Carbon and C++, the most significant negative indicator is moving to Cocoa in the first place. Or at least, in our cross-platform Windows and Mac product, moving to a UI abstraction library (or a version thereof) which is implemented in Cocoa. For those of us who have formatted text editing controls based on Carbon and ATS and such, porting that to Cocoa is a pretty big challenge as well. It also assumes that what one is developing is actually an app. Some of us are building plug-ins to other applications like Acrobat and InDesign, or at least such plug-ins are a major part of our product, along with some standalone applications. But at least you’re not assuming that everyone is building iOS apps. ;^) Thanks, Dan _______________________________________________ Do not post admin requests to the list. They will be ignored. Xcode-users mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/xcode-users/archive%40mail-archive.com This email sent to [email protected]
