Reputation: 13
I have a very strange issue with a very simple "demo" application. Basically the issue is that if I make a class method call with a single argument and this method returns immediately but has variables defined after the return (see below) then the call stack gets damaged and some other variables are changed... I know that this sounds crazy but here is the code...
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
// Override point for customization after application launch.
[self.window makeKeyAndVisible];
NSError *er=[MLRESTRequest test:nil]; //<- this line modifies the "application" variable passed as first argument!
return YES;
}
@implementation MLRESTRequest
+ (NSError*) test:(id)task
{
return nil;
NSURLResponse *responseHeaders=nil;
NSDictionary *responseHeadersDict=nil;
NSError *error=nil;
NSData *result=nil;
NSURL *urlToCall = nil;
NSMutableURLRequest *urlRequest=nil;
NSString *serverRequest=nil;
NSString *cookie=nil;
NSString *server=nil;
NSString *port=nil;
NSString *call=nil;
//return nil;
}
@end
If I move the return at the end of the "test" method then all is OK...
Edit: I post images of the issue in comments
Edit2: I re-imaged the mac and installed a fresh copy of xCode 3.2.6 - the problem vanished. Sadly after few days I started to have similar issues...(a stack variable gets changed without any reason after returning from function call)... I recompiled exactly the same code on 3.2.5 and 4.0 and the issue vanished again... I don't know what to do but for now will stay away from 3.2.6
Edit3: If some one is still interested about this case - I have proves that the GCC 4.2 used in 3.2.6 is buggy - if the LLVM + GCC 4.2 is used then there is no crash
Upvotes: 1
Views: 213
Reputation: 3386
Based on your comment to Joshua Weinberg, it sounds like you are trying to access variables that have been optimized away, i.e. the variables that are declared below the return. Don't do that!
Upvotes: 0
Reputation: 162712
The only way application
is going to be modified in that code, as posted, is if you are compiling with optimization enabled. End of story.
The implementation of test:
, regardless of where the return statement is, does pretty much absolutely nothing and it certainly won't affect the parent stack frame.
As Joshua said, you haven't given enough information to tell you what is going on. Post the crash's backtrace, for starters.
Upvotes: 1
Reputation: 28688
Are you debugging this in release mode? Or Debug mode? If you're in release mode, you can't really trust anything the debugger tells you about this kind of thing.
Upvotes: 2