Obscure AS3 for-switch-if-false bug (VerifyError)
December 9th, 2008
So we finally tracked down just how Jay broke Grooveshark Lite the other day.
He apparently managed to trigger a very obscure language bug, that no one has really posted about, though if you dig deep enough into Adobe’s bug tracking system, you can find some reports of, though it’s supposedly fixed as of some version of the compiler that I have no idea if it’s in production yet.
This is all it takes to break Actionscript with a nasty runtime error:
private function breakIt():void
{
var arr:Array = [];
for each (var obj:Object in arr) {
switch ('s') {
case 's':
if (null) {
}
//break;
}
}
}
The key here is the nested for/switch/if and that the expression for the if statement evaluates to false, and that there is nothing in the case after the if.
Uncommenting the commented break statement will prevent the bug. Even a variable declaration on that line will prevent the bug. Removing the switch from inside the for loop will prevent the bug. Notice in this case the loop shouldn’t even be executing: the array is empty. Doesn’t matter, it crashes anyway.
The runtime error this triggers is “VerifyError: Error #1068: CLASSNAME and CLASSNAME cannot be reconciled.” where CLASSNAME is the name of the class that contains the above code.
So if you’re getting the above error in your code, check around for any constructs like the above.
December 10th, 2008 at 10:17 pm
[...] discover the source of the problem. Turns out what I hit is a compiler/language/optimization bug. Katy has more about it here, including the generic code we were able to distill it down to in order to cause the [...]
February 4th, 2009 at 12:42 pm
Thx a lot !
I was struggling for days before finding your solution.
The last case in my switch had no break; instruction. It appeared that it looped over and over before throwing a #1068 Error…
Cheers!
February 20th, 2009 at 2:07 am
Really its working..but i was shocked because in debugging mode.it not going upto that line to produce error.i just change if-else part and re-open the application. it has works
May 4th, 2009 at 1:48 pm
Apparently you get this error for the following as well:
switch (‘s’) {
case ‘s’:
if (null)
{
break;
}
}
July 1st, 2009 at 7:41 pm
Thanks a ton for posting this. This bug was killing me!
I thought switch statements could “cascade” down to other cases if you didn’t have a break in them, but apparently not how I was doing it..
October 20th, 2009 at 5:58 pm
You saved me 15 minutes or more by switching my breaks.
December 10th, 2009 at 11:58 pm
Would just like to join the chorus of people praising you for this post. Nicely done.
January 25th, 2010 at 3:40 pm
Thanks! You saved my already pounding headache from getting worse!
February 22nd, 2010 at 12:51 pm
And thanks from another!
March 2nd, 2010 at 10:31 am
Thanks indeed. You are a lifesaver.
March 10th, 2010 at 4:26 pm
Huzza! I just got hit by this one too. Thanks!
April 12th, 2010 at 7:51 pm
Thank you!!!! First time i’ve come across the VerifyError and it had me very confused! Turned out I was missing that break statement after the nested for-switch-if. Crazy.
September 9th, 2010 at 5:04 am
They never got around to fixing it. Surprisingly this bug has only about 400 hits on Google. Obscure, annoying and easy to fix… Thanks!
September 9th, 2010 at 7:16 pm
Thanks from me as well, very hard to diagnose when the debugger refuses to even go into a function that has this specific switch/if condition.
September 21st, 2010 at 1:30 pm
Wow. That was exactly it. Thanks a ton man, you totally saved me a lot of trouble!
October 11th, 2010 at 10:47 am
it seems that putting an
else ;
behind the code as in
switch (’s’) {
case ’s’:
if (null)
{
break;
}
else ;
}
also fixes this bug.
October 15th, 2010 at 8:17 pm
Thanks! Looks like the problem is fixed in Flash player 10.1 btw.
October 18th, 2010 at 7:59 pm
Thanks!
December 17th, 2010 at 9:04 pm
I believe that is indeed invalid syntax. Break statements are scoped to the iterator scope they exist within. The break is bound to the switch. Case statements execute everything after them until they reach a beak or default statement. While looping through the Object’s properties, it has to call the switch and test against every prop against case. As there is no statement following case, which requires a statement, there is no end to the line to move onto the next execution instruction. You just hang and error out. I bet null; in the if statement won’t throw the error.
January 16th, 2011 at 2:02 pm
I’m pretty sure you just saved my day!
Thanks!!!
March 23rd, 2011 at 12:30 pm
Thank you very much for this posting. I’d left out a break statement accidentally within a complicated set of loops/switches. The runtime error was ugly (class couldn’t reconcile with class). This was EXACTLY the problem. It would have been a long hard day if I had not seen this posting!
March 28th, 2011 at 7:29 pm
tq tq tq tq tq…
because it has solve my problem..
May 11th, 2011 at 11:20 am
I cant tell you how grateful I am that you posted this solution. I have been tearing my hair out over the past few days trying to find out why some users were getting unexplained errors, and other were not. Turn out it was directly as a result of this.
What a piece of shit Flex is. Thankfully I am moving on from it.
August 30th, 2011 at 5:26 am
Thanks a ton! You saved my day
November 14th, 2011 at 4:31 am
Thanks a lot.It worked for me
April 10th, 2012 at 1:06 pm
Each single day you wont be discovered by your clients means a loss of money.Better Ranking In The SERP´s with our Search Engine Marketing Team Suchmaschinenoptimierung