Re: How to debug crash in NSOperation?

is highly speculative, and other people may have reasons to argue that > such a reordering cannot legally take place, but if you use a non-atomic > write you eliminate any possible timing window on the directory scan, I think. I will abandon the atomic write and just rely on the

Re: How to debug crash in NSOperation?

y scan, I think. That doesn’t really touch the “how to debug?” question, to which I don’t know the answer, except to suggest you play around trying to make the problem more reproducible. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post

Re: How to debug crash in NSOperation?

Sent from my iPhone > On 28 Mar 2017, at 10:32, Jens Alfke wrote: > > >> On Mar 27, 2017, at 8:25 PM, Gerriet M. Denkmann wrote: >> >> >> >> Sent from my iPhone >> >>> On 27 Mar 2017, at 23:37, Jens Alfke wrote: >>> >>>

Re: How to debug crash in NSOperation?

> On Mar 27, 2017, at 8:25 PM, Gerriet M. Denkmann wrote: > > > > Sent from my iPhone > > On 27 Mar 2017, at 23:37, Jens Alfke > wrote: > >> >>> On Mar 26, 2017, at 10:04 PM, Gerriet M. Denkmann

Re: How to debug crash in NSOperation?

Sent from my iPhone > On 27 Mar 2017, at 23:37, Jens Alfke wrote: > > >> On Mar 26, 2017, at 10:04 PM, Gerriet M. Denkmann >> wrote: >> >> Yes, you are right. And I have to apologise for not spotting this: >> >> *** Terminating app due to uncaught

Re: How to debug crash in NSOperation?

> On Mar 26, 2017, at 10:04 PM, Gerriet M. Denkmann wrote: > > Yes, you are right. And I have to apologise for not spotting this: > > *** Terminating app due to uncaught exception 'NSInvalidArgumentException', > reason: '*** setObjectForKey: object cannot be nil (key:

Re: How to debug crash in NSOperation?

> On 27 Mar 2017, at 10:39, Ken Thomases wrote: > > On Mar 26, 2017, at 10:06 PM, Gerriet M. Denkmann wrote: >> >> macOS 12.3 >> >> This is a rather rare bug (never seen before): >> >> Thread 12 Crashed:: Dispatch queue: เสือ :: NSOperation

Re: How to debug crash in NSOperation?

On Mar 26, 2017, at 10:06 PM, Gerriet M. Denkmann wrote: > > macOS 12.3 > > This is a rather rare bug (never seen before): > > Thread 12 Crashed:: Dispatch queue: เสือ :: NSOperation 0x61800184fbd0 (QOS: > UTILITY) > 0 libsystem_kernel.dylib

How to debug crash in NSOperation?

on: weakBo ]; } ]; [ self.commandOperationQueue addOperation: echoOperation ]; } // this probably is never called: - (void)cancelEchoOperations: (BOOL)explicit; { [ self.commandOperationQueue cancelAllOperations ]; … } Any ideas how to debug this? Gerriet. ___

How to debug [NSObject(NSKeyValueObserverNotification) willChangeValueForKey:] crash

Our app is using a custom split view controller that we're getting rid of for the next major release, but for the CURRENT release we still have it. The problem I have is that on iOS 9 we're seeing the above when we hide the master view and show it a few times over and over agian. Its random

How to debug a binding exception?

Things are working mostly fine with my app, but I discover an exception if I close a document which has not been saved, and elect to discard the document: * thread #1: tid = 0x51dfe8, 0x7fff9393b743 libobjc.A.dylib`objc_exception_throw, queue = 'com.apple.main-thread', stop reason =

Re: How to debug a binding exception?

___ 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:

Re: How to debug a binding exception?

On Jun 2, 2015, at 02:36 , John Brownie john_brow...@sil.org wrote: * thread #1: tid = 0x51dfe8, 0x7fff9393b743 libobjc.A.dylib`objc_exception_throw, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1 Have you tried continuing after the exception? The next thing it should do

How to debug this?

Hi everybody, unfortunately I can't be more precise than the title. Here's what I get Thread 0 Crashed: Dispatch queue: com.apple.main-thread 0 libobjc.A.dylib 0x7fff8766c11c objc_msgSend + 40 1 com.apple.CoreFoundation 0x7fff882e9cc6 _CFAutoreleasePoolPop

Re: How to debug this?

