Application developed in XCode 3.1.3 - OS X 10.5.7 crashing in XCode 3.2 - OS X 10.6

Discussion in 'Mac Programming' started by Monaj, Sep 6, 2009.

  1. Monaj macrumors regular

    May 24, 2009
    I had developed an application on Leopard :apple: and I tried to run it in snow leopard :apple: with settings- (10.5 | Debug | i386), (10.5 | Release | i386), (10.6 | Debug | i386) and (10.6 | Release | i386) but got following error message:- :eek:

    GDB: Program received signal: "EXC-BAD-ACCESS'. Thread-1-<>

    Can anyone suggest me what modifications I require so that it can also be executed in Snow Leopard :confused:

    I have one more question- Is there any way by which we can obtain binary for Snow Leopard without upgrading to Snow Leopard :confused:


  2. Catfish_Man macrumors 68030


    Sep 13, 2001
    Portland, OR
    That message just means "it crashed". Any of literally millions of things could be wrong.
  3. Bakerman macrumors member

    Jan 31, 2005
    If you run it through XCode, it automatically fires up the debugger for you. After you've got the BAD_ACCESS, hit shift-cmd-Y, to enter the debugger. If you're lucky, the crash is somewhere in your own code...
  4. gnasher729 macrumors P6


    Nov 25, 2005
    A binary that is built on a Tiger or Leopard machine for 10.4 or 10.5 will run on Snow Leopard, there is nothing you need to do. If you want to use features that are new in Snow Leopard, well, it would be complete madness if Apple let you develop this on a machine where you don't have the slightest possibility to test it. You can always get a cheap external hard drive and install Snow Leopard there if you don't want to upgrade your computer permanently.
  5. Monaj thread starter macrumors regular

    May 24, 2009
    Thanks, for all your replies!
    There is some more input on the problem which I found, I am getting error on this line -
    searchData = [NSURLConnection sendSynchronousRequest:postRequest returningResponse:&response error:&error];

    For first request it works correct but on second it fails and crashes! :(
  6. whooleytoo macrumors 603


    Aug 2, 2002
    Cork, Ireland.
    Can you more of the code - my guess is it's due to how the response and/or error parameters are created on the first and subsequent calls.
  7. Sayer macrumors 6502a


    Jan 4, 2002
    Austin, TX
    Sounds like something is being released after the first call on Snow Leopard that isn't on Leopard.

    I use NSURLConnection in a few things and I believe they are all one-shot calls. That is, you make the objects, send the request, and that's the end of it. To send a second request I make all new objects.

    Sounds like that is where the core problem lies.
  8. Monaj thread starter macrumors regular

    May 24, 2009
    In my code after using :
    searchData =[NSURLConnection sendSynchronousRequest:postRequest returningResponse:&response error:&error];

    I am using this line to check if action is successful or not-

    if([error code]==0){
    // action considered to be successful
    // re-attempt to perform the action

    :rolleyes: my guess is that error will never give (null). However when I am trying to get the log - NSLog(@"error code- %d",[error code]); it does not show for the second time, may be it is somehow getting- (null)
  9. Monaj thread starter macrumors regular

    May 24, 2009
    I must remind you all guys that the application was running successfully in Leopard.
  10. gnasher729 macrumors P6


    Nov 25, 2005
    So two possibilities: You ran into a bug in Snow Leopard that escaped the attention of all the developers at Apple, plus lots of beta testers in the world, but your code found it. Or your code contains some stupid bug which crashes on one machine but not on another machine. Which one is more likely?

    You assume that error != nil. Can you remember an old saying involving the words "assume", "ass", "you" and "me"?
    Do you know what a breakpoint is? Do you know what a source code debugger is?

    The documentation actually says that error will only be set when an error happens. Check for success by checking that the NSData* returned is not nil.

Share This Page