Bug 37637

What kind of crash is it exactly?

It looks like it doesn't even loading properly.

This has some similarities with like https://bugzilla.redhat.com/show_bug.cgi?id=706395 . Please try building the bug.c attached to that bug and tell me what happens.

Also, please rebuild with --enable-debug and retry.

(In reply to comment #1)
> What kind of crash is it exactly?
It segfaults upon initializing:
...
Opening SDL viewport.
Bound to SDLGLDrv.so
Loaded render device class.
Initializing SDLGLDrv...
binding libGL.so.1
Resizing SDL viewport. X: 1280 Y: 1024
OpenGL
Signal: SIGSEGV [segmentation fault]
Aborting.

> 
> It looks like it doesn't even loading properly.
> 
> This has some similarities with like
> https://bugzilla.redhat.com/show_bug.cgi?id=706395 . Please try building the
> bug.c attached to that bug and tell me what happens.
I tried bug.c with r300g of 7.10.2 and both r300g and llvmpipe of 7.11-dev, but none of them failed. At least nothing was printed to the console.

The comments in bug.c mention llvm 2.8. I'm using llvm 2.6 (the default one in debian unstable). Is this a problem?

> 
> Also, please rebuild with --enable-debug and retry.
I always build mesa with --enable-debug.

OK. I'm out of clues then.

Does building without LLVM support make a difference (r300 requires llvm but you may still use swrast with softpipe).

Have you tried to start ut with gdb to get a better backtrace?

Now I had some time to investigate this.

It seems to me that llvm initializes some iostream thing, which calls dynamic_cast<>() (at libstdc++-v3/include/bits/locale_classes.tcc:97), but the unreal engine has its own implementation of that, or something with the same name (in Core.so, unfortunately this is not included in the public unreal sources), which takes precedence over libc++, and the world ends. Maybe it wasn't a very good idea to use C++ in a GL implementation.

I also tried to run ut in wine 1.3.20, but the mouse is insanely fast, and the mouse buttons jump the cursor instead of clicking. Running old things on linux is really problematic :(

(In reply to comment #5)
> Now I had some time to investigate this.
> 
> It seems to me that llvm initializes some iostream thing, which calls
> dynamic_cast<>() (at libstdc++-v3/include/bits/locale_classes.tcc:97), but the
> unreal engine has its own implementation of that, or something with the same
> name (in Core.so, unfortunately this is not included in the public unreal
> sources), which takes precedence over libc++, and the world ends.

Hmm..

> Maybe it
> wasn't a very good idea to use C++ in a GL implementation.

There's nothing C++ specific about this.  This is a symbol collision which can and sometimes happen with C too.

The problem here is that we're linking to LLVM/libstdc++ as a shared library, and polluting the symbol namespace. The right fix is to link to LLVM/libstdc++ as a static library and/or ensure that all its symbols are not visible outside of the DRI driver.

You may try linking LLVM statically instead of dynamically as workaround.

But otherwise I'm afraid there's nothing practical we can do about this.

This also happens with ut2003. Honestly I don't understand comment #7. The mesa build options default to static llvm linking anyway:
--with-llvm-shared-libs link with LLVM shared libraries [default=disabled]

So how should the workaround for this problem look like?

This still happens in mesa git master.

Im currently using the following setup:
(1) llvm is build with static libstdc++:
ldd doesn't show any ref to libstdc++ anymore, however nm confirm that libLLVM is now exporting the dynamic_cast symbol

(2) mesa is build with shared llvm
Building with static libstdc++ doesn't seem to work here, since ldd shows that r600g_dri.so still refs to libstdc++


What I find strange is that swrastg_dri.so works flawlessly, even though it also refs to _both_ libLLVM and libstdc++.

I'm also attaching two gdb backtraces. One without any preloading (crashing results from static initialization inside r600g), and one with llvm preloading (crashing results because ut2003's Core.so now uses dynamic_cast from libLLVM).

I think the crashes would go away if one could hide the libstdc++ symbols that reside in libLLVM. Any ideas how to tackle this?

Greets,
Tobias

Created attachment 73329 [details]
two bts with recent mesa git master

Both crashes are due to dynamic_cast, but the calling chain is different.

Tried another approach:
llvm build normally and mesa with static llvm. I then replaced -lstdc++ by -static-libstdc++ for building of r600g_dri.so (targets/dri-r600).

Doesn't work though:
ibGL error: dlopen /usr/lib/dri/r600_dri.so failed (/usr/lib/dri/r600_dri.so: undefined symbol: _ZTVN10__cxxabiv120__si_class_type_infoE)

I wonder why this doesn't work??

Last update for today. Current commandline is this:
g++ -fPIC -DPIC -shared -nostdlib /usr/lib/gcc/i686-pc-linux-gnu/4.7.2/../../../../lib/crti.o /usr/lib/gcc/i686-pc-linux-gnu/4.7.2/crtbeginS.o  .libs/target.o .libs/utils.o .libs/dri_util.o .libs/xmlconfig.o  -Wl,--whole-archive ../../../../src/mesa/.libs/libmesagallium.a ../../../../src/gallium/auxiliary/.libs/libgallium.a ../../../../src/gallium/drivers/r600/.libs/libr600.a ../../../../src/gallium/state_trackers/dri/drm/.libs/libdridrm.a ../../../../src/gallium/winsys/radeon/drm/.libs/libradeonwinsys.a ../../../../src/gallium/drivers/trace/.libs/libtrace.a ../../../../src/gallium/drivers/rbug/.libs/librbug.a ../../../../src/gallium/drivers/noop/.libs/libnoop.a /usr/lib/gcc/i686-pc-linux-gnu/4.7.2/libstdc++.a -Wl,--no-whole-archive -L/usr/lib/llvm -lffi -lLLVMipo -lLLVMVectorize -lLLVMBitReader -lLLVMAsmParser -lexpat -lrt -lpthread -ldl -ldrm -ldrm_radeon -lLLVMMCJIT -lLLVMBitWriter -lLLVMX86Disassembler -lLLVMX86CodeGen -lLLVMX86AsmParser -lLLVMX86Desc -lLLVMX86AsmPrinter -lLLVMX86Utils -lLLVMX86Info -lLLVMJIT -lLLVMRuntimeDyld -lLLVMExecutionEngine -lLLVMR600CodeGen -lLLVMSelectionDAG -lLLVMAsmPrinter -lLLVMMCParser -lLLVMCodeGen -lLLVMScalarOpts -lLLVMInstCombine -lLLVMTransformUtils -lLLVMipa -lLLVMAnalysis -lLLVMTarget -lLLVMCore -lLLVMR600Desc -lLLVMR600Info -lLLVMR600AsmPrinter -lLLVMMC -lLLVMObject -lLLVMSupport -L/usr/lib/gcc/i686-pc-linux-gnu/4.7.2 -L/usr/lib/gcc/i686-pc-linux-gnu/4.7.2/../../../../i686-pc-linux-gnu/lib/../lib -L/usr/lib/gcc/i686-pc-linux-gnu/4.7.2/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/i686-pc-linux-gnu/4.7.2/../../../../i686-pc-linux-gnu/lib -L/usr/lib/gcc/i686-pc-linux-gnu/4.7.2/../../.. -lm -lc -lgcc_s /usr/lib/gcc/i686-pc-linux-gnu/4.7.2/crtendS.o /usr/lib/gcc/i686-pc-linux-gnu/4.7.2/../../../../lib/crtn.o  -O2  -Wl,--version-script=sym_exports -Wl,-soname -Wl,r600_dri.so -o .libs/r600_dri.so

sym_exports:
{
  local: __dynamic_cast;
};

(this effectively hides __dynamic_cast)

Gives a warning:
/usr/lib/gcc/i686-pc-linux-gnu/4.7.2/../../../../i686-pc-linux-gnu/bin/ld: /usr/lib/gcc/i686-pc-linux-gnu/4.7.2/libstdc++.a(compatibility.o): warning: relocation in readonly section `.eh_frame'.
/usr/lib/gcc/i686-pc-linux-gnu/4.7.2/../../../../i686-pc-linux-gnu/bin/ld: warning: creating a DT_TEXTREL in object.

But ut2003 now loads properly.

Still happening in Ubuntu 14.04. Binary Nvidia drivers don't suffer the problem, but Mesa drivers on Intel GMA 3100 crashes with segfault. Can provide debug information on request.

*** Bug 108933 has been marked as a duplicate of this bug. ***

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/967.