Re: Totally stumped on extern NSString
Re: Totally stumped on extern NSString
- Subject: Re: Totally stumped on extern NSString
- From: William Squires <email@hidden>
- Date: Sat, 7 Jul 2007 21:12:30 -0500
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