On Nov 24, 2014, at 3:03 AM, Markus Spoettl <[email protected]> wrote: > > I'm attaching the call stack of the crash in the hope that someone on the > list recognizes it. Any ideas what might be going on?
Is this 10.10? And the libs are still using FSRef underneath their implementations??? Hoo boy. I've seen 10.10 get into a state where FSPathMakeRef will report fnfErr when the file is sitting right there, with correct permissions. In fact, you can stat the file without error, then immediately call FSPathMakeRef with the same path, and get an error. (Full path, only a-z & 0-9 in any of the names...) I've also seen the case of: 1) get an FSRef, 2) create a new file elsewhere, 3) FSRefMakePath on the FSRef now fails. Unfortunately I haven't been able to figure out anything about the circumstances except that PID 1 was going crazy at the time, and a reboot fixed everything. I simply eliminated all my FSRef code, which I had intended to do RSN anyway, and replaced with plain POSIX stuff. But if 10.10 is using FSRefs in the implementation of Cocoa, I guess other people are going to trip over the bugs... So I have no idea if this is related or not. But a few things for you to possibly find out: is there a lot of file manipulation being done on that Mac, is performance of everything sluggish before this happens, and will it work after a reboot. -- Scott Ribe [email protected] http://www.elevated-dev.com/ (303) 722-0567 voice _______________________________________________ Cocoa-dev mailing list ([email protected]) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
