Sunman
Sunman

Reputation: 13

XCode 3.2.6 stack damage after function call

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

Answers (3)

Richard
Richard

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

bbum
bbum

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

Joshua Weinberg
Joshua Weinberg

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

Related Questions