Type Coercion failures with MovieClips in ASC 2.0

Report · May 21, 2013

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()

Report · Apr 10, 2015

@Dave: I (or, rather, my team) have been finding that publishing asset SWC files twice (or thrice) with Flash CC generally alleviates the issue. Could be a red herring though.

@Roshan: Any news to share? I'm not sure what the "ToTrack" status on the bug means.

Thanks,

Russell

Report · Apr 27, 2015

Thanks for the suggestion Russell.

Roshan I really wish Adobe would be more responsive when it comes to dealing with bugs, especially ones like this that have been around for years, and have had fixes promised before.

Nothing makes the platform feel like it's dying than Adobe's silence. If it's bad news, you're not going to fix it, just give us the bad news! If the Air team lacks resources, charge us something to use the SDK, or tie it to Adobe CC (we have several licenses of for this project) or something. Air is a great cross platform dev environment but it is being neglected. 20% faster iOS compilation is great .. but there serious are bugs to fix and Adobe's silence is infuriating.

For example - I found a way to completely lock up the Flash Player when using RTMPT, submitted a bug report containing a minimal project to reproduce the issue .. and nothing. No response, no one has looked at it. Bug#3953352 - NetConnection close() blocks forever when using RTMPT (Test project attached)

Today we discovered that RTMPS proxyType = "best" is broken in Android 5. I'll file a bug report, but wish I could have any faith at all that it will be looked at, let alone fixed. Instead of assuming you'll fix it - I starting thinking about crazy workarounds such as a native extension socket server that forwards RTMP over an SSL connection. Too many of these sorts of hacks and we may as well be writing native apps.

We love Adobe Air, we are doing some awesome stuff with it .. I just wish we could get some real support for it.

/Complain

Report · Apr 27, 2015

Hello,

I understand the frustration with this bug (and others). Our team works around the clock to fix security and functional bugs, along with adding features that our community is asking for. We update the runtimes monthly, with almost weekly public betas. I'm sure you guys are familiar with this, and we definitely appreciate your feedback and support.

We are actively investigating this issue and we're making progress, but the problem is intermittent and the fix hasn't been found yet. That said, we're not giving up and we'll keep working on it! Once we have new information, we'll update the bug report.

I've also asked the team to take a look at the NetConnection.close issue. Once you have the bug number for proxyType on Android, please let me know.

Thanks,

Chris

Report · Apr 28, 2015

Thanks Chris.

I have been appreciating the recent frequency of SDK updates, just frustrated the lack of communication / community engagement. If we could pay for premium support or even better for few hours sitting down with members of the dev team we'd jump at the chance. We've done some interesting things like writing an as3 RTMP server that runs in the client to allow the creation of FLV video recordings when offline - having a better understanding of runtime internals (and roadmap) would no doubt help us with our plans.

Anyway, here's my bug report for Android 5 RTMPS Bug#3977064 - RTMPS proxyType "best" not working in Android 5

I wanted to create a Flash Builder test project for it (although simple to reproduce) but installing it keeps getting stuck at 42% for some reason. We don't use Flash Builder anymore as it seems to no longer be updated and questions about it tend not to be answered.

Whilst I have your attention, I just filed a bug for running fdb on OS X, I still use it for debugging on mobile devices and have to modify it each time I update the SDK.

Bug#3977804 - Command line debugger fdb fails to launch on OSX

Cheers,

Dave

Report · May 02, 2015

Thanks for the update Chris. Any chance you can give this a higher priority? This bug already delayed the release of our latest game to iOS for 2 months now, which itself is unfortunate enough. But starting from June 1, all of our existing apps will need to be published with 64 Bits support as well. And as I just now realized in terror, June is less than a month from now. This might be an actual business breaker for us as we have not found any workaround yet and reworking all of our assets might easily occupy us for the better part of Summer...

Report · Jul 05, 2015

Seriously, seriously, is there any chance to see this bug resolved?

It's been more than two months and a major version release since the last update. I've been hounding this topic daily hoping to see something we could do, only to see said hopes crushed.

it's midnight here, and I've just been forced to rip out a lot of nice links from my asset library, wasting precious time I 'd rather use to sleep off my frustration.

