<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Flightgear crashes during splashboot with R600 driver, LLVM 3.7.0 and mesa 11.0.2" href="https://bugs.freedesktop.org/show_bug.cgi?id=92214#c26">Comment # 26</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Flightgear crashes during splashboot with R600 driver, LLVM 3.7.0 and mesa 11.0.2" href="https://bugs.freedesktop.org/show_bug.cgi?id=92214">bug 92214</a> from <a class="email" href="mailto:mister.freeman@laposte.net" title="Barto <mister.freeman@laposte.net>"> Barto</a> <pre>(In reply to Barto from <a href="show_bug.cgi?id=92214#c25">comment #25</a>) > to be sure I am currently trying to compile LLVM 3.7.0 with the classic way > ( ./configure ) by reverting this patch in order to allow this : > > <a href="http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20150629/284970.html">http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20150629/284970.html</a> > > and I will see if the bug is still here when libLLVM.so.3.7 is building with > ./configure and not CMAKE I tried : the bug is still here, even with an autoconf build, so the bug is elsewhere, maybe in mesa source code ( bad initialization of llvm 3.7.0 lib ) , or in LLVM 3.7.0, could be also in glibc 2.22-3 but I doubt, here is a new backtrace of the tunnel program ( from mesa-demos ), here I use a debug version of glibc 2.22-3 : (gdb) thread apply all bt full Thread 2 (Thread 0x7fffee4c6700 (LWP 11292)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 No locals. #1 0x00007ffff22fe04a in ?? () from /usr/lib/xorg/modules/dri/r600_dri.so No symbol table info available. #2 0x00007ffff22fd787 in ?? () from /usr/lib/xorg/modules/dri/r600_dri.so No symbol table info available. #3 0x00007ffff3d74464 in start_thread (arg=0x7fffee4c6700) at pthread_create.c:334 __res = <optimized out> pd = 0x7fffee4c6700 now = <optimized out> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140737191372544, -3511726595263618993, 0, 140737488345551, 3, 140737488348064, 3511694852238942287, 3511735595139276879}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = <optimized out> pagesize_m1 = <optimized out> sp = <optimized out> freesize = <optimized out> __PRETTY_FUNCTION__ = "start_thread" #4 0x00007ffff704d13d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 No locals. Thread 1 (Thread 0x7ffff7f9a740 (LWP 11286)): #0 0x00007fffedaa55eb in ?? () No symbol table info available. #1 0x000000000076a320 in ?? () No symbol table info available. #2 0x00007fffffffd630 in ?? () No symbol table info available. #3 0x0000000000000007 in ?? () No symbol table info available. ---Type <return> to continue, or q <return> to quit--- #4 0x0000000000000000 in ?? () No symbol table info available. it would be interesting to put a breakpoint in mesa 11.0.3 source code, a location where LLVM 3.7.0 functions are used or loaded, my purpose is to know if the bug occurs before or after mesa tries to use LLVM functions, and if it's a problem related to glibc or gcc libs, but I don't know where I should put this breakpoint, another test would be to create a simple program test, for example a simple test.c program who loads LLVM 3.7.0 lib and try to run a simple LLVM function, the idea is to check if LLVM 3.7.0 lib can be loaded and used without a crash</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>