Neko.exe crash compiling from Flash Develop

Sometimes when I compile from Flash Develop to cpp targets “neko.exe” crashes but when I compile from command line it works fine. Is that normal?

If I try to compile to neko it says: “Uncaught exception - std@module_read” and it fails to compile.

This is weird because sometimes it is compiling fine and when I compile from command line it seems to work always.

Flash always compiles. I’m using windows 7 64bits.

actuate: 1.7.2 1.7.3 1.7.5 1.8.0 [1.8.1]
admob: git [dev:C:\HaxeToolkit\haxe\lib/admob/git]
asiads: git [dev:C:\HaxeToolkit\haxe\lib/asiads/git]
dragonbones: git [dev:C:\HaxeToolkit\haxe\lib/dragonbones/git]
firetongue: git [dev:C:\HaxeToolkit\haxe\lib/firetongue/git]
flixel-addons: 1.0.3 [1.1.0]
flixel-demos: 1.0.2 1.1.0 [1.1.1]
flixel-templates: 1.0.0 1.0.1 [1.0.2]
flixel-tools: 1.0.2 1.0.3 [1.0.4]
flixel-ui: 1.0.1 [1.0.2]
flixel: 3.2.2 3.3.0 3.3.1 3.3.3 3.3.4 3.3.5 [3.3.6]
haxelib_client: 3.1.0-rc.3 [3.1.0-rc.4]
hxcpp: 3.0.2 3.1.21 3.1.22 3.1.30 3.1.37 3.1.39 [3.1.48]
hxlibc: [1.1.4]
hyprate: git [dev:C:\HaxeToolkit\haxe\lib/hyprate/git]
iap: 1.0.4 [1.0.5]
inthebox-macros: git [dev:C:\HaxeToolkit\haxe\lib/inthebox-macros/git]
lime-tools: 1.3.0 1.3.1 1.3.2 1.4.0 1.5.4 1.5.6 [1.5.7]
lime: 0.9.5 0.9.6 0.9.7 1.0.0 1.0.1 2.0.0 2.0.4 [2.0.5]
nape: 2.0.15 [2.0.16]
openfl-bitfive: git [dev:c:\haxetoolkit\haxe\lib/openfl-bitfive/git]
openfl-html5-dom: 1.2.1 [1.2.2]
openfl-html5: 1.1.0-beta 1.1.1-beta 1.4.0-beta 1.4.1-beta [1.4.2-beta]
openfl-native: 1.2.4 1.3.0 [1.4.0]
openfl-samples: 1.2.1 1.3.0 2.1.0 2.2.0 [2.2.1]
openfl: 1.2.3 1.3.0 1.4.0 2.0.0 2.0.1 2.1.6 2.2.1 [2.2.3]
spinehx: [0.2.0]
SpriterHaxeEngine: [1.1.0]
swf: 1.4.1 1.4.2 1.5.2 1.7.0 1.7.3 [1.7.5]
task: [1.0.6]
tilelayer: [0.2.0]

Do you get any other output? You could add -verbose To FlashDevelop’s build settings, and then see when this occurs, it is probably in the build tool somewhere, I always test from the command prompt so maybe there’s something different that’s tripping up on one step

(Sorry for my delay. I was making a Global Game Jam Location)

I don’t understand where do I put -verbose on flash develop. I can’t find the build settings. I searched about this before making the question but I was unable to find it.

If nowhere else, you could even do it in the target drop down, which is editable, change “windows” to “windows -verbose”, and the drop-down will remember both options, so you can switch between them. Otherwise, somewhere in the project options I think there’s a place for additional build arguments

Thanks! I searched for this everywhere :smiley:

Well, it neko crashed (Stopped working) while compiling for windows and the logs are long. I don’t understand any of it:

Not always does this. Usually it works after trying a few times. It is not always on the same place. After that I did another build and it showed this when it crashed:

You are using Nape? Never had success on compiling Neko with Nape and OpenFL.

Other people reported as well:

The bug seems to be fixed on the neko side and require a rebuild from source but personnally I havn’t had any luck on getting it to run but perhaps I didn’t rebuild Neko correctly.

Yes, I’m using Nape with HaxeFlixel. These are the libs I’m using:

<haxelib name="flixel"/>
<haxelib name="flixel-addons" />
<haxelib name="nape" />
<haxelib name="swf" />
<library id="comicLib" path="libs/comicPanels.swf" type="swf" />
<library id="levelUILib" path="libs/UILevels.swf" type="swf" />
<haxelib name="firetongue"/>
<haxedef name="advanced-telemetry" />

The third time that I compiled it worked fine. It is like it always takes three or four times to compile to windows.

How do I do the Neko rebuild?

Download latest, copy this bat file in the root directory:

msbuild neko_vc10.sln
msbuild libs/libs_vc10.sln 
copy /y libs\include\gc\gc.dll bin
cd src
neko ../boot/nekoc tools/install.neko
neko tools/install -nolibs
cd ../bin
nekoc release.neko
neko release.n