Please, pretty please (with Steve Jobs dead balls ontop) keep us posted about this bug.

Report · Jul 12, 2015

Hi again chris.campbell,

A few months on, we are in the same situation. Someone at Adobe managed to replicate the issue where the runtime locks up on NetConnection.close() - but haven't updated the bug to indicate so, and not further activity has taken place. The other bugs I listed remain in an 'Unverified' state. This is a recurring pattern - people complain about a year or two of silence regarding a serious bug, someone such as yourself steps in to reassure us that FP/Air isn't dead, but then very little happens afterwards.

Honestly, I don't understand why you would prioritise working on any new feature when you have this ASC2 compiler race condition. This bug is hurting businesses and your reputation.

RTMPT being verified by Adobe as fundamentally unusable is also extremely disappointing considering how much you charge us for Adobe Media Server, which itself hardly seems like an active project.

In Air you have a great platform on your hands - but you need to make real, structural, changes in your operation in order to better engage with the community in addressing bugs. Charge us something to license the compiler if you need more resources!

Dave

Report · Apr 27, 2015

Dave et al:

First, the suggestion in my previous comments -- to try republishing the asset SWC -- is probably a red herring, or is an unrelated issue we're experiencing with Flash Pro CC.

Second, per jeffward's comments on the filed bug (Bug#3562040 - ASC 2.0 compiled app report Type Coercion crashes with MovieClips in SWC)... we converted all of our import statements for Sprite and MovieClip assets to wildcard import statements (import foo.*). We seem to have a much more stable build now using ASC 2.0: so far we haven't caught any # 1034 errors, and the sizes of our SWF artifacts are more consistent. However, we have still experienced intermittent issues with MovieClip-based assets, where their timeline code is getting ignored at runtime. It's been inconsistent between builds. We have resorted to going down the path of changing more of our import statements to wildcard ones to see if that again works around the issues.

I am glad to hear this is being investigated. I'd probably feel even better seeing the bug bumped up in priority. We're spending a lot of time building and testing our app trying to get a repro, going fishing in SWCs/Linkage Reports/ABC in attempts to find a clue to suggest there is some predictive marker -- so that we might be able to at least catch the issue with some form of static analysis -- and taking stabs at workarounds. There is still uncertainty at this point when we'll become confident in our ASC 2.0 builds.

Thanks!

Russell

Report · Jul 12, 2015

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.

Report · Jul 12, 2015

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.

Report · Jul 12, 2015

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.

Report · Jul 12, 2015

Ah, we have a different situation.

When we try to instantiate an asset from the swc that has TextInput components on it, we sometimes get a

Exception fault: TypeError: Error #1034: Type Coercion failed: cannot convert flash.display::MovieClip@c709551 to our.domain.TextInput.

Complicating matters is that our.domain.TextInput is a subclass of fl.controls.TextInput with some custom code in it. The TextInput component in the library has a 'Linkage' of our.domain.TextInput.

Report · Jul 13, 2015

Well, it looks like we have a 'workaround'.

After spending the weekend trying anything and everything anyone has suggested, today we removed every use of an AS3 component at design time and added code to instantiate them at runtime manually. Not ideal but at least we can rely on the created builds now.

Report · Jul 15, 2015

Spoke too soon, we are now seeing errors with non-component assets with custom classes.

Adobe .. please take this problem seriously. Your compiler doesn't produce consistent output for the same input!

Report · Jul 15, 2015

Just wanted to pop in and let everyone know that we definitely take this seriously and it's very high on my priority list. I'll touch base with the team on this tomorrow.

Report · Jul 15, 2015

This thread has been started 2 years ago. Your words look like you're trying to give us hope again. If it was a high priority for you guys, you would have fixed it long ago.

It's still good to hear, but hard to believe.

Report · Jul 16, 2015

There's usually a burst of real activity at the time someone pops in to reassure, so we can have valid hope that this is the time that they'll get this one across the line. Chris - thank you for resuming communication with us.

All - I have another theory on what triggers this and a possible workaround. We only see the issue on swc assets that both have a linkage class set, and are also used within another asset in the swc.

