Debugger says variable is "Out of scope"

[haydnw]

I have a method which has suddenly started giving me some problems. It starts like this:

- (double) calcJulianDayNumber: (NSDate *) dateToConvert {
	
	// Get the day, month and year
	NSDateFormatter *dateFormatter = [[NSDateFormatter alloc] init];
	[dateFormatter setDateFormat:@"M"];
	double month = [[dateFormatter stringFromDate:dateToConvert] doubleValue];
	[dateFormatter setDateFormat:@"YYYY"];
	double year = [[dateFormatter stringFromDate:dateToConvert] doubleValue];
	[dateFormatter setDateFormat:@"d"];
	double day = [[dateFormatter stringFromDate:dateToConvert] doubleValue];
	[dateFormatter release];
	
	// Work out Julian Date / Julian Day Number
	...

And is called like this, in the same class:

- (void) refresh: (NSDate *) dateToRefreshTo {
	workingJDN = [self calcJulianDayNumber:dateToRefreshTo];
	...

However, when I run the code, the iPhone simulator crashes. The debugger tells me that 'dateToConvert' on the line

double month = [[dateFormatter stringFromDate:dateToConvert] doubleValue];

is "Out of scope".

The only problem I can think is that I'm calling refresh:aDate from a different class. This could mean that if I'm passing things by reference rather than by value, then in the methods above I'm trying to access a variable which belongs to the calling class, not self. Which I guess isn't allowed. Right?

As you can tell, I'm new to all of this! Any guidance or general thoughts would be much appreciated!

[jnorton]

Originally Posted by haydnw

I have a method which has suddenly started giving me some problems. It starts like this:

- (double) calcJulianDayNumber: (NSDate *) dateToConvert {
	
	// Get the day, month and year
	NSDateFormatter *dateFormatter = [[NSDateFormatter alloc] init];
	[dateFormatter setDateFormat:@"M"];
	double month = [[dateFormatter stringFromDate:dateToConvert] doubleValue];
	[dateFormatter setDateFormat:@"YYYY"];
	double year = [[dateFormatter stringFromDate:dateToConvert] doubleValue];
	[dateFormatter setDateFormat:@"d"];
	double day = [[dateFormatter stringFromDate:dateToConvert] doubleValue];
	[dateFormatter release];
	
	// Work out Julian Date / Julian Day Number
	...

And is called like this, in the same class:

- (void) refresh: (NSDate *) dateToRefreshTo {
	workingJDN = [self calcJulianDayNumber:dateToRefreshTo];
	...

However, when I run the code, the iPhone simulator crashes. The debugger tells me that 'dateToConvert' on the line

double month = [[dateFormatter stringFromDate:dateToConvert] doubleValue];

is "Out of scope".

The only problem I can think is that I'm calling refresh:aDate from a different class. This could mean that if I'm passing things by reference rather than by value, then in the methods above I'm trying to access a variable which belongs to the calling class, not self. Which I guess isn't allowed. Right?

As you can tell, I'm new to all of this! Any guidance or general thoughts would be much appreciated!

Don't know if you have solved this yet, but my guess would be that you need to retain your date object at the point of creation.

[Kalimba]

Originally Posted by jnorton

Don't know if you have solved this yet, but my guess would be that you need to retain your date object at the point of creation.

That might cause other issues, but shouldn't cause the debugger to display "Out of scope" for the variable name.

To the OP, is is possible that you have multiple instances of variable named 'dateToConvert' within your method? I've seen behavior in the compiler where I have multiple 'count' or 'i' variables (each in their own scope) and the compiler will show "Out of scope" for all instances of that variable except the one that is currently IN scope. Take a good look at all of the variables in the variable list window in the debugger to see if this is perhaps the case.

[jnorton]

Originally Posted by Kalimba

That might cause other issues, but shouldn't cause the debugger to display "Out of scope" for the variable name.

It will if the variable was created in a separate thread without being retained. I have seen this behavior before.

[Kalimba]

Originally Posted by jnorton

It will if the variable was created in a separate thread without being retained. I have seen this behavior before.

It makes no sense how the retained state of a variable would affect the debugger's ability to determine whether said variable was in or out of scope. I'd like to see an example of this.

[jnorton]

Originally Posted by Kalimba

It makes no sense how the retained state of a variable would affect the debugger's ability to determine whether said variable was in or out of scope. I'd like to see an example of this.

I agree that it makes no sense for the debugger to do this, but here you go:

//
//  TestRetainAppDelegate.m
//  TestRetain
//
//  Created by James Norton on 3/23/09.
//  Copyright __MyCompanyName__ 2009. All rights reserved.
//

#import "TestRetainAppDelegate.h"

@implementation TestRetainAppDelegate

@synthesize window;

NSTimer *timer1;
NSDate *date;

-(void)printDate:(NSString *)d{
	NSLog(d);
}

-(void)test:(NSDate *)parmDate {
	NSString *desc = [parmDate description];
	[self printDate:desc];
}

-(void)callBack1 {
	
	[self test:date];
}

-(void)callBack2 {
	NSAutoreleasePool *pool = [ [ NSAutoreleasePool alloc ] init ];
	
	date = [NSDate date];
//	[date retain];
	
	[pool release];
}


- (void)applicationDidFinishLaunching:(UIApplication *)application {    

    // Override point for customization after application launch
	timer1 = [NSTimer scheduledTimerWithTimeInterval:5 target:self selector:@selector(callBack1) userInfo:nil repeats:NO];
	
	[NSThread detachNewThreadSelector:@selector(callBack2) toTarget:self withObject:nil];
	
    [window makeKeyAndVisible];
}


- (void)dealloc {
    [window release];
    [super dealloc];
}


@end

Create a new Window-Based Application and replace the App-delegate with this code. Set a break point on line 23 (the first line of the test method) and debug. You should see parmDate labeled as "Out of scope".

Now uncomment line 26 (the retain) and debug again. Scoping problem goes away.

I don't know why this is, but it happens and I suspect this is the cause of the OP's problem.