Backtrace

#0  0x00007f40f703d2c5 in raise () from /usr/lib/libc.so.6
#1  0x00007f40f703e748 in abort () from /usr/lib/libc.so.6
#2  0x00007f40f7036312 in __assert_fail_base () from /usr/lib/libc.so.6
#3  0x00007f40f70363c2 in __assert_fail () from /usr/lib/libc.so.6
#4  0x00007f40f45b1b59 in llvm::cl::parser<llvm::ScheduleDAGSDNodes* (*)(llvm::SelectionDAGISel*, llvm::CodeGenOpt::Level)>::addLiteralOption<llvm::ScheduleDAGSDNodes* (*)(llvm::SelectionDAGISel*, llvm::CodeGenOpt::Level)> (this=0x7f40f38ae9d0 <ISHeuristic+96>, Name=0x7f40f308a1d5 "default", 
    V=@0x7fff83a92008: 0x7f40f4598600 <llvm::createDefaultScheduler(llvm::SelectionDAGISel*, llvm::CodeGenOpt::Level)>, HelpStr=0x7f40f2f2b68c "Best scheduler for the target")
    at /home/zoxc/llvm-build/llvm/include/llvm/Support/CommandLine.h:646
#5  0x00007f40f45b25aa in llvm::RegisterPassParser<llvm::RegisterScheduler>::NotifyAdd (this=0x7f40f38ae9c8 <ISHeuristic+88>, N=0x7f40f308a1d5 "default", 
    C=0x7f40f4598600 <llvm::createDefaultScheduler(llvm::SelectionDAGISel*, llvm::CodeGenOpt::Level)>, D=0x7f40f2f2b68c "Best scheduler for the target")
    at /home/zoxc/llvm-build/llvm/include/llvm/CodeGen/MachinePassRegistry.h:148
#6  0x00007f40f480ba8f in llvm::MachinePassRegistry::Add (this=0x7f40f5a18320 <llvm::RegisterScheduler::Registry>, Node=0x7f40f38aeb38 <defaultListDAGScheduler>)
    at /home/zoxc/llvm-build/llvm/lib/CodeGen/MachinePassRegistry.cpp:41
#7  0x00007f40f22ae445 in llvm::RegisterScheduler::RegisterScheduler (this=0x7f40f38aeb38 <defaultListDAGScheduler>, N=0x7f40f308a1d5 "default", 
    D=0x7f40f2f2b68c "Best scheduler for the target", C=0x7f40f4598600 <llvm::createDefaultScheduler(llvm::SelectionDAGISel*, llvm::CodeGenOpt::Level)>)
    at /home/zoxc/llvm-build/llvm/include/llvm/CodeGen/SchedulerRegistry.h:43
#8  0x00007f40f22a0e1d in llvm::RegisterScheduler::RegisterScheduler (this=0x7f40f38aeb38 <defaultListDAGScheduler>, N=0x7f40f308a1d5 "default", 
    D=0x7f40f2f2b68c "Best scheduler for the target", C=0x7f40f4598600 <llvm::createDefaultScheduler(llvm::SelectionDAGISel*, llvm::CodeGenOpt::Level)>)
    at /home/zoxc/llvm-build/llvm/include/llvm/CodeGen/SchedulerRegistry.h:43
#9  0x00007f40f1bb4129 in __cxx_global_var_init38 () from /usr/lib/xorg/modules/dri/swrast_dri.so
#10 0x00007f40f1bb41aa in global constructors keyed to a () from /usr/lib/xorg/modules/dri/swrast_dri.so
#11 0x00007f40f8c629d6 in call_init () from /lib64/ld-linux-x86-64.so.2
#12 0x00007f40f8c62aba in _dl_init_internal () from /lib64/ld-linux-x86-64.so.2
#13 0x00007f40f8c66af9 in dl_open_worker () from /lib64/ld-linux-x86-64.so.2
#14 0x00007f40f8c62816 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2
#15 0x00007f40f8c66329 in _dl_open () from /lib64/ld-linux-x86-64.so.2
#16 0x00007f40f85c3026 in ?? () from /usr/lib/libdl.so.2
#17 0x00007f40f8c62816 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2
#18 0x00007f40f85c35ec in ?? () from /usr/lib/libdl.so.2
#19 0x00007f40f85c30c1 in dlopen () from /usr/lib/libdl.so.2
#20 0x00007f40f5ce80a6 in ?? () from /usr/lib/xorg/modules/extensions/libglx.so
#21 0x00007f40f5ce79d6 in ?? () from /usr/lib/xorg/modules/extensions/libglx.so
#22 0x00007f40f5ce6fda in ?? () from /usr/lib/xorg/modules/extensions/libglx.so
#23 0x00000000004aace9 in InitExtensions ()
#24 0x000000000042670c in ?? ()
#25 0x00007f40f7029a15 in __libc_start_main () from /usr/lib/libc.so.6
#26 0x0000000000426c0d in _start ()

Created a LLVM bug report since it looks a LLVM issue: http://llvm.org/bugs/show_bug.cgi?id=15410

This appears to only be an issue with the VMware driver. Also, disabling glx-tls works around the problem.

My trace is from llvmpipe, disabling LLVM and using svga works fine.

Could this be something that causes the RegisterScheduler global to be constructed twice triggering the assertion? Does --enable-glx-tls do something weird?

Ajax, Jerome does this bug look like the load LLVM multiple times bug?

Cheers, Jakob.

Yeah i saw same issue on radeon

Does it work if you build Mesa with --with-llvm-shared-libs? Tom mentioned something like this happens if Mesa is linked to static LLVM libaries.

It might be related to this ... See the explanation

http://lists.freedesktop.org/archives/mesa-dev/2013-January/032944.html

For me building mesa with --with-llvm-shared-libs fixes the crash.

This should be fixed now in mesa master when linking with llvm static libraries.  Can you re-test?

Assuming fixed as per last comment, and no recent bug activity.