Bug 37637

Summary: unreal tournament crashes with mesa 7.11-dev
Product: Mesa Reporter: almos <aaalmosss>
Component: Mesa coreAssignee: mesa-dev
Status: RESOLVED MOVED QA Contact:
Severity: normal    
Priority: medium CC: bugs, jfonseca, network723
Version: git   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments: backtrace
two bts with recent mesa git master

Description almos 2011-05-26 09:42:52 UTC
Created attachment 47193 [details]
backtrace

It runs fine with r300g of mesa 7.10.2, but both r300g and llvmpipe of 7.11-dev segfault. I think llvm causes the trouble (see frame #15), but frame #9 is also suspicious.
Comment 1 Jose Fonseca 2011-05-26 09:51:47 UTC
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.
Comment 2 almos 2011-05-26 10:40:46 UTC
(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.
Comment 3 Jose Fonseca 2011-05-26 10:44:55 UTC
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).
Comment 4 Tobias Jakobi 2011-05-26 11:50:30 UTC
Have you tried to start ut with gdb to get a better backtrace?
Comment 5 almos 2011-05-27 13:05:10 UTC
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 :(
Comment 6 Jose Fonseca 2011-05-27 14:21:44 UTC
(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.
Comment 7 Jose Fonseca 2012-10-30 10:09:13 UTC
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.
Comment 8 Tobias Jakobi 2012-11-01 17:58:49 UTC
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?
Comment 9 Tobias Jakobi 2013-01-20 14:57:11 UTC
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
Comment 10 Tobias Jakobi 2013-01-20 14:57:54 UTC
Created attachment 73329 [details]
two bts with recent mesa git master

Both crashes are due to dynamic_cast, but the calling chain is different.
Comment 11 Tobias Jakobi 2013-01-20 19:37:15 UTC
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??
Comment 12 Tobias Jakobi 2013-01-20 20:21:34 UTC
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.
Comment 13 Ray Ingles 2014-07-28 16:44:00 UTC
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.
Comment 14 Timothy Arceri 2019-05-07 05:26:50 UTC
*** Bug 108933 has been marked as a duplicate of this bug. ***
Comment 15 GitLab Migration User 2019-09-18 20:22:41 UTC
-- 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.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.