Crash caused by excessive wakeup calls by AIR on iOS 8.2

[zingtime]

We have an iPad app that runs continuously in hospital clinics. About once a day, the app crashes because of "excessive wakeups" (crash details below). The app isn't doing a lot of things -- it's mostly a branching app that shows different text and video, depending on which buttons the user taps. To lock the iPad so that it can only run this one app, we use Apple's Guided Access feature (I don't know if this is relevant).

I searched the forums and only found one reference to the wakeups issue, which was mentioned in February 2015. There weren't any answers to that post.

Has anyone else seen this? Can any Adobe engineers give me tips on what might be causing this or where to look?

Thanks,

John

--------------

Details...

AIR version: 15

Hardware Model:      iPad4,2

Code Type:           ARM (Native)

Parent Process:      launchd [1]

OS Version:          iOS 8.2 (12D508)

Report Version:      105

Exception Type:  EXC_RESOURCE

Exception Subtype: WAKEUPS

Exception Message: (Limit 150/sec) Observed 218/sec over 300 secs

Triggered by Thread:  0

[kheftel]

I'm not an adobe engineer, but I'm sure they will ask you what version of AIR SDK the app was built with.

[zingtime]

Yes, thanks. I mentioned in the details section that it was AIR version 15.

[kheftel]

My bad, sorry for the noise.

[Anki_AG_]

Hi,

Thanks for reporting the issue. Could you please try with latest AID SDK and let us know if the Crash persists?

Thanks,

Adobe Air Team

[tdwivedi]

Hi Zingtime,

Correct me if I'm wrong, but I guess you must be facing this issue in iOS 8 devices only. Background threads in iOS 8 have a limit on how many times you can run a sleep/wake cycle on each thread per second. This app seems to send a wakeup command a lot of times to some thread - around 218/second. This may be caused by some problem in thread management. We will need a sample AIR project to suggest anything more than this.

Thanks,

Tushar Dwivedi,

Adobe Air Team

[zingtime]

Thanks for the reply. I'm not sure if it's iOS 8 only, and I'm having a hard time reproducing the crash at my office after letting it run for 24 hours. I only see the crash results on the iPad after the fact.

I can send the code for the project to someone, if that will help. Who would I send it to?

In the meantime, do you have any recommendations for how to force an excess number of wakeups? I figure if I can force the crash, then I can see if it helps to try the latest AIR SDK or make other changes.

Also, here is a little more info about the project:

- Uses Starling.

- Uses video playing in a webview (with darkredz ANE).

- Uses Apple's Guided Access to lock out app switching.

Do any of these things seem more likely to cause issues with thread management? I'm guessing that the app never goes into background mode, since it's locked to this one app. But would the iPad going to sleep force it into background mode somehow?

Thanks for the help.

John

[tdwivedi]

Hi,

You can send me the link to your code / sample project in a personal message, may be on dropbox or a similar service.

-Tushar

[zingtime]

I sent the source code last week by personal message, but I'm not sure if you received it. Did it make it through?

Thanks,

John

[tdwivedi]

Hi Zingtime,

What we have received seems to be the complete source code of the application. So, it's being difficult to proceed, and find out the cause of the issue, as it's not possible (or right) for us to go through the entire source code. Though we are trying to proceed with it, but it would be great if you can narrow it down to a sample application with the functionality (APIs) you may find to be the culprit, and share it with us.

-Tushar

[zingtime]

Hi Tushar,

Thanks for trying. The problem is intermittent, and we haven't been able to identify any particular part of the app that might be the cause. I thought you might have some debugging tools that could identify an issue, but if there's nothing obviously wrong, then we'll just keep trying to reproduce the problem.

Thanks,

John