Skip to main content
Legend
July 4, 2012
Answered

How do I start to debug when iOS package only crashes outside of non-debug compile mode?

  • July 4, 2012
  • 8 replies
  • 1121 views

Hi,

I have an app that I am migrating from web to mobile and I have recently encountered an issue where it will crash on load, but _ONLY_ when packaged for release and only on iOS.

EG:

1. For Android, works in

- emulator

- USB debug

- release compile modes

2. For iOS, works in:

- emulator

- fast compile USB debug

- standard compile USB debug

DOESN'T work in:

- ad hoc compile

I initially thought it was due to loading SWF with ActionScript, but even after replacing those files with static JPEG, it still crashes.

I have commented out all traces, following another forum report that listed traces as a problem with ad-hoc compile.

I have tried moving resource bundle strings out of the problem view as these strings don't display in the problem view (but do elsewhere).

In all cases, the result is the same:

View loads, then freezes before it gets far enough to set navigatorContent property (declared in MXML) so it just hangs with no labels visible.

Have tried any number of things to debug this, and at twenty+ minutes per compile, there is a limit to how many I _can_ try, so, please, please, does anybody have any idea of where to look for potential problems that might be causing my app to fail?

Thanks,

Gaius

This topic has been closed for replies.
Correct answer Gaius Coffey

OK, now that's weird.

Or, rather, it isn't but it is unexpected.

Clearly, whatever is crashing is caught inside AIR...

There is no crash report, and (now that I have modified my code a bit) I can get back to the main view via a button in navigator content.

What I am seeing is that my Swiz framework, that should be initialising my DisplayObject with all kinds of niceties doesn't seem to have done so - although it should have done prior to the clip being added to stage. Does anyone know if there are any problems with Swiz and view navigator apps? I will also go to the Swiz forums and see if there is anything there.

G


Got it.

I was using the Swiz framework (which is brilliant, btw) and compiling the Swiz library rather than using the SWC as I needed a change to the underlying, I had omitted one of the metadata tags from the compiler args - for some reason, it recovered when run in any other compile mode, but crashed when run in release mode.

G

8 replies

July 5, 2012

Hi Gaius,

Are you encountering this issue with AIR 3.3 latest release also?

Legend
July 5, 2012

Yes, I am (now) on AIR 3.3.

I'm not sure if it helps, but the problem began when I moved from a base mobile application to a view navigator one.

EG: All functions _have_ previously worked. Just not in views, for release compile only.

I think that the issue could have something to do with resourceBundle? Screen elements appear to be initialised, but without strings from the resource bundle implying that there was an error in setting them up that triggered the crash.

G

sinious
Legend
July 5, 2012

If you're on a Mac you can get access to the devices crash logs. I've done this with native projects in the past. Here's a brief but technical tutorial on the process:

http://kevincupp.com/2011/05/12/symbolicating-ios-crash-logs.html

After AIR for iOS is compiled it's anyone's guess if what is actually in the log will be useful as it will have already translated between frameworks. In other words, it won't say "This URLLoader failed" but more like something to the effect of an NSURL request went bad, which can be somewhat useful. At least it narrows it down to a network issue, etc.