Type Coercion failures with MovieClips in ASC 2.0

Legend

For us this was solved by switching from .swc assets to .swf assets on iOS. Maybe it helps.

P

PippoApps

Inspiring

thanks,

me too I use external SWF (even though swcs offer more advantages).

The issue I face is as follows (only on iOS):

- Same application domain

- Some classes are defined in both main swf and loaded swf

- In abstract code everything works fine

- When a class is linked to a DisplayObject in library, and that DisplayObject is instantiated visually inside the display list of a DisplayObjectContainer, I get an error.

ie.:

Inside MovieClip A, created visually in Animate, there is an instance of MovieClip B.

If in A Class, I reference b typing a variable:

var _myB:B = this["instanceOfB"];

I get the error: Cannot convert B@23232 to B.

The error also shows when typing vectors.

A bit tricky to describe, but this shouldn't happen as all lives in the same application context.

The only workaround is to use core classes, ie.:

var _myB:MovieClip = this["instanceOfB"];

Not too bad, but you lose IDE code completion and some OOP advantages.

C

Calibrae_

Participating Frequently

ArslanovArtem I use wrappers. I parse the library items by names, making them inherits movieclip directly, and I instantiate different wrapper depending on what I want to do.

Yeah. It's a pain.

S

Streiffus

Participating Frequently

For those still suffering from this issue - our build engineer fixed the issue by switching to using 64 bit Java to compile AIR.

Previously, we were using 32 bit Java and were seeing more than half of our builds fail. Since the switch, we have not encountered a single 1034 error.

Gio_Nadirashvili

Participating Frequently

Streiffus wrote:

For those still suffering from this issue - our build engineer fixed the issue by switching to using 64 bit Java to compile AIR.

Previously, we were using 32 bit Java and were seeing more than half of our builds fail. Since the switch, we have not encountered a single 1034 error.

Streiffus Can you be more specific on how to switch to 64 bit java for compilation?

I've also found Adobe Flex 4.6 SDK Configuration page (scroll down to JVM configuration) on which it says:

These compilers are 32-bit executables and cannot launch 64-bit processes. As a result, they require a 32-bit version of Java to run.

S

Streiffus

Participating Frequently

I'd have to ask our build engineer, since he was the one who set it up. I'll see if I can get him to post when he's not too busy.

SlavomirDurej

Participant

How is this still not being fixed?! We have air sdk 20, now and I'm still getting this fairly regularly.. Beyond frustrating && beyond disappointing..

Inspiring

The process outlined in post #44 should help a lot. It can be a lot of work, but when Adobe stop working on this bug down for months and years at a time it's probably your only option (if java 1.8 / 64 bit doesn't help your case)

Given that the same input to the compiler can produce different output each time, the bug is by definition a race condition. Changing java version likely altered the race on your particular codebase and on your particular build server, in such a way that the problem seems to have disappeared. It's extremely unlikely that the bug is actually gone if anyone is still seeing it on any java version.

http://pastebin.com/Xjr6hyz8

Inspiring

Thanks Chris.

All - I believe I now have a bash script for OS X that can detect a bad build. It requires:

An fla or folder containing xfl, that was used to build your asset swc
A swf that you have linked against that swc
ssh access to a linux host with swfdump installed. I couldn't get swfdump building on OS X. I used an Ubuntu vm running locally on virtualbox, as Ubuntu supplies a swfdump package.

The script iterates through all assets in the fla with custom linkage classes that have been placed as named instances on other assets that have been linked into your swf. For each asset it determines how many named placements should be in the swf, and checks that that many named placements exist in the swf.

If you find that swfdump doesn't think your swf is valid, try disabling compression in your build (pass --compress=false to mxmlc , or add to compiler options in your IDE).

Hopefully someone else finds this useful. If you try it and it isn't accurate for your situation please let me know.

Usage:

check_type_coercion_bug.sh <fla file OR folder containing xfl> <swf file> <linux ssh host with swfdump>

For example:

check_type_coercion_bug.sh AppAssets.fla MyApp.swf username@linux-host-with-swfdump.example.com

Inspiring

I have discovered another bug in the Air compiler, likely related or the same as Type Coercion bug.

In our case we are exporting ActionScript components in our swc. Occasionally, the final swf will be missing the TextInput (and probably other) skins. Inspecting a swfdump of the swf shows that whilst the TextInput class is listed as exported, the related skin classes are not. Usually the next build will be fine, and a swf dump of a working build will show the skin class.