On Sep 9, 2010, at 4:27 AM, Luca C. wrote: 0 libobjc.A.dylib 0x7fff8766c11c objc_msgSend + 40 1 com.apple.CoreFoundation 0x7fff882e9cc6 _CFAutoreleasePoolPop + 230 2 com.apple.Foundation 0x7fff87a4881a Classic overrelease problem.

Re: How to debug this?

Thanks for your reply - solved. The problem was because of a goto: placed before any init happened. 2010/9/9 Bill Bumgarner b...@mac.com On Sep 9, 2010, at 4:27 AM, Luca C. wrote: 0 libobjc.A.dylib 0x7fff8766c11c objc_msgSend + 40 1 com.apple.CoreFoundation

How to debug crash on startup of 64-bit build

I just transitioned my (primarily Cocoa based) code from building 32-bit i386/PPC, to also include x86_64. Unfortunately, when launching the 64-bit version I'm getting a crash at launch and I can't figure out how to debug it. Stack trace at the bottom of the email. - The crash does *not* occur

Re: How to debug crash on startup of 64-bit build

On Tue, Jul 6, 2010 at 9:47 AM, Jeffrey J. Early jeff...@jeffreyearly.com wrote: I just transitioned my (primarily Cocoa based) code from building 32-bit i386/PPC, to also include x86_64. Unfortunately, when launching the 64-bit version I'm getting a crash at launch and I can't figure out how

Re: How to debug crash on startup of 64-bit build

On Jul 6, 2010, at 11:47 AM, Jeffrey J. Early wrote: I just transitioned my (primarily Cocoa based) code from building 32-bit i386/PPC, to also include x86_64. Unfortunately, when launching the 64-bit version I'm getting a crash at launch and I can't figure out how to debug it. Stack trace

Re: How to debug crash on startup of 64-bit build

Jeffrey J. Early wrote: - The crash does *not* occur when the application (either release or debug build) is launched within Xcode. - The crash *does* occur if I launch the app with gdb from the command line (same stack trace). Inspect and then change things about your executable's

Re: How to debug crash on startup of 64-bit build

Much thanks to the three of you for your responses, with your help I was able to solve the problem. It was a dumb mistake on my part that was exposed due to different behavior in how dyld works (apparently?!). I have dependencies on a bunch of my own frameworks, and a few third party

Re: How to debug crash on startup of 64-bit build

Le 6 juil. 2010 à 22:49, Jeffrey J. Early a écrit : Importantly, I'm not calling any code framework A that depends on framework B. Because of this, in 32-bit mode, it ended up being totally okay that framework B was missing (presumably because it never had to resolve any symbols from that

Re: How to debug: Save partially failed: Error saving the persistent store.

On 23 Jun 2010, at 8:03 PM, Gideon King wrote: I am encountering this issue when trying to save my atomic store. The backtraces don't seem to give anything useful to locate the issue. Any suggestions as to how to find the cause of this? I wish you had mentioned the circumstances in which

How to debug: Save partially failed: Error saving the persistent store.

I am encountering this issue when trying to save my atomic store. The backtraces don't seem to give anything useful to locate the issue. Any suggestions as to how to find the cause of this? Thanks Gideon___ Cocoa-dev mailing list

Re: How to debug invalidated core data object

Hello, you might place some breakpoints, you did only post the consequences, debugging is matter of understanding. On Sun, Jun 13, 2010 at 8:49 AM, Gideon King gid...@novamind.com wrote: I have a situation where I create a temporary managed object context and do a bunch of things with

How to debug invalidated core data object

I have a situation where I create a temporary managed object context and do a bunch of things with various managed objects before releasing the context again. After this, there appears to be an asynchronous cleanup operation done by coredata, at which point I get an exception as per the trace

Re: How to debug invalidated core data object

On 2010 Jun 13, at 08:49, Gideon King wrote: I get an exception ... The NSManagedObject with ID:(whatever) has been invalidated. Those things always ruin my day. I don't think I've ever fixed one by debugging from the bottom up as you would like to do. The solution has always come from

Re: How to debug invalidated core data object

Thanks Jerry mm @mm The problem is I don't know what to put breakpoints on @jerry My understanding is that with the core data, they have their own memory management scheme which will reuse the space of something that has been invalidated, and that invalidated is not equal to deallocated. If I

Re: How to debug invalidated core data object

On 2010 Jun 13, at 17:34, Gideon King wrote: From the top down approach, the places I could envisage this problem originating are: 1. NSNotificationQueue - queued notifications that get fired after I have released the MOC, and the objects have been faulted and invalidated but not removed

