More info:
More info:
- Subject: More info:
- From: William Squires <email@hidden>
- Date: Sat, 7 Jul 2007 21:39:14 -0500
It now seems as if you can't debug a "Foundation tool" project if
it uses stdin, as it will conflict with gdb's use of the Debug
console! :(
Is there some way to make gdb redirect to /dev/null so that only
Xcode can talk to it? Or, failing that, redirect stdin/stdout to the
the "Run Log" instead so that gdb can continue to use the debug console?
Thinking this was some weird autorelease pool problem, I ran it
under MallocDebug, but didn't learn anything useful. And I totally
have no clue about how to get ObjectAlloc to do anything useful... (I
clicked Debug > Launch Using Performance Tool > ObjectAlloc which
opened a window, but just sat there. So I clicked "Run..." and
selected the MyAddressBook debug build executable, but - again -
nothing useful. I give up.)
On Jul 7, 2007, at 9:12 PM, William Squires wrote:
Now the debugger is not respecting breakpoints!?!?
In attempting to find out where the above NSString is being
initialized, I put some breakpoints into the statement that
allocates the AddressBook in Controller.m:
- (BOOL)processUserChoice:(NSString *) choice
{
BOOL shouldStop = NO;
NSString *outputString;
Class commClass = [commandClassForChoiceDict objectForKey:choice];
*if (commClass == Nil) // * = breakpoint
{
outputString = @"Invalid choice.";
}
else
{
NSDictionary *infoDict = [self
requestCommandInfoFromUser:commClass];
* AddressBook *ab = [AddressBook sharedAddressBook];
* Command *comm = [[[commClass alloc] initWithAddressBook:ab]
autorelease];
* outputString = [comm executeWithInfoDictionary:infoDict]; // This
is the line that led to the problem
// call
sequence.
if (outputString == nil)
{
shouldStop = YES;
}
else
{
// Append new line
outputString = [outputString stringByAppendingString:@"\n"];
}
}
if (outputString != nil)
{
WriteToStandardOutput(outputString);
}
return shouldStop;
}
This whole bit is called from main() which asks the user for a
command (only one so far = 'q'->quit). Once the user (me) types "q"
and <Return>, the debugger pauses at the breakpoint on the
* AddressBook *ab = ...
line for about a second, then continues without warning until it
crashes as described in the previous post!
While I've seen this sort of weird debugger behavior in REALbasic,
I didn't expect to see gdb do it! :( And there aren't any other
threads or timers running (that I know of). The debugger arrow is
pointing to the
outputString = [comm executeWithInfoDictionary:infoDict];
line (when I examine that part of the call chain for thread 1) at
the time of the crash
Not only that, but it doesnt stop on the first breakpoint:
*if (commClass == Nil)
Yikes!
On Jul 7, 2007, at 8:25 PM, Fritz Anderson wrote:
On 7 Jul 2007, at 6:45 PM, William Squires wrote:
- (void)writeToFile:(NSString *) path
{
...
}
+ (void)writeSharedAddressBookToFile
{
// Added as a debug aid..
NSString *localStr = [NSString
stringWithString:AddressBookFilePath];
// ...
[[AddressBook sharedAddressBook] writeToFile:localStr];
}
...
@end
(uninteresting parts trimmed for brevity... :) )
...
[The -writeToFile: method fails...]
because path = nil, but when I click on the stack crawl to view
the calling method, I can see (in the Globals Browser) that
AddressBookFilePath is initialized and has a valid NSString in
it! Why is the call losing the NSString pointer value?
If your "interesting parts" demonstrate that there is no bug, and
you have a bug, then something is going on in the parts you think
are uninteresting. For instance, your excerpts never show
AddressBookFilePath being initialized.
I'd break at the first line of -writeSharedAddressBookToFile and
try a print-object on AddressBookFilePath (enter 'po
AddressBookFilePath' in the debugger console). If it's nil, then
you've learned something.
I'd do a global find on AddressBookFilePath, to verify that it is
defined only once. I would put a breakpoint on every assignment to
AddressBookFilePath, to see the last value it was given.
(You are gate-keeping AddressBookFilePath with accessor methods,
aren't you? If so, why are you making the variable globally-
accessible?)
I know I'm asking you to do things for which you feel you already
know the answers, but if everything is going as you think it
should, then you don't have a bug.
— F
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden