Type Coercion failures with MovieClips in ASC 2.0

[michelangelo.capraro]

Hi all, i am seeing this Type Coercion problem with SWCs containing MovieClip assets in 3.7 and 3.8 versions of ASC 2.0

here is the bug i filed: https://bugbase.adobe.com/index.cfm?event=bug&id=3562040

Adobe: would love to see a fix in the next beta update if possible so i dont have to go back to the flex compiler. I posted this accidentally in the Flex group, so sorry about hte cross post, want to be sure adobe sees it, my bug, and can issue a fix.

Basically, when i compile using ASC 2.0 and am calling assets from a SWC generated in Flash CS6, i get an intermittent type coercion error. What seems to trigger this is adding a child of a MovieClip in the SWC to the stage of a Sprite not in the SWC (generated programatically).

Exception fault: TypeError: Error #1034: Type Coercion failed: cannot convert flash.display::MovieClip@d7dd431 to assets.ui.GoButtonAsset.

          at flash.display::Sprite/constructChildren()

          at flash.display::Sprite()

          at flash.display::MovieClip()

[fhfghgfh434]

> chris.campbell 06-Aug-2015 01:50

Yes, it's on our priority list and I just talked with our dev manager about this earlier this week.  The vm engineer assigned has been busy working on security the last few weeks but I'm hoping we can get some of his time in the next few weeks.

Yeah.

Adobe the only thing you are doing currently is angering your customers, this will not end well. Look at MS they still havent recovered from the IE6 backslash. Do not waste your time introducing new features that are used by 0.1% of your customers (just look at the Flash changelogs - I havent used a feature introduced in the last six versions).

BUT I have torn my hair out several times because my iOS app wont compile on Windows, apps with ANEs wont compile all the time, AIR cannot debug, videos crash on Android, I can't submit to Apple, AIR gives me useless "ApplicationVerifiedError" messages that take hours to debug, the [Inline] optimization corrupts code, AIR on Android throws random errors when using textures, AIR on iOS randomly refuses to write on the disk, SharedObjects randomly wont work on iOS, on IOS my app asks randomly whether to use push notifications,....

all AIR bugs. Do you really want this kind of social media attention?

[dqh360]

This is still a bug 6 months (and years) later in Air 20. I hadn't seen it for a while but my script that checks a build for this bug found one today. Rebuild of same code worked fine.

Of the several bugs i've submitted, I don't think any of them have been fixed. There's this one, there's secure socket not working in Android, RTMPS proxyType = "best" not working in Android 5 or 6, complete flash player lockup when playing video over RTMPT.

I sometimes have contact with Adobe support engineers, but they never seem interested in having to work particularly hard. Makes me wonder if they are measured on how many bugs they fix or something equally silly.

I've been following your forum participation and you seem to work hard chris.campbell - what's going on with the rest of the team? I would much prefer to pay for the Air SDK if it meant that you had resource to work on fixing bugs.

[dqh360]

Come to think of it, we do actually pay quite a bit every month in order to use Adobe Media Server.

[chris.campbell]

Our team is still working on the type coercion bug, but we've recently discovered a potential workaround.  Could those interested please try replacing the \AIRSDK\lib\mxmlc-cli.jar file with the one in the zip file linked below.  We'd be very interested in hearing the results.

Shared Files - Acrobat.com

Thanks,

Chris

[nuthman]

Replacing the jar file with the attached didn't help for me. I get the type coercion bug very intermittently.

I just have to keep rebuilding the project until it finally compiles. Eventually it will compile with no errors.

I am using the latest AIR SDK version 21.0.0.215 using SWC assets exported from Flash Professional in an as3 project for air mobile using IntelliJ Idea IDE. Here is the output:

/Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home/jre/bin/java -Dapplication.home=/Volumes/yosemite/Users/nuthman/Documents/AIRSDK_Compiler -Dfile.encoding=UTF-8 -Djava.awt.headless=true -Duser.language=en -Duser.region=en -Xmx512m -classpath /Volumes/yosemite/Users/nuthman/Documents/AIRSDK_Compiler/lib/legacy/fdb.jar flex.tools.debugger.cli.DebugCLI

Adobe fdb (Flash Player Debugger) [build development]

Copyright (c) 2004-2007 Adobe, Inc. All rights reserved.

Waiting for Player to connect

/Volumes/yosemite/Users/nuthman/Documents/AIRSDK_Compiler/bin/adl -profile extendedMobileDevice -screensize NexusOne -XscreenDPI 252 -XversionPlatform AND -extdir /private/var/folders/gy/kfkjrww1011gw8d1lbng501w0000gn/T/IntelliJ_ANE_unzipped /Users/nuthman/Desktop/w/repos/word-slip-as3/out/production/word-slip-as3/Main-app.xml /Users/nuthman/Desktop/w/repos/word-slip-as3/out/production/word-slip-as3