Re: How to debug invalidated core data object

Thanks Jerry Whoops/sorry. I forgot that -[NSManagedObject valueForKey:] is an Apple method so all you get is stupid registers and no symbols. (Text is not colorized in email.) So there are two ways to do this. One way would be, assuming that all of your managed objects descend

Re: How to debug this error on closing a document?

Well I spent some of the day going through the application with the analyzer - first time I have used it, and I'm pretty impressed - I like the way it draws the lines showing the relevant lines of code...but although it did pick up some leaks etc, it made no difference to my specific problem.

Re: How to debug this error on closing a document?

On 2010 Mar 11, at 02:27, Gideon King wrote: or whether I would have to subclass NSConcreteNotification and override dealloc and then use pose as, so I could print out the notification name etc, to get the info That would work, but Method Replacement [1] was added in Objective-C 2.0 as a

How to debug this error on closing a document?

I have a core data based application, and use the NSPersistentDocument's -managedObjectContext to get my managed object context. As far as I can see, I do not retain or release it anywhere in my code, but apparently it is getting over released when I close my document. My test case is to start

Re: How to debug this error on closing a document?

On Wed, Mar 10, 2010 at 4:45 PM, Gideon King gid...@novamind.com wrote: Seeing as none of this appears to have anything to do with my code, I am assuming that some notification created somewhere in my application is somehow the cause, but I'm not sure how to track this down. Run the analyzer

Re: How to debug over-release of private Cocoa object?

On 16/09/2009, at 3:38 PM, Kyle Sluder wrote: Oh, you just made the text system *very* mad. Somewhere in the soca it says you must use -[NSTextStorage setTexrStorage:] to do what you want. You don't want to know the morass of code we have in OmniOutliner to support moving the text system

Re: How to debug over-release of private Cocoa object?

On Sep 15, 2009, at 11:17 PM, Graham Cox wrote: snip (Incidentally, I see in Snow Leopard that all such crashes get sent to Apple - there is no 'Cancel' button any more on the crash reports. Hope they are finding this entertaining - especially as it's increasingly looking like their bug

How to debug over-release of private Cocoa object?

be prepared to believe that something in the creation of the undo task is wrong where a bit more work is being done in my subclass, like coalescing identical consecutive tasks into one. Any pointers on how I might debug this? --Graham ___ Cocoa-dev

Re: How to debug over-release of private Cocoa object?

is being done in my subclass, like coalescing identical consecutive tasks into one. Any pointers on how I might debug this? Open Instruments, add the object allocation instrument, turn on reference count recording and zombie detection in the instrument, and then record your app. Do what you need

Re: How to debug over-release of private Cocoa object?

Open Instruments, add the object allocation instrument, turn on reference count recording and zombie detection in the instrument, and then record your app. Do what you need to do to reproduce the problem. When it triggers, you'll get a backtrace of both the offending access and everything

Re: How to debug over-release of private Cocoa object?

Open Instruments, add the object allocation instrument, turn on reference count recording and zombie detection in the instrument, and then record your app. Do what you need to do to reproduce the problem. When it triggers, you'll get a backtrace of both the offending access and everything

Re: How to debug over-release of private Cocoa object?

On Sep 15, 2009, at 8:40 PM, Graham Cox wrote: What seems weird to me is that there is no release or dealloc event for this. It jumps straight from ref count = 1 to being a zombie. How is that possible? Or am I not using the tool correctly? Are you sure you have reference counting also

Re: How to debug over-release of private Cocoa object?

On 16/09/2009, at 12:43 PM, Nick Zitzmann wrote: On Sep 15, 2009, at 8:40 PM, Graham Cox wrote: What seems weird to me is that there is no release or dealloc event for this. It jumps straight from ref count = 1 to being a zombie. How is that possible? Or am I not using the tool

Re: How to debug over-release of private Cocoa object?

On 16/09/2009, at 1:17 PM, Graham Cox wrote: I guess it's time to strip this down to a small reproducible case I can give them... OK, narrowing it down, the problem seems to be an interaction between NSTextView and NSUndoManager. So far I've discovered that: 1. If I disable undo for

Re: How to debug over-release of private Cocoa object?

On Sep 15, 2009, at 9:59 PM, Graham Cox graham@bigpond.com wrote: 3. I am re-using the textview for different edits, much like the field editor. This involves replacing the text storage for a new edit, by calling -replaceTextStorage on the text view's layout manager. Then, undo fails

Re: How to debug GC related EXC_BAD_ACCESS

On Nov 24, 2008, at 11:45 AM, Nirias wrote: I have a garbage collected application that runs (apparently) flawlessly with a debug build. But with a release build it promptly fails with an EXC_BAD_ACESS error. My guess is that somehow the GC is not seeing a clear reference to some

Re: How to debug this...

On 20-Mar-09, at 1:04 AM, Alex Kac wrote: 1 CoreFoundation 0x3023c326 CFRelease + 58 2 Foundation 0x3066fe04 -[NSCFDictionary release] + 2 3 CoreFoundation 0x3023c326 CFRelease + 58 4 Foundation

Re: How to debug this...

2.2 and 2.21 mostly. As I said - I can't reproduce this. I only get crash logs from users with it. I'm just trying to get some idea of what it could be. On Mar 20, 2009, at 4:57 AM, Mark Ritchie wrote: On 20-Mar-09, at 5:32 AM, Alex Kac wrote: iPhone OS :) And normally I'd ask on the