I have updated my build checking script to also check for this case. I have also dramatically increased the performance of the script, it now runs in a couple of seconds for our project. It requires access to a linux server with bash version 4, swfdump and unzip. I used an ubuntu 14.04 vm running under virtualbox on my OS X laptop.

To install the dependencies on an ubuntu server:

sudo apt-get install swftools unzip

Place the script [Bash] Check SWF for ASC 2.0 Type Coercion Bug - Pastebin.com somewhere on your OS X build machine, I call it check_type_coercion_bug.sh . Then invoke as follows:

SERVER="<USER@HOST>"; SCRIPT="<PATH_TO_SCRIPT>"; FLA="<PATH_TO_FLA_OR_XFL_FOLDER>"; SWF="<PATH_TO_SWF>"; scp -q -r "$FLA" "$SWF" "$SCRIPT" dev_a: && ssh $SERVER chmod +x \"$(basename "$SCRIPT")\" \&\& \"./$(basename "$SCRIPT")\" \"$(basename "$FLA")\" \"$(basename "$SWF")\"

Replacing <USER@HOST>, <PATH_TO_SCRIPT>, <PATH_TO_FLA_OR_XFL_FOLDER> and <PATH_TO_SWF> as appropriate.

BE AWARE: This invocation will copy your fla, swf, and this script to the home directory of whatever account you use on the server. Files with the same names on the server will be overwritten.

Hope this helps. Certainly useful for verifying an app store build.

mustangy

Participant

Looks like I got workaround!

I've discovered linked MC's that are placed on first frame of root works.

So I've expanded all folders in library, selected all, and moved ALL to FRAME 1 of root

Export. Bang! Everything works just like with flex compiler.

Inspiring

Does it work repeatably? How many builds have you tested?

I tried your method, no change for us. Probably about 1 in 10 builds is failing at the moment.

I've converted to using the wildcard import method, no luck there either. Have also tried referencing & instantiating related classes during our document class static initialisation. All the of the things i've tried are helping a little, as previously I was getting a dud build perhaps 1 in 5 times.

I'm guessing they've made the ASC 2 compiler multithreaded but have failed to determine dependencies properly, resulting in a race condition. Have looked but haven't been able to find a compiler flag for disabling multithreaded compilation.

mustangy

Participant

One big project - 0 problems since this method (compiled like 40 times today).

Compiled with latest AIR SDK. SWC is from Flash CC

Not sure if we talk about the same problem. Mine was that MC's from SWC (as classes) got all children as null.

R

Roshan Chhetri

Adobe Employee

Hi,

I am not able to reproduce the bug you reported as I used the resources you attached.

Please let me know the following.

Air sdk version Used and the resources you used to reproduce this bug.

-Roshan

Legend

Hi Roshan,

I am happy to send you our .swc file with some instructions how to reproduce the error, can you give me your email address?

The error occurs when compiling for iOS. Currently I am compiling my iOS app on debug interpreter build with Air SDK 17.0.0.105 and the swc file I tested both with Air 14 (FlashCC default) and Air 17.0.0.105, the error occurs in both cases. Testing happens on an actual device. The .swc file is fully included and resources are loaded in the app with new (Class(getDefintinitionByClassName("resourceName")))(). Most resources load fine, some dont.

Legend

Also note there is more details about the problem reported here: Re: Random swc runtime problems and here Bug#3562040 - ASC 2.0 compiled app report Type Coercion crashes with MovieClips in SWC

M

molotowitzz

Participating Frequently

Hello, confirming this issue. I am unable to build our project with ASC2. It works with the legacy flex compiler without a problem, but latest stable ASC2 compiler (and various versions back) suffer from this. I have reduced my project only to the one SWC with graphic assets (built in latest Flash Pro CC) and Flex 4.6, which is used ONLY for BlazeDS and some minor stuf. No MXML at all etc. Please, correct this....it is killing us... (I have spent days on this, I think it is could be connected to the badly shared or just badly copied Library Symbols in Flash Pro. Recreating - not duplicating - some symbols helps for some projects, but when you have 500 assets?).

R

Roshan Chhetri

Adobe Employee

Hi, We are looking into this case.

The project, Test Project.zip, uploaded by you worked fine on Flash builder with AIRSDK 16 .

Kindly let us know the exact steps to reproduce this error. Also please note that, we cannot overlay ASC2 compiler SDK on Flex SDK's. It needs non ASC 2 compiler to be used.

Kindly send us a sample project and steps to reproduce this issue.

Roshan

Adobe AIR