seg fault after bullet sample completes

[hdiedrich]

erlc -o examples/bullet_engine examples/bullet_engine/*.erl
cd examples/bullet_engine && ./start.sh
Erlang/OTP 17 [erts-6.0] [source-07b8f44] [64-bit] [smp:4:4] [async-threads:10] [hipe] [kernel-poll:false] [dtrace]

Eshell V6.0  (abort with ^G)
1> ./start.sh: line 2:  9736 Segmentation fault: 11  erl +stbt db -pa ../../ebin -eval "bullet_engine:run()."
make[1]: *** [bullet] Error 139
make: *** [all] Error 2

[essen]

Yeah then it's definitely to do with GC order. I guess Linux doesn't care about it but OSX does.

[essen]

I've been looking into this. On Linux I get the renderer destroyed before the window, so no problem. Can you add a printf in both dtor functions of c_src/sdl_renderer.c and c_src/sdl_window.c and tell me in what order they are called? If this is the actual issue then I have a fix in mind. Otherwise, heh, I'll need an OSX to test.

[essen]

I believe this one should be fixed in the newest commit.

[brainstormi]

unfortunately, the issue persists on osx 10.9

[essen]

I have an OSX around in a VM now, I will try when I can access it.

[essen]

Well I fail to even compile it. I will get back to you.

[essen]

I can reproduce. I will get you something during the day.

[essen]

My problem might be because SMP was not enabled (trying to add a second core to the VM, but OSX doesn't seem to like that...). Do you have SMP enabled?

[essen]

OK the SMP issue I could fix by adding -smp enable. And now I finally could observe the issue. I'll work on a fix when possible.

[brainstormi]

Yes, smp is enabled when the issue raised... Thanks for your support. I
would like to ask you some questions about your thoughts around your
project, not sure if this is the best place to discuss it...
El 23/7/2015 1:27 p. m., "Loïc Hoguin" notifications@github.com escribió:

OK the SMP issue I could fix by adding -smp enable. And now I finally
could observe the issue. I'll work on a fix when possible.

—
Reply to this email directly or view it on GitHub
#2 (comment).

[essen]

Feel free to open a new ticket, tickets are fine for discussions. :-)

[brainstormi]

Issue persist with esdl2 master brach in OSX... Segfault when demo ends:
./start.sh: line 2: 11970 Segmentation fault: 11 erl -smp enable +stbt db -pa ../../ebin -eval "bullet_engine:run()."
make: *** [bullet_engine] Error 139

[essen]

Yep I confirm this both on Windows and OSX. Fine on Linux.

[brainstormi]

I'm just trying to get some insights about this issue... but trying to setup a dummy debugging environment for erlang+nifs in OSX/Windows is causing me more than a headache.
Some tip about how to debug this issue?

I could make some progress in OSX side, it seems a bit easier than windows to setup a enabled debug emulator, following the instructions in:
http://www.erlang.org/doc/installation_guide/INSTALL.html
The issue is that launching, for example, "hello_sdl" demo just crash trying to render the texture at the beginning, generating the following stack:

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_platform.dylib 0x00007fff93f2fd06 _platform_bzero$VARIANT$Merom + 22
1 libsystem_c.dylib 0x00007fff89f91a6b __memset_chk + 22
2 beam.debug.smp 0x0000000015e71fb3 debug_free + 147 (erl_alloc.c:4032)
3 beam.debug.smp 0x0000000015e66001 erts_free + 97 (erl_alloc.h:254)
4 beam.debug.smp 0x0000000016058a7c enif_free + 28 (erl_nif.c:245)
5 esdl2.so 0x0000000016627812 thread_render_copy + 82
6 esdl2.so 0x0000000016623723 nif_thread_handle + 99
7 esdl2.so 0x0000000016623816 nif_main_thread + 70
8 beam.debug.smp 0x000000001608d807 erts_sys_main_thread + 359 (sys.c:3311)
9 beam.debug.smp 0x0000000015e9e7fa erl_start + 14538 (erl_init.c:2166)
10 beam.debug.smp 0x0000000015e06402 main + 34 (erl_main.c:30)
11 libdyld.dylib 0x00007fffa02625ad start + 1

Launching it with standard emulator, crash at the end, as always... but seems to be associated to a missing texture ?¿???¿ ... this is only my assumption looking at the stack because I can't trace anything :(

Thread 15 Crashed:: 2_scheduler
0 libGL.dylib 0x00007fff9d8134bd glDeleteTextures + 18
1 libSDL2-2.0.0.dylib 0x0000000015d4298a GL_DestroyTexture + 54
2 libSDL2-2.0.0.dylib 0x0000000015d39578 SDL_DestroyTexture_REAL + 164
3 esdl2.so 0x00000000141aa55c dtor_Texture + 28
4 beam.smp 0x0000000013cdb392 nif_resource_dtor + 98

Seeing your last try to solve GC order between Renderer and Window using enif_keep_resource, enif_release_resource and the dependency macros for resources you integrated looks good... could it be the same but this time between Renderer and Texture GC order?... I'm only thinking out loud shooting at anything that moves...