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:
Main (Specific for Each Activity) <- ItemActivityVideo <- ItemActivity
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  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  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