IOS Air Application crashes without info


our team has been struggling for 2 weeks (Working and Personal), with the following issue regarding Ios deployment and Adobe Air. Below is a detailed message entailing the Application, our issue. If anyone can help us in debugging this task we'd greatly appreciate it.

The team is using IntelliJ/Flashbuilder setup with airsdk 17, the below description also affects AirSdk19, and the Beta Build AirSDK20. We are attempting to compile an Adobe Air project on IOS but are meeting a lot of trouble when an app is compiles using the AOT compiler mandated by Apple (our android app runs just fine using the JIT compiler).

Before I get into our issue, I'd like to discuss the App we are developing how it works, along with any specifications that may or may not be helpful in the Help Session.

How the App works: The way we have our App setup is we have a series of Activities each in their own swf, and the main app which is in it's own Swf aswell. Activities fall into two types: Explanation Activities and Challange Activities. All challange activities inherit from an ItemActivity Class, meanwhile all Explanation Activities inherit from an ItemActivityVideo class which in turn inherits from ItemActivity.

Our Inheritance structure for Activities is as Follows:

Explanation Activities:

Main (Specific for Each Activity) <- ItemActivityVideo <- ItemActivity

Challange Activities:

Main (Specific for Each Activity) <- ItemActivity.

The main Swf has a series of screens one of which the "ItemSelect" screen lays out a web of buttons each directing the app to load up one of the external activity swfs. All swf's are hosted locally alongside the main swf so there are no network calls when it comes to item Loading.

The Explanation Activities are the only ones that utilize sound this is located inside a "Voice Controller" class, whenever this class is referenced (simply via an instruction such as "new VoiceController()), the Ios App crashes, also certain item's are crashing at various parts of the timeline without any indication as to why from the Flash Debugger nor the crash log. The Debugger simply prints "Player Session Exited", meanwhile the crashlog results in a segfault signal "SigSegV", without any indication as to what caused the memory misuse.

Any assistance in helping our team be able to debug this Issue would help us out greatly, we are also having issues in regards to symbolicating the crash log using the dsymutils due to the drastic changes between the current Apple architecture and Adobes' dated documents.

Below is a segment of the Crash log of our App:

Incident Identifier: FC5E0968-20E5-4A52-BF7E-38FCBA425D00
CrashReporter Key:   ----------------------------------------------
Hardware Model:      iPad2,5
Process:             myApp [1848]
Path:                /private/var/mobile/Containers/Bundle/Application/30740408-6AAD-447E-8ED3-0ECAEF7A7B0A/
Identifier:          myApp
Version:             0.4.0 (0.4.0)
Code Type:           ARM (Native)
Parent Process:      launchd [1]

Date/Time:           2015-12-04 13:29:38.38 -0500
Launch Time:         2015-12-04 13:29:22.22 -0500
OS Version:          iOS 9.1 (13B143)
Report Version:      104

Exception Subtype: KERN_INVALID_ADDRESS at 0x00000083
Triggered by Thread:  0

Filtered syslog:
None found

Thread 0 name:  Dispatch queue:
Thread 0 Crashed:
0   myApp                       0x0248debe 0x74000 + 37854910
1   myApp                       0x00797598 0x74000 + 7484824
2   myApp                       0x00797598 0x74000 + 7484824
3   myApp                       0x00794b7c 0x74000 + 7474044
4   myApp                       0x007b6794 0x74000 + 7612308
5   myApp                       0x0247aab8 0x74000 + 37776056
6   myApp                       0x0248f926 0x74000 + 37861670
7   myApp                       0x024506b6 0x74000 + 37602998
8   myApp                       0x02450648 0x74000 + 37602888
9   myApp                       0x021fb188 0x74000 + 35156360
10  myApp                       0x0225027c 0x74000 + 35504764
11  myApp                       0x01facb90 0x74000 + 32738192
12  myApp                       0x01fb2650 0x74000 + 32761424
13  myApp                       0x0010b80c 0x74000 + 620556
14  myApp                       0x007b74d0 0x74000 + 7615696
15  myApp                       0x007eda9c 0x74000 + 7838364
16  myApp                       0x0247aab8 0x74000 + 37776056
17  myApp                       0x0248f926 0x74000 + 37861670
18  myApp                       0x024506b6 0x74000 + 37602998
19  myApp                       0x02450648 0x74000 + 37602888
20  myApp                       0x021fb188 0x74000 + 35156360
21  myApp                       0x021fbd08 0x74000 + 35159304
22  myApp                       0x021fba9c 0x74000 + 35158684
23  myApp                       0x021fb614 0x74000 + 35157524
24  myApp                       0x021bd364 0x74000 + 34902884
25  myApp                       0x00237d18 0x74000 + 1850648
26  myApp                       0x00237dec 0x74000 + 1850860
27  myApp                       0x0247aab8 0x74000 + 37776056
28  myApp                       0x0248f926 0x74000 + 37861670
29  myApp                       0x0219b9fc 0x74000 + 34765308
30  myApp                       0x0219c198 0x74000 + 34767256
31  myApp                       0x021f8bf8 0x74000 + 35146744
32  myApp                       0x0208b79c 0x74000 + 33650588
33  myApp                       0x0208c2f4 0x74000 + 33653492
34  myApp                       0x01fc0a9c 0x74000 + 32819868
35  QuartzCore                      0x2999b7f2 0x29941000 + 370674
36  QuartzCore                      0x2999b63e 0x29941000 + 370238
37  IOMobileFramebuffer             0x2f87957a 0x2f874000 + 21882
38  IOKit                           0x270524d8 0x2704e000 + 17624
39  CoreFoundation                  0x25f48058 0x25ea2000 + 680024
40  CoreFoundation                  0x25f5a3b2 0x25ea2000 + 754610
41  CoreFoundation                  0x25f59ac6 0x25ea2000 + 752326
42  CoreFoundation                  0x25f57ed8 0x25ea2000 + 745176
43  CoreFoundation                  0x25eab118 0x25ea2000 + 37144
44  CoreFoundation                  0x25eaaf04 0x25ea2000 + 36612
45  GraphicsServices                0x2f035ac8 0x2f02c000 + 39624
46  UIKit                           0x2a0edf14 0x2a072000 + 507668
47  myApp                       0x020b6e40 0x74000 + 33828416
48  libdyld.dylib                   0x3819d872 0x3819b000 + 10354
asked on Stack Overflow Dec 4, 2015 by VrettaDev

1 Answer


Anything can crash your Ios app while not crashing the Android version, for example: file names. You could load a sound called "test.mp3" and really called in file system "Test.mp3" and it will work in debugging, work in Android, even play a few times in Ios and then crash the app. All filenames in Ios should be lowercases and not contain fancy characters. In general debugging Ios app in AIR is really coming down to tracing only, there's no real easy way to translate a DYSM to anything meaningful in AS3 so trace, trace, trace. I work in each project with an extended Sprite class that can remove all its registered listeners in one call. Very handy but the first version was crashing in Ios pretty randomly. I put traces all over and finally figured that my last trace was just before a 'removeListeners()' call. So I commented out the method code and no more crashes. Then I reworked the system to make it more solid and everything finally worked fine without any crashes in Ios.

So to summarize:

  • In Ios if loading anything externally pay close attention to file names, they should be lowercases and not contain fancy characters or else ... watch for crashes!

  • To debug and really know what's going on there's only trace, put trace everywhere and watch for the last one, the faulty code will be right after. I do have a system that outputs all trace real time to a server so I catch them even in testflight installs. Put something similar together.

answered on Stack Overflow Dec 5, 2015 by BotMaster

User contributions licensed under CC BY-SA 3.0