We are now going through the library and identifying assets that match this pattern, and doing the following:

1. Remove the linkage class (e.g. design.AssetLoadWheel)

2. If the 'linkage' class is referenced in any source code:

a. Create a new MovieClip with that linkage class (LoadWheelExport)

b. Add an instance of the graphic asset to the new MovieClip at position 0, 0, increasing the "Use Count" of the original asset

c. If your linkage class contains code and isn't just a generated MovieClip instance, then you need to:

i. Give the instance you placed on your new MovieClip at 0, 0 an instance name

ii. Update your linkage class code to refer to the instance via its name rather than to itself.

As we work through the library the bad builds occur less and less often, so i'm sharing this approach now in case it helps someone. If anyone else tries this and it doesn't fix the issue please let us know!

Report · Jul 17, 2015

Although the above technique works in general, it ultimately won't work for us as we are using the Actionscribpt 3 UI components and the "components shim" has both a linkage class and use count > 0 .

However - I have developed a bash test for whether a build is good or not which can be integrated into a build script. It relies on the output of swfdump tool from matthiaskramm/swftools · GitHub .

#!/bin/bash
set -o nounset

if [ "$#" -ne 2 ]; then
     echo -e "Usage:\n\t$0  \n"
     exit 2;
fi

SWF_FILE=$1
ASSET_CLASS=$2
DUMP_FILE=$(mktemp)

swfdump -u $SWF_FILE > $DUMP_FILE
grep "places id $(grep "exports [0-9]\\+ as \"design.AssetLoadWheel\"" $DUMP_FILE | awk '{ print $2 }')" $DUMP_FILE > /dev/null

if [ "$?" -eq 0 ]
then
     echo Good build
     exit 0
else
     echo Bad build
     exit 1
fi

Report · Jul 17, 2015

ATTN: Adobe, chris.campbell‌

The swfdump reveals the difference between a working and non working SWF. The broken SWF is embedding two copies of the asset, one copy is exported as the linkage class and the other copy is placed on other assets, and doesn't have an export entry.

Bad SWF:

$ grep 0192 bad_swf_dump 
[027]         4 DEFINESPRITE defines id 0192
                exports 0192 as "design.AssetLoadWheel"

$ grep 0074 bad_swf_dump
[027]         4 DEFINESPRITE defines id 0074
[01a]        18          PLACEOBJECT2 places id 0074 at depth 0001 name "d_spinny"

Good SWF:

$ grep 0079 good_swf_dump
[027]         4 DEFINESPRITE defines id 0079
[01a]        18          PLACEOBJECT2 places id 0079 at depth 0001 name "d_spinny"
                exports 0079 as "design.AssetLoadWheel"

The exact same code, swc and compiler produced these two swf files. I really hope this points someone in the right direction for fixing this.

Report · Jul 17, 2015

It wont let me edit my previous post. There's a bug in the previous version of the script that always checks for design.AssetLoadWheel, additionally the forum stripped the usage string. Fixed version at http://pastebin.com/hBVyQfyC

Report · Jul 22, 2015

Thanks for the script, this is a very good way to insure your build will run as it should.

For my part, I reverted to old positions constants and runtime addchilds. At least I can keep some type safety.

Report · Aug 03, 2015

Hi Chris did your team give you that update? This bug is still causing us major headaches. Checking a single asset via the script above is not enough, my latest testing shows that a random selection of assets fail to link correctly each build. Working on more scripts to attempt to get a stable build system but really hoping for a real fix to this problem so I can get back to productive work

Report · Aug 06, 2015

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. Once we have something, I'll make sure to get out private builds (or have it pushed to the beta channel) ASAP.

Report · Aug 06, 2015

Thanks Chris, I really can't overstate how helpful updates like these can be for confidence at a time when the platform is under attack in the media and by certain prominent individuals.

Report · Aug 06, 2015

I totally understand. We do our best to keep threads updated, but if you ever feel like I'm ignoring or not seeing a thread/issue, please do not hesitate to reach out to me directly. My email address is ccampbel@adobe.com.

Adobe Community

Type Coercion failures with MovieClips in ASC 2.0