Compilation failed while executing : compile-abc when publishing a Release iOS build with AIR 33.1.1.889 (workaround is known)

[GeneralVimes]

Problem Description

When I produced an app-store ipa from a Debug SWF using AIR 33.1.1.889 everything went well. But when I tried to build an app-store ipa from a Release SWF, I encountered a following error:

0x00007FF7C43FCFC4 (0x000000EFE34FE580 0x0000000000000000 0x000000EFE34FE580 0x00007FF7C43FD15E) 0x00007FF7C43FD8BA (0x000003A82A54BE40 0x000003A82A7BE120 0x000003A82A54BD80 0x000003A82A7BE240) 0x00007FF7C44C84ED (0x000000EFE34FE700 0x000000EFE34FE700 0x000003A82A74A830 0x000000EFE34FE540) 0x00007FF7C44C8663 (0x000003A82A7BE120 0x000003A829E5DF00 0x0000000000000001 0x000000EFE34FE870) 0x00007FF7C44C8180 (0x000003A82A7BE120 0x000000EFE34FE870 0x000000EFE34FE790 0x0000000000000000) 0x00007FF7C4493027 (0x000003A82A7BE050 0x000000EF00000000 0x000000EF00000000 0x000000EF00000000) 0x00007FF7C448CC28 (0x000003A82A7BE050 0x000003A82A5481D8 0x000003A82A548060 0x000003A82A5481D8) 0x00007FF7C43ED488 (0x000002D92327A4E0 0x000003A82A3921ED 0x000003A82A3921EC 0x0000000000000001) 0x00007FF7C43E6D95 (0x000000EFE34FF000 0x000003A82A3921EC 0x0000000000000047 0x000000EF00000000) 0x00007FF7C43D4639 (0x00007FF7C53678A0 0x000002D92327A4E0 0x000000EFE34FF020 0x000003A829E5DF00) 0x00007FF7C437DB53 (0x0000000000000000 0x000000EF00000003 0x000002D9230F6D40 0x0000000000000010) 0x00007FF7C437B349 (0x000003A829DD1000 0x0000000000000014 0x000003A800000001 0x000003A829DE3200) 0x00007FF7C438132F (0x000002D923096960 0x0000000000000000 0x0000000000000009 0x0000000000000000) 0x00007FF7C43825E0 (0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000) 0x00007FF7C52BBEE8 (0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000) 0x00007FF962627034 (0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000), BaseThreadInitThunk() + 0x14 bytes(s) 0x00007FF963E42651 (0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000), RtlUserThreadStart() + 0x21 bytes(s)

Compilation failed while executing : compile-abc

At the same time when I used 33.1.1.821 building an app-store ipa worked well both from an Release and from Debug SWFs.

Steps to Reproduce

Here is a minimal build with just a Main.as class to reproduce this error:

package
{
	import flash.display.Sprite;
	public class Main extends Sprite 
	{

		public function Main(){
			
		}
		public function testCase(a:int):void{
			switch (a){
				case 0:{
					trace('0');
					break;
				}
			}			
		}		
	}
}

Looks like this issue is connected with an "empty case" Apple's bug.

Back in 2018 it was known that if an AIR project has an empty case clause like this:

case 0:{
	break;
}

then it would cause compile-abc error when building an .ipa. If the developer wanted to keep an empty case clause it was possible to add a trace() call into it (just like in example). But since AIR 33.1.1.889 it looks like the trace() calls are cut out of the SWF if the Release version is produced and such case clauses become empty again.

Known Workarounds

Not sure if this is a bug which needs fixing, as removing trace() calls from a Release SWF looks like a right thing. However if any of the developers who encounters compile-abc error when building an app-store ipa, you'll know where to look.

If you still want to keep an empty case clause you can add a trivial call into it like:

switch (a){
	case 0:{
		a=0;
		break;		
	}
}

Or just comment them put entirely from your code.

[itlancer]

Seems it related to https://github.com/airsdk/Adobe-Runtime-Support/issues/1912#issuecomment-1138153263 "Release" swf now uses omit-trace-statements=true by default. You can set up omit-trace-statements=false to amxmlc compile arguments (if you use it) to avoid this issue.

[GeneralVimes]

Oh, cool, thank you!

[ajwfrost]

I'd heard about this failure of AOT to cope with case xx: break; - so it's good to see there are workarounds but it would also be something we can look into, we had been already doing some updates in the AOT compiler recently..

[ajwfrost]

@GeneralVimes can I just check on this, the issue doesn't seem to much to be about an empty case statement, it's about there only being one case statement. Unless I'm doing something wrong:

public function testCase(a:int):void{
    switch (a){
      case 0:{
        break;
      }
      default:{
        break;
      }
    }
}

So that works for me, as there are two choices. Then:

public function testCase(a:int):void{
    switch (a){
      case 0:{
        a = 5;
        break;
      }
    }
}

also works, because there are still two choices ('case 0' or the missing 'default').

But then if I make it so there's only one choice:

public function testCase(a:int):void{
    switch (a){
      default: // fall-through
      case 0:{
        a = 5;
        break;
      }
    }
}

then it fails again, regardless of the fact that I've got some code in the case statement. But here, there's only one option for the switch statement (which makes it a bit nonsensical to use... essentially like if (true) ...)

Can I check you're seeing the same thing: it's not that there's a blank case that's the issue, it's if there's only actually one option to choose?

thanks

[ajwfrost]

Just as somewhere to record some details .. we've checked what gets generated here and it seems to check out and also to explain why the problem happens. If you have the simple case with nothing in it, then the generated bytecode has a default offset, a '0' as the number of cases, and a 'case' offset which is the same as the default offset. So it will always jump to the same place. If you explicitly add a default case which is separate from the empty case, then the 'case' offset changes so that it points to some code .. which is essentially just the 'break' statement i.e. go to the end. This is a bit wasteful you might think, and yes at compile-time in the JIT, this is optimised. It's also optimised in the AOT compiler but that's where it goes wrong: the cases are condensed down since they point to the same instruction, and then we end up with a switch statement that has no cases other than the default, and this then causes a problem... but we can work around it by checking after the optimisation: if there are no cases, then we just do "goto default" rather than adding the switch table.

So fwiw I think we have a fix within the compile-abc tool...

[GeneralVimes]

Can I check you're seeing the same thing: it's not that there's a blank case that's the issue, it's if there's only actually one option to choose?

Exactly! Indeed, it's rather of a "only empty case", not "blank case issue"