On Tue, Sep 16, 2008 at 12:50 PM, John Love <[EMAIL PROTECTED]> wrote: > +++++ > Michael Ash wrote: > > When your application becomes unresponsive, pause it in the debugger > and look at the backtraces of all the threads. (You can do this in a > single step by typing "t a a bt" at the debugger console. This is a > shortcut for "thread apply all backtrace".) This should quickly tell > you where it's stuck, and thus hopefully why it's stuck. > +++++ > > t a a bt looks like it could be a powerful tool, but, Michael, I do not > understand most of the following ..
I suggest you learn! Gdb is an extremely powerful, albeit difficult, tool. Trying to write anything substantial without it is, in my opinion, like a carpenter trying to build a house without using a measuring tape. Maybe you can do it, maybe you can even do it well, but it's going to take a lot more effort. Unlike the measuring tape, gdb takes a fair effort to learn, but just like the measuring tape, that effort pays off rapidly in the form of being able to work much more efficiently. There are a lot of guides available online that talk about how to use it. > I see some familar stuff, such as > MPWaitOnQueue and most of the listing at the very bottom .. but how is this > trace tell me where the hang is? If you in fact stopped the program while it was hung, then the trace shows exactly what each thread was doing at the time. The main thread (thread 0) is what handles the GUI, so you can see what it was doing instead of handling the GUI. As a really quick overview (hit up a tutorial for a more extensive discussion), the backtrace shows the current call stack for each thread. This call stack is read from bottom to top. For your backtrace looking at thread 0, for example, you can see that start() called NSApplicaitonMain(), which then called -[NSApplication run], and so forth. You can follow it up into your code, and see what your code was doing at the time. In this case -[ScriptController ExecAppleScript:] appears to be executing an AppleScript, and that's what was happening at the time you paused the debugger. > I do see "Cannot access memory at address > 0x0" with Thread3. Apparently, I've leaked memory or something rotten?? Gdb is occasionally unreliable. For some reason it was unable to figure out the backtrace of this thread. I wouldn't worry about it unless you see other symptoms. > By the way, I init the Queue within the -init of the app controller. Then, > in another method I go through a 100-count big for-loop, at each iteration > of which I init a new NSInvocationOperation via: > theOp = [[NSInvocationOperation alloc] initWithTarget:self > selector:@selector(calculateWorksheetRow:) object:nil]; > > followed by > > [theQueue addOperation:theOp]; > > and then, > > [theQueue waitUntilAllOperationsAreFinished]; Has it occurred to you that waiting for the operation to finish is rather at odds with the idea of trying to run it asynchronously to keep your program responsive? Mike _______________________________________________ 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 [EMAIL PROTECTED]
