Program received signal: “SIGKILL”.

Member
Posts: 38
Joined: 2008.09
Post: #1
I just installed the new SDK and my application is acting differently when it "closes".

When I close my application (pushing the home button) it goes in the background (i dont like it, but whatever), but once I close it via the "task bar", xcode says "Program received signal: “SIGKILL” and the debugger is hung.

If I create a new project, run in the simulator and push the home button it the application closes, it doesnt go into the task bar.

1) How do I fix my app to handle this new style with the multi task
OR
2) How does my application exit like in the previous OS?
Quote this message in a reply
Moderator
Posts: 133
Joined: 2008.05
Post: #2
Add the UIApplicationExitsOnSuspend to your Info.plist and check the box next to it.
Quote this message in a reply
Member
Posts: 38
Joined: 2008.09
Post: #3
Awesome, that worked, thanks.
Quote this message in a reply
Member
Posts: 87
Joined: 2006.08
Post: #4
Except that Apple made multitasking default because users will expect you to adopt it.

You're trading one problem for another.
Quote this message in a reply
Moderator
Posts: 133
Joined: 2008.05
Post: #5
If you read the docs, they say the opposite. Especially for games.
Quote this message in a reply
Member
Posts: 87
Joined: 2006.08
Post: #6
longjumper Wrote:If you read the docs, they say the opposite. Especially for games.

Can you provide a more concrete link? I cannot find that statement. Once you point it out, I'll look into having the docs fixed.
Quote this message in a reply
Moderator
Posts: 133
Joined: 2008.05
Post: #7
Quote:Opting out of background execution may be preferable for certain types of applications. Specifically, if coding for the background may require adding significant complexity to your application, terminating the application may be a simpler solution. Also, if your application consumes a large amount of memory, the system might need to terminate your application quickly anyway to make room for other applications. Thus, opting to terminate, instead of switch to the background, might yield the same results and save you development time and effort.

So, it is most certainly not a "problem" to opt out of background execution. Although "opposite" wasn't exactly the best word to use.

Just because something is or is not in the template project doesn't make it the best way of doing it. Making applications default to "multitasking" is a marketing ploy. By defaulting applications to suspend, iOS users can open and close an application and then say, "Look, I have multi-tasking now!"
Quote this message in a reply
Member
Posts: 87
Joined: 2006.08
Post: #8
longjumper Wrote:Making applications default to "multitasking" is a marketing ploy. By defaulting applications to suspend, iOS users can open and close an application and then say, "Look, I have multi-tasking now!"

It is only a 'marketing ploy' if you feel that there is no end-user value to reduced time to switch between apps. Games are uniquely suited to benefit the most from this arrangement, as they tend to the types of applications that need the longest to load. The last thing you want to do is to force the user to wait tens of seconds to get back into their game after a brief user diversion to another app. Those games that explicitly try to avoid meeting the users needs will still be compared to those that do meet user needs.

Please see the video of WWDC Session 415, OpenGL ES Overview for iPhone OS, which discusses exactly this issue.
Quote this message in a reply
Moderator
Posts: 133
Joined: 2008.05
Post: #9
The load times of bigger games when switching to do a quick task is a good point.

But, I'm wondering how long a 10-second-to-load game will survive suspension. I suppose keeping multitasking on doesn't really hurt anything in that case. Unless it's unreasonably difficult to implement it.

The basis of my point is that even though multitasking is on by default, that doesn't mean it makes sense for all applications.
Quote this message in a reply
Nibbie
Posts: 2
Joined: 2010.06
Post: #10
Any ideas on what would cause the error? I'm getting the same thing using cocos2d. In my case, not only do I get the SIGKILL, but after that the app won't load at all. I'm guessing others will run into this too. Thanks.
Quote this message in a reply
Nibbie
Posts: 2
Joined: 2010.06
Post: #11
I've noticed this only happens to me in the debugger. Could it be just a glitch of some sort with the debugger?
Quote this message in a reply
Member
Posts: 38
Joined: 2008.09
Post: #12
My opinion on the topic of todo multi-tasking vs not, should be that the default setting should of automatically closed the application instead of putting it in the background (from a developer's view and customer view). I already know how my applications work, I dont want it to change because I or customer installed a new version of the OS.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #13
If you don't want to have to update your code, don't change your SDK. Any newer SDK always means you may have to update your code.

Just be aware you'll be stuck in the past, unable to adopt new OS features, and if you ever need to use a newer SDK for whatever reason, you'll have the sum of all the intermediary SDKs' differences to deal with all at once.
Quote this message in a reply
Member
Posts: 40
Joined: 2009.05
Post: #14
On a side not, you should make sure you do any state saving in the applicationDidEnterBackground method on the app delegate.

Once you are in the background then you might be killed at any time - and this means killed rather than being shut down nicely, applicationWillTerminate does not get called.
Quote this message in a reply
Member
Posts: 87
Joined: 2006.08
Post: #15
wmwilson Wrote:I've noticed this only happens to me in the debugger. Could it be just a glitch of some sort with the debugger?

The issue is that drawing with OpenGL in the background is disallowed, to ensure UI responsiveness. You can keep your GL resources around, to allow for a quick resume, but you cannot draw.

Your access to the GPU ends when your app returns from -appDidEnterBackground.

In the normal case, you're lucking out that your process simply isn't scheduled, and so you don't get the opportunity to attempt drawing. In the debugger, processes are not suspended (because that tends to make debugging very difficult), so your app tries to continue drawing.

To resolve this, you simply need to halt animation before returning from -appDidEnterBackground, and resume animation in -appWillEnterForeground.
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  How can I smooth accelerometer signal? riruilo 6 8,782 Feb 10, 2009 04:53 PM
Last Post: riruilo