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/myApp.app/myApp
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 Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x00000083
Triggered by Thread: 0
Filtered syslog:
None found
Thread 0 name: Dispatch queue: com.apple.main-thread
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
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.
User contributions licensed under CC BY-SA 3.0