OpenFL/Lime segfaults creating its window under Linux

Lime
#1

I’ve got myself an issue running any any OpenFL projects under Linux (Mint 17.3, 64bit, Cinnamon). I suspect I should be filing a bug report (or +1ing one) for Lime, but I’d like to know if I’ve missed anything stupid.

When ever I try to run a neko or linux native openfl app I see the window border for a fraction of a second, then I get a segfault. It’s no issue in my code as I get it with a completely empty new project:

bloognoo@taran ~/Development $ openfl create project Crashes
bloognoo@taran ~/Development $ cd Crashes/
bloognoo@taran ~/Development/Crashes $ openfl test neko -debug
Segmentation fault
bloognoo@taran ~/Development/Crashes $ cd Export/linux64/neko/obj/
bloognoo@taran ~/Development/Crashes/Export/linux64/neko/obj $ neko ApplicationMain.n 
Called from sys.FileSystem::$statics line 1
Called from ApplicationMain::main line 139
Called from ApplicationMain::create line 19
Called from openfl.display.Application::create line 44
Called from lime.app.Application::createWindow line 202
Called from openfl.display.Window::create line 24
Called from a C function
Called from lime.ui.Window::create line 248
Called from lime.graphics.Renderer::create line 34
Called from lime._backend.native.NativeRenderer::create line 72
Called from lime._backend.native.NativeRenderer::render line 117
Uncaught exception - Segmentation fault

I’ve reproduced it with both the git and haxelibs versions of the following:

lime: [2.8.2]
openfl-samples: [3.3.1]
openfl: [3.5.3]

Haxelib is 3.2.0-rc3, Haxe is 3.2.1

I’ve also updated my graphics drivers - it’s an intel i945 chipset - to no avail.

Has anyone else seen this? Has anyone fixed it?

Many Thanks

H

#2

Does it work with openfl test linux -debug?

#3

Could you try openfl test linux --window-hardware=false and see if it makes a difference? Is this a full desktop OS install, or a VM?

#4

openfl test linux -debug fails

openfl test linux --window-hardware=false works

openfl test neko --window-hardware=false works

I’m running on hardware, HP tc4400 tablet/laptop.

This gives me a way forward for my dev work, which is awesome.

How best can I help debug what looks like a HW compatibility issue?

H

#5

Can you tell if OpenGL 2 features work? If framebuffers work?

#6

My OpenGL is scant at best - Will any of the lime / openfl samples tell you?

#7

Heroku Shaders and BunnyMark both segfault, running with --windows-hardware=“false” gives me empty windows, but that’s not really surprising

#8

I would recommend trying some other samples, if you can, such as DisplayingABitmap or the Lime HelloWorld and SimpleImage samples. Try them with or without --window-hardware=false.

It will tell us if GL is working (“HelloWorld” should work with GL that is not fully compatible with GL2 for example) and if you are able to support software windows for other samples (many samples work without hardware)

It could be a driver issue

#9

Sorry for the slow reply. I’ve dug around to try and find some common behaviour between the code samples that work and those that don’t.

My rosetta stone came when I built BabylonHx’s default project with both lime and openfl. The lime build works, the openfl fails, and fails in the same way as I have had it fail with various generations of nvidia driver, nouveau nvidia driver and the intel i915 chipset drivers.

I then compared the stack between the BabylonHx demo and BunnyMark and found the commonality is a failed malloc call in glibc made by lime via openfl. This is the consistent stack trace between the two:

#0  0x00007ffff6dcfab2 in __GI___libc_free (mem=0x7ffff651c596) at malloc.c:2968
#1  0x00007ffff620c7a7 in lime::lime_system_get_directory(int, HxString, HxString) () from ./lime.ndll
#2  0x00000000010bf86f in lime::_system::System_obj::get_fontsDirectory () at ./src/lime/system/System.cpp:345
#3  0x00000000005ed669 in openfl::_internal::text::TextEngine_obj::getFontInstance (format=...)
    at ./src/openfl/_internal/text/TextEngine.cpp:2977
#4  0x00000000005e4689 in openfl::_internal::text::TextEngine_obj::getLayoutGroups (this=0x7fffe103ac0c)
    at ./src/openfl/_internal/text/TextEngine.cpp:708
#5  0x00000000005ec19a in openfl::_internal::text::TextEngine_obj::update (this=0x7fffe103ac0c)
    at ./src/openfl/_internal/text/TextEngine.cpp:2679
#6  0x000000000059fc03 in openfl::text::TextField_obj::__updateLayout (this=0x7fffe103a618) at ./src/openfl/text/TextField.cpp:3821
#7  0x00000000006db4ea in openfl::_internal::renderer::cairo::CairoTextField_obj::render (textField=..., renderSession=...)
    at ./src/openfl/_internal/renderer/cairo/CairoTextField.cpp:108
#8  0x000000000059e527 in openfl::text::TextField_obj::__renderGL (this=0x7fffe103a618, renderSession=...)
    at ./src/openfl/text/TextField.cpp:3514
#9  0x0000000001480f19 in openfl::display::DisplayObjectContainer_obj::__renderGL (this=0x7ffff7f94088, renderSession=...)
    at ./src/openfl/display/DisplayObjectContainer.cpp:2820

This looks like the smoking gun. I have the full traces if that would be useful.

I’ll keep poking and see what else I can find.

H

#10

Could you try Lime 2.9.0 or the latest source?

#11

It’s using lime 2.9.1, openfl 3.6.1.

I’ll try the source version tonight

#13

You can also try the latest haxelib