Crash in Gallium3D for 3D program using LLVM

[JeromeAtTaodyne]

404

Just to let you know: x86_64 builds of Tao Presentations Discovery is not available (404).

Hello RussianNeuroMancer,

I work at Taodyne and I just checked our download page at http://www.taodyne.com/shop/en/conte...mpare-versions
There is no 404 on my side.

Could you tell me what URL returned a 404? Please contact me via PM so that we don't pollute the forum.

[RussianNeuroMancer]

Offtopic

Just to let you know: x86_64 builds of Tao Presentations Discovery is not available (404).

[christophe3d]

Should the application have to protect its LLVM symbols?

Here is the solution we applied in our case. In the library which uses LLVM, we used the following link option:

-Wl,--exclude-libs,ALL

This instructs the linker to make the LLVM symbols invisible to the outside world. As a result, Gallium3D no longer attempts to use "our" LLVM in llvmpipe.

I believe we shouldn't have to do that. I see no reason why the LLVM inside Gallium3D should be visible to the outside world at all, or why Gallium3D should interact with the LLVM in the application at all. This is one case where I feel that Gallium3D would be better off linking to LLVM statically and hiding the symbols.

Basically, a graphics driver shouldn't crash an application that happens to use (a possibly different version of) one of the libraries it uses.

What do you think?

[christophe3d]

At Taodyne, we are developing a 3D presentation software called Tao Presentations. It works well on Linux, except with Gallium3D drivers (e.g. under VMware or on systems with software fallback; currently testing on an ATI ES 1000...)

The problem is a crash very early, simply trying to create a GLX context. The stack trace looks like this:

#0 0x00007fffd2bbe191 in gallivm_remove_garbage_collector_callback () from /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so
#1 0x00007fffd2b28615 in ?? () from /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so
#2 0x00007fffd2b28b63 in llvmpipe_create_context () from /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so
#3 0x00007fffd21c7062 in ?? () from /usr/lib/x86_64-linux-gnu/dri/libgallium.so
#4 0x00007fffd2aec495 in dri_create_context () from /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so
#5 0x00007fffd2ae9395 in ?? () from /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so
#6 0x00007fffd2ae944d in ?? () from /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so
#7 0x00007ffff2ea5b3e in ?? () from /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1
#8 0x00007ffff2e8333e in ?? () from /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1
#9 0x00007ffff2e83a95 in glXCreateContext () from /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1
#10 0x00007ffff465a54e in ?? () from /usr/lib/x86_64-linux-gnu/libQtOpenGL.so.4
#11 0x00007ffff45e258d in QGLFormat:penGLVersionFlags() () from /usr/lib/x86_64-linux-gnu/libQtOpenGL.so.4
#12 0x00000000004d167a in Tao::Application::Application (this=0x7fffffffded0, [email protected]: 1, argv=0x7fffffffe168) at application.cpp:271
#13 0x00000000005de174 in main (argc=1, argv=0x7fffffffe168) at tao_main.cpp:92

My question is: what precautions should a program using LLVM take to avoid interfering with the LLVM pipe?