Run it inside the Visual Studio Command Prompt. You should get a .zip in the bin folder. Makes sure you have 7za in your PATH as well as SP1 update of Visual Studio I think.

Evrything seems to go well except I always get a “Uncaught exception - load.c(237) : Failed to load library : std.ndll” when trying to compile/run a neko OpenFL game… So I must be missing a step somewhere.

Ok turns out you need to update the DLL inside the template folder (or bin/), still that now gives me this error

Called from zpp_nape/callbacks/CbType.hx line 348
Called from nape/callbacks/CbType.hx line 179
Called from nape/callbacks/CbType.hx line 198
Called from zpp_nape/callbacks/CbType.hx line 174
Called from zpp_nape/callbacks/CbType.hx line 353
Called from zpp_nape/ID.hx line 186
Uncaught exception - Invalid operation (+)

Thanks! But I think I’ll wait for an official update because I don’t want to break anything and I’m not desperate about this.

I found there is a problem compiling Nape with Neko target. Basically what you need to do is to enable DCE in the project.XML file, like this:

<haxeflag name="-dce full" />

By default this setting is commented out in the FlashDevelop template.

1 Like

@Starburst Do you know if the fix is required to build Nape on all platforms, or just on Windows?

It is strange that for me sometimes neko crashes and sometimes it works :frowning:

It seems to be something that was already discussed between nape and openfl but never fixed:

I think that it is a problem with the resulting size of the Neko binary. If I remember properly, Nape uses a LOT of inlining, which performs well in Flash, but not perform as well elsewhere. If it is the binary size, then debug vs. release, or which project uses Nape, could trigger the threshold it crosses. It might be interesting to try --no-inline to see if it makes a difference

I’m using HaxeFlixel Addons and on the include.xml it has:

<!-- This prevents a bug with nape + OpenFL not building on neko (std@module_read error) -->
<haxedef name="NAPE_NO_INLINE" if="neko"/>

But it still gave me the “std@module_read” error when compiling to neko.

Didn’t try on Neko on Mac or Linux yet, no matter if I add

<haxeflag name="-dce full" />


<haxedef name="NAPE_NO_INLINE" if="neko"/>

It still output the same error (debug / release). I know people were refering to this commit: and said this should fix it, but rebuilding Neko from the source didn’t fix it. I also try tweaking the values again using 0xFFFFFFF, still nothing.

It’s a shame since Neko compile quite fast and is usefull to debug, so I use the flash target instead to debug.

If anyone is interested here is my build of Neko for windows: don’t forget to copy the neko.dll into your bin directory.

Ok, using this example, it does seems to works, with the new build of neko this run as expected instead of having the “Uncaught exception - std@module_read” even without DCE or NO INLINE

class Main extends flash.display.Sprite {

     public function new () { 

           var tf = new flash.text.TextField();
           tf.text = "Hi There";

           var space = new;


However using my game I still get the error :confused: and it’s not a huge game (simple pachinko physics game) the neko file is 1.2MB


I’ve been thinking for a while about a Neko replacement. I’d be open to your ideas on this subject.

I enjoy Neko for three potential reasons:

  1. Consistent platform tools (the “openfl” or “lime” command)
  2. A fast desktop testing target
  3. The (unutilized) ability to do cross-desktop compiles

I think Neko is more than sufficient for #1, but I’ve been questioning #2 and have never gotten #3 out of it.

One option would be to work with Neko more directly, to contribute to the project and help make it more suitable as both #2 and #3, potentially. Another is to use a different runtime for this.

At least two options exist – we could use JavaScript, in the form of a node.js application (using the C++/SDL windowing) or node-webkit (using DOM windowing), and we could use Java (using our same C++/SDL windowing or another window library)

Either Java or JavaScript will compile fast like Neko, JavaScript even more so, and either could be good for both testing or cross-desktop builds (say, Mac builds from Windows)

Do you have any opinion on whether either of these choices would be suitable for you? Should we consider this, or stick with Neko?

Neko is also much slower than JavaScript or Java in raw number crunching, and is susceptible to unique quirks (like a default value of “null” for int/float values) which makes it less resilient when it is used as a quick testing target

I think you have to ask this more openly maybe on twitter or it’s own tread. I wouldn’t know what to do.

I always tough that Neko was something invented by the same people that made Haxe. Wouldn’t It be better to talk to them about this?

Is there a code size limit for Neko? I’ve had a project get to the point where it won’t run under Neko any more, and the only thing I can think is that it crossed some size threshold.

I always liked using Neko to iterate quickly, until I ran into that problem, and until I found the null default value making a difference to my tests.

If there is an option to use something that compiles quickly and allows for reliable application testing, I’m sure that many people would find it useful. If you can continue to support Neko at the same time, that’s great.