Here's the screen capture that demonstrates this issue: http://www.vimeo.com/8208563
This time around, I got a few errors logged in Console: *** -[NSRecursiveLock unlock]: lock (<NSRecursiveLock: 0x16c2340> '(null)') unlocked from thread which did not lock it *** Break on _NSLockError() to debug. *** -[NSRecursiveLock unlock]: lock (<NSRecursiveLock: 0x16c2340> '(null)') unlocked when not locked *** Break on _NSLockError() to debug. *** -[NSRecursiveLock finalize]: lock (<NSRecursiveLock: 0x16c2340> '(null)') finalized while still in use *** Break on _NSLockError() to debug. *** -[NSRecursiveLock finalize]: lock (<NSRecursiveLock: 0x16ca9c0> '(null)') finalized while still in use *** Break on _NSLockError() to debug. I've gotten these before, and they don't seem to affect the operation of the app so I doubt this is what's causing my problem, however I have set a breakpoint on _NSLockError to catch this next time (It happens randomly, not all the time). In the meanwhile, I directly launched the apps executable using Terminal, and here is the error it logs: fail: 'Error Domain=NSURLErrorDomain Code=-1012 UserInfo=0x2004dad80 "The operation couldn’t be completed. (NSURLErrorDomain error -1012.)" Underlying Error=(Error Domain=kCFErrorDomainCFNetwork Code=-1012 UserInfo=0x2004dad00 "The operation couldn’t be completed. (kCFErrorDomainCFNetwork error -1012.)")' This would explain my apps screwup. If it can't connect then that would explain the request timed out and authentication errors. The problem is, I have no idea why this only happens on the Release config *when launched from Finder* And I don't know how to debug this, as this problem doesn't occur when the app is launched by Xcode. Is there a way to load an executable into gdb manually? Thanks On 2009-12-15, at 5:43 PM, Kyle Sluder wrote: > On Tue, Dec 15, 2009 at 4:34 PM, PCWiz <pcwiz.supp...@gmail.com> wrote: >> I don't know why this is happening. I don't think its an issue with my code >> if it works in Debug (Xcode & Finder) and Release (Xcode only). > > Two rules of software development: > Rule 1: Check again. It's probably your fault. > Rule 2: It's still probably your fault. > >> My build configurations for both Debug and Release are identical (I haven't >> checked thoroughly, but I know I didnt change much). Both configs are set to >> use the LLVM GCC 4.2 compiler, and GC is set to Required. The only other >> change I've made is adding a few header search paths. > > When it comes to debugging, there is no such thing as "not checking > thoroughly." There is only "Checking thoroughly" and "not checking at > all." "Checking thoroughly" means proving (not convincing, but > actually sitting down with a backtraces, a debugger, and even > single-stepping through your source code if necessary) that your > program is behaving as designed. > > So, run your release-built app from inside gdb (yes, you can run a > non-debug app inside a debugger). When it does something wrong, trap > that error in the debugger and figure out what happened. Then fix > your bug. Rinse, repeat. > > --Kyle Sluder _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
