[Issue] AVMPlus is crashing

[Hydp]

Behavior

Trying to run a SWF with redshell or redshell_d now works fine again. I've tried a tradional 'Hello, RedShell', and it did it. But, trying to compiling my true project to a SWF and run it with RedShell only fails.

About Flash API: I'm not really using it anywhere. I've replaced playerglobal.swc by redtamarin.swc and I've also included redtamarin.swc in my final SWF.

Here's the error when is entered redshell_d ASC.swf:

avmplus crash: exception 0xC0000005
Writting minidump crash log to avmplusCrash.dmp

SWF version: 11.0 . My project has been already uploaded to GitHub earlier, but it has been modified just a bit more for now.

[Hydp]

If RedTamarin uses AVMPlus, then there's no good reason for this crash, if it's ECMAScript 3 compliant.

Well, I gave up in this AS3 shit. I think the way is to continue creating my next scripting language and abandon both Lua and AS3 at the maximum possible, really. At least it'll be easy to optimise that new scripting language.

But thanks, @zwetan, for your max help. It's strange how Adobe, Macromedia, Mozilla and Opera don't care for max performance and compatibility.

[zwetan]

please describe on which OS you're doing this
which version of redtamarin
wether you use redshell / redshell_d or redshell_dd ?
is it the 32-bit or 64-bit version ?

what command-line parameters have you used

• for compiling your SWF
• for running the SWF with redshell

[Hydp]

OS: Windows 10.x., x64 (64-bits).
RedTamarin v. 0.4.1T174
RedShell: both redshell, redshell_d and redshell_dd.

mxmlc -o ASC.swf -swf-version=11 -library-path+=../lib ../src/Main.as
redshell_dd ASC.swf

I'd love to use RedTamarin since it allows me to use the file system easily and probably also the argv.

[zwetan]

ok that's normal

this is related to that

Issue: Support for 'normal' SWF loading/instantiating

in short, when you build a SWF with MXMLC
the main class is loaded in the first doABC tag
instead of being loaded last (after all the other dependencies)

workaround in v0.4.1

package
{
    public class Main
    {
        public function Main()
        {
             // ...
        }
    }
}

import shell.Program;
Program.atExit( function():void {
   new Main();
} );

in v0.4.2 you'll be able to do that

package
{
    public class Main
    {
        public function Main()
        {
             // ...
        }
    }
}

import shell.Program;
Program.start( "Main" );

see updated doc Compile with the Flex SDK

[Hydp]

Got it, but right now a verify error is persisting here.

VerifyError: Error #1019: Native methods are not allowed in loaded code.

I'm not really defining native functions, but I had to include redtamarin.swc. If don't include it, I get a bunch of MXMLC errors.

[zwetan]

check if you use the keyword "native" in your source code

[Hydp]

Did a full search:

Searching 24 files for "native" (case sensitive)

0 matches

So, well, I'm not using that attribute. But..., w/o redtamarin.swc, I only get reference errors for shell.Program at strict verifications (MXMLC).

[Hydp]

That's a bug, right? I guess so because redtamarin.swc obviously needs all its methods native.

I hope there can be a fix, because it's not that easy to do a, well, transpiler specifically for self-running as a Flash application. GUI is something I want to avoid for now.

[zwetan]

do you have an error stacktrace?

[Hydp]