Player connected; session starting.

[trace] total points:  0

[Fault] exception, information=TypeError: Error #1034: Type Coercion failed: cannot convert flash.display::SimpleButton@239e4e256801 to assets.PlayButton.

[nuthman]

Sadly the problem still exists in Air SDK 21.0.0.215

For years I thought that I was doing something wrong. It's kind of amazing that this bug has lasted for so long! I only just discovered that many others are having the same issue.

[bhargaveede]

Hi,

This problem is solved by the addition of a compiler-flag in the SDK.

I assume you are facing this error because of the default value of flag.

To set the flag, Please follow below steps:

Project Properties -> ActionScript Compiler -> Additional Compiler Arguments

Add "--single-thread" flag there and run the build again.

Hopefully, this should resolve the issue.

Please let me know the result.

Thanks,

Bhargav

[nuthman]

Bhargav - Thanks! This seems to be working so far. I will report back if the bug continues (or doesn't) to occur.

Rick

[Gio_Nadirashvili]

@bhargaveede How do you guys add this compiler option?

I get an error from the compiler:

Error: unknown configuration variable 'single-thread'.

What IDE are you using or what version of Adobe AIR/Flex SDK?

[nuthman]

The compiler option definitely fixed the problem for me. It has yet to reoccur for me after many, many compiles.

I am using IntelliJ Idea with the latest AIR SDK (as of this writing). You have to find the compiler options and add --single-thread with the leading 2 dashes.

Gio - what IDE are you using? Maybe I can help you find the setting.

[Gio_Nadirashvili]

I'm also using IntelliJ IDEA. Adobe AIR 21 overlaid by Flex SDK 4.6. I've tried using both a compiler config file and just adding a compiler option in Project Settings > Modules > MyAppModule > Compiler Options Tab > Additional Compiler Options input.

Maybe it's because of the overlaid Flex SDK, I'll try with vanilla AIR SDK 21 and let you guys know.

EDIT: I tried vanilla AIR SDK 21 and it's the same for me. Also tried to change IntelliJ compiler settings from "Built-in compiler shell" to Mxmlc/compc without any success.

Adding screenshots of what I have configured and the error I get:

Note that I also tried to build a project with only inline compiler options (without an xml config file).

[stephenr1027395]

If I'm publishing SWCs from Animate 2015.2 CC, how would I add this "--single-thread" compiler argument so that when it is published it works?

The company I work for uses Animate to export assets into a SWC, which is then referenced in Flash Builder to initialize the assets - which are generally MovieClips that contain images/Bitmaps in them, but sometimes we create a full "skin" as a MovieClip that will have additional MovieClips in it, then we just initialize this one MovieClip to get our full screen set up with its buttons, text, etc. However, we constantly run into this coercion error, where a MovieClip in the "skin" can't be converted to the correct class. We generally get around it by not "exporting for ActionScript" any MovieClip we don't need a typed reference for, but this only helps so much since sometimes we need to export for ActionScript.

This issue currently causes us a ton of overhead in just building projects, because sometimes you won't know if a build is bad until you run through it and make sure each skin is initialized to see if it has a problem - if a skin doesn't show up until the very end of the interactive, you won't know the build isn't good until you get to that part (unless the skin is initialized at startup of the interactive, which some are).

At this point, I've suggested we start moving to different technologies to build our interactives (Unity for example), since this issue has been going on for so long without a reliable workaround or any real progress in getting it fixed.

[nuthman]

Stephen,

If you want, you can send me a sample project of this occurring and I can tell you what is happening, but I think that the following will solve your issues.

I use the exact same workflow that you are talking about and had run into your issues in the past. When exporting the SWC, you don't have to add any kind of compiler arguments in Flash Professional / Adobe Animate CC. Here is what I do:

In the Flash file, every single asset that will be used gets the linkage asset.ClassName:

Make sure that in flash the linkage does NOT point to a 'real' class in your project such as com.company.ClassName

The above has caused me tons of nightmares in the past. Make sure that all of the MCs inside of the skin don't link to actual code in your project. You will attach the images to code in Flash Builder if need be.

Export the swc and import it into your project.

In your project, use the asset like this:

package com.company

{

     import assets.SomeSkin;

     public class Menu extends assets.SomeSkin

     {

          public function Menu()

          {

               // If the skin has a SimpleButton with an instance name of goButton...

               goButton.addEventListener(etc.....)

          }

     }

}

Rick

[stephenr1027395]

Thanks for the reply Rick. Unfortunately I can't really send you a sample project because it only sometimes happens randomly with certain projects, and the project that its occurring in currently that I can't fix is a company project and I can't give out assets.

Make sure that in flash the linkage does NOT point to a 'real' class in your project such as com.company.ClassName

I know this is already not the case - I'm only exporting about 15 Movie Clips (12 buttons and then 3 skins that contain those buttons). In Flash Builder, I initialize those skins using var mySkin:MySkinClass = new MySkinClass(). I can then access those buttons in the skin using mySkin.myButton, just as  you said. I generally wouldn't even need to export the buttons with linkage names, but I need to initialize new versions/duplicates of those buttons during runtime, so they have to have linkage names to be created correctly.

I didn't include our build process since I didn't think it made a difference, but now I'm going to so maybe I can get more information on how to get around this issue.

Here is our development workflow:

1. We create assets in Animate 2015.2 CC (buttons, sounds, textfields, etc, as MovieClips with linkage names - exported for ActionScript)
2. Occasionally we group multiple MovieClips into one MovieClip that we call a "skin" - basically a layout of all the buttons, text, etc for a screen or other part of the interactive that we are developing.
3. We then publish the library as a SWC, which is then imported into Flash Builder, under the ActionScript Build Path - Library settings.
4. We then initialize the MovieClips and place them on the stage.

Here is our build process:

1. The SWCs are generated by Animate using a JSFL file that exports the libraries.
2. We use the amxmlc compiler to generate a SWF. We include the source files and the SWCs that are required.
3. We use the ADT to package the SWF from step 2 and SWCs from step 1 into a "signed application with captive runtime" AIR package.

The weird issue is I generally don't see the problem in our development workflow - Flash Build very rarely has an issue taking a SWC and building the MovieClips from it, although I do sometimes see this issue in Flash Builder. I did some further testing after I had posted, and my initial thinking was that it was a SWC issue, since it seems that generally, if the build fails, redoing the build won't fix the issue, but rebuilding the SWC will eventually fix it (sometimes it takes multiple tries before we get a good build, but then the next build may fail again anyway, without any rhyme or reason).

However, I took a working SWC from my development PC (which worked in Flash Builder, even when doing a release build from Flash Builder), and put it on our build PC in the place where it generates the SWCs, and then building the project, but skipping the step where it builds the SWCs (so that it only does steps 2 and 3 in the build process) - and the build still had errors. So the same SWC that worked on my development computer failed for the build computer.

From reading what people are saying above, it seems when the SWF is generated in step 2, it's the one that causing the issues and it's possible to add the "single-thread" compiler argument to the amxmlc compiler, which I did. Unfortunately it did not fix the issue. I'm going to be doing more testing of it today and see if there's something I'm missing.

Any additional information would be helpful as well.

[nuthman]

Yes, this was exactly the problem that I was having - the build would intermittently fail. After several rebuilds the coercion error would not manifest and the air runtime would finally compile.

My problem was fixed by adding the single thread argument, though.  I'm wondering, is there anything in that compiler-options.xml file that is overriding the argument? I may be reaching, but just trying to cover all bases.

On a side note, for ActionScript development, you should check out Intellij Idea. Sadly Adobe seems to have given up on FB. Idea has some great refactoring tools as well.

[ArslanovArtem]

Hello!

Compiles the project in IntelliJ IDEA. Adding --single-thread does not help.

Library swf compile in Adobe Flash CC 2015.

Is there any progress with this bug?

Tell me what to do?

[PippoApps]

Hi,

I am encountering this issue only on iOS, and not on Android or Desktop.

Any news about how to fix this?

Any news about how to set that compiler flag in Animate CC?

cheers

[rewb0rn]

I found a workaround that works in our projects. I was having this issue on iOS only where the platform was limiting us from remotely loading swf files. I found however that the AOT compilation on iOS seems to work quite fine. So from now on we are exporting our assets on iOS to swf file and it is possible to load them via Loader as long as the swf files are packaged into the ipa. MovieClip linkage names function as well. Maybe it helps some of you.

[dqh360]

Thanks for this, i'll look into it now. Will have to modify a lot of code but if I can begin the week without having to deal with this problem i'll be happy indeed. Good to know that this approach is possible on iOS.

[dqh360]

So much for that plan, some of our code is extending asset classes in the swc.

[dqh360]

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

http://pastebin.com/Xjr6hyz8

[dqh360]

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.

[SlavomirDurej]

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..

[dqh360]

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.

[Streiffus]

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.