How to debug this...

I have tried for a few weeks now to try and decipher this myself on the web, the archives, etc... without success. The problem I have is that I cannot reproduce this myself. But I've had a few customers who have sent me their crash logs and they are all identical. About 500 lines of this:

How to debug a loadNib error in a Release version?

Folks; An Australian tester is reporting the crash shown below... How can I best attack this problem? What kind of IB setting causes a 'makeObjectsPerformSelector:'? I do not directly call such a method in my code at all. What do I make of the 'CFRelease' at frame 0? What can I do to facilitate

Re: How to debug a loadNib error in a Release version?

Corbin; Thanks for responding! I don't understand ..Symbolicate your backtrace.. Can you take a moment and educate me on this? Thanks! Steve On Jan 29, 2009, at 1:24 PM, Corbin Dunn wrote: On Jan 29, 2009, at 9:54 AM, Steve Cronin wrote: Folks; An Australian tester is reporting the crash

Re: How to debug a loadNib error in a Release version?

On Jan 29, 2009, at 1:54 PM, Steve Cronin wrote: I don't understand ..Symbolicate your backtrace.. Can you take a moment and educate me on this? You did keep the dSYM bundle used to build the release binary, right? If you did, then you can use dwarfdump with the --lookup flag to

Re: How to debug a loadNib error in a Release version?

On 1/29/09 1:54 PM, Steve Cronin said: Thanks for responding! I don't understand ..Symbolicate your backtrace.. Can you take a moment and educate me on this? http://developer.apple.com/technotes/tn2004/tn2123.html -- Sean McBride, B.

How to debug GC related EXC_BAD_ACCESS

I have a garbage collected application that runs (apparently) flawlessly with a debug build. But with a release build it promptly fails with an EXC_BAD_ACESS error. My guess is that somehow the GC is not seeing a clear reference to some object(s) and is releasing them too soon. Is there a

How to debug The Debugger has exited due to signal 10 (SIGBUS).

Hello Everyone, I am a newbie to Cocoa and just started getting this error as my app starts up: The Debugger has exited due to signal 10 (SIGBUS).The Debugger has exited due to signal 10 (SIGBUS). I am having trouble debugging this because I do not know what this means. I also don't

Re: How to debug a corrupted stack

On 7 Aug 2008, at 01:16, Sean McBride wrote: On 8/6/08 9:51 AM, Gerriet M. Denkmann said: So it is kind of difficult to see where and why the stack gets corrupted. Have you tried 'stack canaries'? http://lists.apple.com/archives/xcode-users/2007/Dec/msg00055.html I have not. Seems this

Re: How to debug a corrupted stack

On 6 Aug 2008, at 21:56, Shawn Erickson wrote: On Tue, Aug 5, 2008 at 7:51 PM, Gerriet M. Denkmann [EMAIL PROTECTED] wrote: I have a document based app which works perfectly with -O0 or -O1 but crashes with -O2 or higher. When the crash occurs the debugger comes up and says: Previous frame

Re: How to debug a corrupted stack