It just prints the VerifyError and nothing more... Is there a flag for tracing the entire stack? (Wow, there're a lot of flags.)

[zwetan]

replace library-path by external-library-path to load redtamarin.swc

you can also use -dump-config <filename> to output your full compilation config

in short, you can compile against a library without embedding it external-library-path
or compile with a library by embedding it library-path

if you compile in such a way that redtamarin.swc is embedded
then the MXMLC compiler will complain

VerifyError: Error #1019: Native methods are not allowed in loaded code.

eg. you can not load code that use native definition

[Hydp]

I've tried external, but same crash error 0xC0000005 occurred.

Also, I think MXMLC has nothing to do with native method errors. I think you have mispelled it with AVM2, nah?

[Hydp]

In short, the VerifyError happens within redshell_dd, as opposite to mxmlc. I guess RedShell must ignore the ABC from redtamarin.swc.

About -external-library-path+=n

I've tried this option instead of simply -library-path before your reply, but it got worst to RedShell: the above issue crash occurred. So, not embedding the redtamarin.swc causes a crash. That's exactly my recent comment.

The best I can say is that this native method error is a bug.

[zwetan]

provide a

-dump-config <filename>

like that it's hard to see what's going wrong in your compilation

The best I can say is that this native method error is a bug.

yeah and MXMLC is telling you there is a problem

but now I would say you're not compiling with MXMLC correctly
that's why you get this error

redshell in itself has no bug on this side

so first thing to do is understand how to compile with MXMLC
hence why I ask the dump of your config

[Hydp]

but now I would say you're not compilling with MXMLC correctly

No, I'm executing $swf before redshell_dd. $swf.cmd/Batchfile contains my MXMLC command.

Well, here is the full configuration dump:

(I've already tried -external-library-path, too.)

https://pastebin.com/raw/a6DAP59w

[zwetan]

OK the important part is here

          <!-- compiler.external-library-path: list of SWC files or directories to compile against but to omit from linking-->
          <external-library-path>
             <path-element>libs/player/{targetPlayerMajorVersion}.{targetPlayerMinorVersion}/playerglobal.swc</path-element>
          </external-library-path>

where you install the Flex SDK

the path ${flex_sdk}/libs/player/{targetPlayerMajorVersion}.{targetPlayerMinorVersion}/playerglobal.swc

is used with external-library-path

when you mentioned

I've replaced playerglobal.swc by redtamarin.swc and I've also included redtamarin.swc in my final SWF.

and you use
-swf-version=11

are you sure in this path
${flex_sdk}/libs/player/10.2/playerglobal.swc
that the SWC is the redtamarin.swc renamed to playerglobal.swc ?

yes that can be confusing the SWF version is not equals to the player version
SWF30 is for Flash Player / AIR 19.0 for example

also another thing to look into is there

       <!-- swf-version: specifies the version of the compiled SWF file.-->
       <swf-version>11</swf-version>
       <!-- target-player: specifies the version of the player the application is targeting. Features requiring a later version will not be compiled into the application. The minimum value supported is "9.0.0".-->
       <target-player>29.0</target-player>

while using -swf-version=11 should be enough, try also to add -target-player=10.2

ideally try those combos
-swf-version=11 -target-player=10.2
-swf-version=12 -target-player=10.3
-swf-version=13 -target-player=11.0
-swf-version=14 -target-player=11.1
-swf-version=15 -target-player=11.2
-swf-version=16 -target-player=11.3
-swf-version=17 -target-player=11.4
-swf-version=18 -target-player=11.5
-swf-version=19 -target-player=11.6
-swf-version=20 -target-player=11.7
-swf-version=21 -target-player=11.8

the "simpler combo would be
-swf-version=13 -target-player=11.0
as it is easier to remember

in any case you should also be able to use
-swf-version=9 with whatever Adobe Flex SDK / Apache Flex SDK version
as long as you replace the path
${flex_sdk}/libs/player/{targetPlayerMajorVersion}.{targetPlayerMinorVersion}/playerglobal.swc
with a redtamarin.swc renamed to playerglobal.swc

for example if you use flex_sdk_4.6.zip

then you will have
${flx_sdk)/frameworks/libs/player/11.1/playerglobal.swc

you could do that

$ mv ${flx_sdk)/frameworks/libs/player/11.1/playerglobal.swc ${flx_sdk)/frameworks/libs/player/11.1/playerglobal.swc.old
$ cp redtamarin.swc ${flx_sdk)/frameworks/libs/player/11.1/playerglobal.swc

after that you could use -swf-version=14 -target-player=11.1
but using the default should be enough

alternatively if you want to preserve the current playerglobal.swc "as is

$ mkdir ${flx_sdk)/frameworks/libs/player/9.0/
$ cp redtamarin.swc ${flx_sdk)/frameworks/libs/player/9.0/playerglobal.swc

and compile with -target-player=9.0

[Hydp]

To clarify, I'm using a recent AIR SDK release (29/30) from 2018. I had to manually create the directory ${flex_sdk}/libs/player/11.1 and add redtamarin.swc to it (postly renamed playerglobal.swc), and I still have the default MXMLC playerglobal.swc inside ${flex_sdk}/frameworklibs/player/29.0. MXMLC's default SWC version is 29.0, but I obviously don't want to override it as that messes the compiler and thus I kept the playerglobal.swc in another SWF version folder.

So, is -target-player something like -swf-version, i.e., it points to a folder inside the frameworks/libs?

[zwetan]

well, I tested with Flex SDK 4.6

or example if you use flex_sdk_4.6.zip

https://www.adobe.com/devnet/flex/flex-sdk-download.html

http://download.macromedia.com/pub/flex/sdk/flex_sdk_4.6.zip

now my point in all that is that there is no bug in redtamarin/redshell
if it crashes it is because of how it is compiled

if you want to use that AIR SDK in particular
and related to that

but I obviously don't want to override it as that messes the compiler and thus I kept the playerglobal.swc in another SWF version folder.

overriding the default player version is supported, I see no reasons why it would mess the compilation

you gonna have to figure out on your own as I have no time to just install that particular AIR SDK to show you how

see it as a good exercise as it is always good to know how to know the gritty details of a compiler

[Hydp]

I did it all right and followed every tip you gave me. I wasn't too clear on some comments at all, but I know I'm doing a lot of moves. It's like I'm full of macros in my body. And the funniest thing is that, in principle, I just wanted to have fine import directives that are solved very ahead of definition time.

However, I'm letting these ASC things for the future. I think the solution will be to use MXMLC as normal and execute the SWF with Flash Projector, but I'm not sure if I'll be excited to waste my time again.

Even though, thank you for helping me.