Segfault on any lime build - Ubuntu 16.04



  • Yesterday I could use lime test neko, lime test linux etc, but today, after a system update from last night, I get "Segmentation fault (core dumped)" when I run both of those commands. I have already re-installed haxe and all haxelibs.

    My .haxelib contains the following line
    /home/brandon/haxelib
    And this folder contains all of the haxe libraries, as expected.

    I can still run haxe files, but I can't run anything through lime/openfl/haxelib, which is down to the latest ubuntu update, I would assume.

    Edit: I can run the basic lime helloworld application, but when I <haxelib> flixel in, I get segfaults. Same goes for haxepunk too, but not for openfl or any non-graphical library.

    Edit: FIXED! Ubuntu installed a broken copy of libneko which I didn't know about, so I removed it and the correct, not broken version remained, which works. It was very strange how I could still run openfl, just not flixel though. Might be worth looking into this further in the future.



  • Do you mean that lime itself crashes or your app crashes?
    Try removing stuff from export subdirectory of your project directory, and then build again. It could be that Ubuntu upgraded some libraries to binary-incompatible versions.



  • Also you have a chance to read something useful in backtrace, which you can get from executable and core dump like this: http://blog.xojo.com/take-a-core-dump-linux



  • @starry-abyss I used a flixel template to test, and it still happens.
    I'm just testing it on a vm and it seems to be working fine, with the same kernel update as my install. It also has the same path configuration for haxelibs too.

    I will read through the core dump article and see what I can find out.

    Edit: Did the core dump, but I have no idea where it is being stored. Do you know where it's stored?



  • @Brandon-R On distros that I used it was just in the current directory. Seems that it's not always true: http://stackoverflow.com/questions/2065912/core-dumped-but-core-file-is-not-in-current-directory
    It seems that you'll need ulimit -c unlimited to get the dump, like in the article above



  • Also it's possible to run the application in gdb from the beginning, skipping the dump part (if problem is reproducible).
    I think it's: 'gdb app', then 'run', then 'bt'.



  • @starry-abyss I did set ulimit -c unlimited.
    I found that the errors are sent to /var/log/apport.log and relevant errors are as follows:

    ERROR: apport (pid 15183) Mon Jun 13 17:01:37 2016: called for pid 15154, signal 11, core limit 0
    ERROR: apport (pid 15183) Mon Jun 13 17:01:37 2016: executable: /usr/bin/neko (command line "neko tools/tools.n test neko /home/brandon/Code/topdown/")
    ERROR: apport (pid 15183) Mon Jun 13 17:01:37 2016: executable version is blacklisted, ignoring

    No idea what this means, and a google search doesn't seem to be helping me much.

    I will try looking into running lime through gdb now :)

    Edit: Using the lime source from github and building it to see if it makes any difference.

    Edit: It made no difference. If I make a lime template with no reference to flixel, it runs fine. Soon as I include flixel, it breaks and gives segfault.



  • It isn't a backtrace. Backtrace shows what function was called last, and from what function it was called, and from what function function that called the last function was called, and so on. Like in "This Is the House That Jack Built" :-)



  • @starry-abyss Well I couldn't get gdb to run, and I can't compile an executable with lime as it segfaults and nothing is left in /build. I have run "lime deploy neko -verbose" and it gives me the following:

    Running command: DEPLOY
    Called from ? line 1
    Called from CommandLineTools.hx line 1400
    Called from CommandLineTools.hx line 25
    Called from a C function
    Called from CommandLineTools.hx line 126
    Called from CommandLineTools.hx line 619
    Called from lime/project/PlatformTarget.hx line 84
    Called from lime/tools/platforms/LinuxPlatform.hx line 194
    Called from lime/tools/helpers/DeploymentHelper.hx line 15
    Called from lime/tools/helpers/ZipHelper.hx line 25
    Called from /usr/share/haxe/std/neko/_std/sys/FileSystem.hx line 68
    Called from /usr/share/haxe/std/neko/_std/sys/FileSystem.hx line 59
    Uncaught exception - std@sys_file_type

    Not sure if this helps. I can still run lime test neko/linux on the lime helloworld application, but I just get a segfault with flixel/haxepunk.
    Do you have any other ideas that I can try?



  • I got this exception somewhere.
    My guess - maybe there is some particular file (or several) in assets directory, that causes lime to crash? Try to (re)move them one by one



  • @starry-abyss I edited my original post to say that I fixed it :) It was a broken/old version of libneko from apt. Libneko0 was installed as well as libneko2. 0 was broken, while 2 was needed. No idea how both got installed, but it was suggested to remove the old one by apt autoremove. After that, flixel worked perfectly. What is annoying is that there was nothing saying that it was an issue with neko, as I could still use other libraries and still compile to neko as long as I wasn't using flixel. But at least it is fixed now, and this could help somebody else so I will leave it here.



  • @Brandon-R Glad you figured it out! Apparently lime tool itself uses neko library :-)


Log in to reply
 

Looks like your connection to HaxeFlixel was lost, please wait while we try to reconnect.