Error: SIGABRT and NSThread

Discussion in 'iOS Programming' started by arnieterm, Aug 20, 2009.

  1. arnieterm macrumors regular

    Joined:
    Aug 28, 2008
    #1
    Hi all
    In my 4 tab based UITabBarController application, each tab is using NSThread detachNewThread/performSelectorOnMainThread methods to fetch data from web service.
    My problem is that, if I quickly tap randomly the tabs of the UITabBar then I get the SIGABRT error
    I am not able to get through this error
    Can anybody explain about this error?
    THanks
     
  2. Verda macrumors newbie

    Joined:
    Sep 18, 2009
    #2
    Sigabrt

    In my experience, once this error starts, the only way to fix it is to create a brand new project file. Nothing seems to get rid of it once it starts in a project file. The error messages are so rudimentary, it reminds me of my days when I wrote software for Commodore 64 or Pascal on Macintosh SE. I bet most of you are clueless about my references.

    Does anyone know how to reset this crazy error flag or whatever is happening. Please do not tell us to restart our machines because it happens on the IPhone simulator as well..
     
  3. PhoneyDeveloper macrumors 68030

    PhoneyDeveloper

    Joined:
    Sep 2, 2008
    #3
    arnie, is there more information in the console?

    You might want to look at

    man signal

    and google SIGABRT iPhone

    Verda, thanks for the laugh. That's a funny post. Do you throw out your car when the ash-tray gets full?
     
  4. Darkroom Guest

    Darkroom

    Joined:
    Dec 15, 2006
    Location:
    Montréal, Canada
    #4
    i've read a post somewhere from a developer who claims to have submitted an app to apple, was refused because of a SIGABRT crash (on apple's computer, the developer never experienced such a crash), then s/he resubmitted to apple without changing anything and it went thru. take from that what you will.
     
  5. firewood macrumors 604

    Joined:
    Jul 29, 2003
    Location:
    Silicon Valley
    #5
    It might be memory corruption, that's a serious problem, but it's also the type of problem that whether and where it occurs could depend on the state of the moon.

    Try setting breakpoints in the memory handlers (type these into the debugger console window when the app is paused):

    fb objc_exception_throw
    fb malloc_error_break
    fb szone_error

    and see if the variables window shows your app working with a bad pointer of some sort.
     
  6. LeenaTekani macrumors newbie

    Joined:
    Sep 7, 2010
    #6
    Sigabrt Error

    wenever i run navigation based application it get crashed because of SIGABRT ERROR can anyone help me??
     
  7. PhoneyDeveloper macrumors 68030

    PhoneyDeveloper

    Joined:
    Sep 2, 2008
    #7
    The SIGABRT error occurs due to an assertion failure. Assertions look like this

    Code:
    NSAssert(myPointer != nil, @"myPointer was nil!");
    When an assertion like this is encountered in the code the condition is checked and if it is false then an exception is thrown. This exception causes the message to be written to the debugger console and the app is terminated.

    Something like this occurs:

    Code:
    if (! (myPointer != nil))
         throw assertion with text @"myPointer was nil!";
    
    Assertions like this have been placed in the UIKit and Foundation code to notify the programmer of an error condition as soon as possible when the error is detected. For instance if an 'out of bounds' error occurs with an NSArray (calling objectAtIndex with an index that is >= count) then an assertion failure occurs.

    Basic debugging of assertion failures consists of these things: set a breakpoint using the Run > Stop on Objective-C Exceptions menu item, run your app in the debugger so that the assertion error occurs, inspect the debugger console for the message, and inspect the stack trace in the debugger to see where in your code the failure has occurred. It's usually clear what the error is. In fact each error comes with its own explanation in the debugger console. It is possible for assertions to occur that don't trace back into your app's code, for instance for certain errors with how a nib is hooked up. But the debugger console always has the error message that will help to diagnose the problem.

    Experienced developers use NSAssert() in their own code to help find bugs faster.
     
  8. Luke Redpath macrumors 6502a

    Joined:
    Nov 9, 2007
    Location:
    Colchester, UK
    #8
    Some general advice: if you are using threads to do your networking, you are doing it wrong.

    You should try and use asynchronous APIs where they are available, otherwise you might want to look at NSOperation and if you are targeting iOS4 only, GCD.

    More on this (Apple dev forums link):
    https://devforums.apple.com/thread/9606?tstart=0
     

Share This Page