On Thu, Aug 7, 2008 at 11:28 AM, Gerriet M. Denkmann [EMAIL PROTECTED] wrote: Maybe someone would want to check this on Leopard. File a bug (http://bugreport.apple.com). That's the quickest way to make sure that 1) if it's a problem, it gets fixed or 2) if it's not a problem someone from Apple

Re: How to debug a corrupted stack

On 8 Aug 2008, at 01:59, Johannes Fortmann [EMAIL PROTECTED] wrote: The problem here is that UTCDateTime is defined with #pragma pack 2 in effect. That means the compiler packs with an alignment of 2, so the whole structure has 8 bytes. The proper alignment (4) results in 12 bytes. Since

Re: How to debug a corrupted stack

Gerriet M. Denkmann ([EMAIL PROTECTED]) on 2008-8-8 9:49 PM said: some_type a; NSValue *data = [ NSValue value: a withObjCType: @encode (some_type) ]; followed by: some_type b; [ data getValue: b ]; is unsafe, dangerous and strictly to be avoided - especially if the

Re: How to debug a corrupted stack

On Aug 7, 2008, at 9:49 PM, Gerriet M. Denkmann wrote: Or does anyone have a better idea? Define your own struct or Objective-C class that has the same members as UTCDateTime. Copy the values from a UTCDateTime to your struct or class. Encode/Decode your struct or class from NSValue.

Re: How to debug a corrupted stack

On 8 Aug 2008, at 09:04, Sean McBride wrote: Gerriet M. Denkmann ([EMAIL PROTECTED]) on 2008-8-8 9:49 PM said: some_type a; NSValue *data = [ NSValue value: a withObjCType: @encode (some_type) ]; followed by: some_type b; [ data getValue: b ]; is unsafe,

Re: How to debug a corrupted stack

On 6 Aug 2008, at 11:14, Ken Thomases wrote: On Aug 5, 2008, at 9:51 PM, Gerriet M. Denkmann wrote: I have a document based app which works perfectly with -O0 or -O1 but crashes with -O2 or higher. When the crash occurs the debugger comes up and says: Previous frame identical to this

Re: How to debug a corrupted stack

On Tue, Aug 5, 2008 at 7:51 PM, Gerriet M. Denkmann [EMAIL PROTECTED] wrote: I have a document based app which works perfectly with -O0 or -O1 but crashes with -O2 or higher. When the crash occurs the debugger comes up and says: Previous frame identical to this frame (corrupt stack?) When I

Re: How to debug a corrupted stack

On 8/6/08 9:51 AM, Gerriet M. Denkmann said: So it is kind of difficult to see where and why the stack gets corrupted. Have you tried 'stack canaries'? http://lists.apple.com/archives/xcode-users/2007/Dec/msg00055.html On 8/6/08 7:59 PM, Gerriet M. Denkmann said: If someone wants to check

How to debug a corrupted stack

I have a document based app which works perfectly with -O0 or -O1 but crashes with -O2 or higher. When the crash occurs the debugger comes up and says: Previous frame identical to this frame (corrupt stack?) When I try to step through the function (which is kind of difficult, as the

Re: How to debug a corrupted stack

On Aug 5, 2008, at 9:51 PM, Gerriet M. Denkmann wrote: I have a document based app which works perfectly with -O0 or -O1 but crashes with -O2 or higher. When the crash occurs the debugger comes up and says: Previous frame identical to this frame (corrupt stack?) When I try to step

How to debug Core Data save-as failure

Anyone got any suggestions about how to debug the following situation? I have a Core Data document application where saving the document works fine. But if I try to do a Save As instead (even a Save As immediately after opening or saving the document) Core Data throws an exception: #0

Mystery Thread - how to debug

I'm looking for any thoughts or feedback on this problem. I have an application that starts lots of threads. While it's cleaning up, it shuts most of them down. This is done through NSConditionalLock objects (i.e. tell task to quit, wait for conditional lock to transition to stopped state,

Re: Mystery Thread - how to debug

Any ideas? Cold comfort perhaps, but the way I've debugged similar problems in the past involved *lots* of logging, which of course can affect the bug ;-( -- Scott Ribe [EMAIL PROTECTED] http://www.killerbytes.com/ (303) 722-0567 voice ___

Re: How to debug a nib loading error?

On Mar 6, 2008, at 23:54, Steve Cronin wrote: If I set the NSZombieEnabled variable to YES I get the following: #0 0x9282b36d in -[NSException raise] #1 0x92852247 in +[NSException raise:format:] #2 0x928da79b in logMessageAndRaise #3 0x927dc8af in NSPopAutoreleasePool #4

How to debug a nib loading error?

Folks; Tiger 10.4.11 -- XC 2.4.1 I'm baffled by an IB error. Reasonable development has been on-going. Pretty stringent Build Rules and no errors or warnings. I decide to do a clean build, torch the app's prefs file and the CoreData store. I want to focus on the initial installation phase of