https://bugs.freedesktop.org/show_bug.cgi?id=92850
Bug ID: 92850 Summary: Segfault loading War Thunder Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: critical Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: bellamorte42@gmail.com QA Contact: dri-devel@lists.freedesktop.org
After logging in the game will segfault almost immediately.
LD_DEBUG=all, strace, and gdb of the core dump below. Apitrace did not yield any error messages. I've waited a few weeks to see if it would clear up on it's own but it hasn't yet.
[0] 25515: symbol= 25515: binding file /usr/lib/libgcc_s.so.1 [0] to /usr/lib/libc.so.6 [0]: normal symbol `dl_iterate_phdr' [GLIBC_2.2.5] dl_iterate_phdr; lookup in file=/usr/lib/libgcc_s.so.1 [0] 25515: symbol=dl_iterate_phdr; lookup in file=/usr/lib/libc.so.6 [0] 25515: binding file /usr/lib/libgcc_s.so.1 [0] to /usr/lib/libc.so.6 [0]: normal symbol `dl_iterate_phdr' [GLIBC_2.2.5] 25515: symbol=modff; lookup in file=./aces [0] 25515: symbol=modff; lookup in file=/usr/lib/libpthread.so.0 [0] 25515: symbol=modff; lookup in file=/usr/lib/libresolv.so.2 [0] 25515: symbol=modff; lookup in file=/usr/lib/libdl.so.2 [0] 25515: symbol=modff; lookup in file=/usr/lib/librt.so.1 [0] 25515: symbol=modff; lookup in file=/usr/lib/libGL.so.1 [0] 25515: symbol=modff; lookup in file=/usr/lib/libX11.so.6 [0] 25515: symbol=modff; lookup in file=/usr/lib/libstdc++.so.6 [0] 25515: symbol=modff; lookup in file=/usr/lib/libm.so.6 [0] 25515: binding file ./aces [0] to /usr/lib/libm.so.6 [0]: normal symbol `modff' [GLIBC_2.2.5] war thunder: line 3: 25515 Segmentation fault (core dumped) MESA_GL_VERSION_OVERRIDE=4.1COMPAT LD_DEBUG=all ./aces
ioctl(8, DRM_IOCTL_RADEON_GEM_VA, 0x7ffe41840040) = 0 ioctl(8, DRM_IOCTL_GEM_CLOSE, 0x7ffe41840030) = 0 ioctl(8, DRM_IOCTL_RADEON_GEM_BUSY, 0x7ffe4183ff40) = 0 futex(0x4990d0c, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x4990d08, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1 futex(0x4990ce0, FUTEX_WAKE_PRIVATE, 1) = 1 poll([{fd=6, events=POLLIN|POLLOUT}], 1, 4294967295) = 1 ([{fd=6, revents=POLLOUT}]) writev(6, [{"\224\1\22\0\10\0\0\1\v\0\0\1\270\7\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 72}], 1) = 72 select(10, [9], NULL, NULL, {0, 0}) = 0 (Timeout) select(10, [9], NULL, NULL, {0, 0}) = 0 (Timeout) ioctl(12, EVIOCGABS(ABS_X), {value=124, minimum=0, ...}) = 0 ioctl(12, EVIOCGABS(ABS_Y), {value=138, minimum=0, ...}) = 0 ioctl(12, EVIOCGABS(ABS_Z), {value=10, minimum=0, ...}) = 0 ioctl(12, EVIOCGABS(ABS_HAT0X), {value=0, minimum=4294967295, ...}) = 0 ioctl(12, EVIOCGABS(ABS_HAT0Y), {value=0, minimum=4294967295, ...}) = 0 ioctl(12, EVIOCGKEY(96), [ 0 ]) = 96 ioctl(18, EVIOCGABS(ABS_X), {value=0, minimum=0, ...}) = 0 ioctl(18, EVIOCGABS(ABS_Y), {value=0, minimum=0, ...}) = 0 ioctl(18, EVIOCGABS(ABS_RZ), {value=0, minimum=0, ...}) = 0 ioctl(18, EVIOCGABS(ABS_THROTTLE), {value=0, minimum=0, ...}) = 0 ioctl(18, EVIOCGABS(ABS_HAT0X), {value=0, minimum=4294967295, ...}) = 0 ioctl(18, EVIOCGABS(ABS_HAT0Y), {value=0, minimum=4294967295, ...}) = 0 ioctl(18, EVIOCGKEY(96), [ 0 ]) = 96 recvmsg(6, 0x7ffe41840000, 0) = -1 EAGAIN (Resource temporarily unavailable) select(10, [9], NULL, NULL, {0, 0}) = 0 (Timeout) select(10, [9], NULL, NULL, {0, 0}) = 0 (Timeout) ioctl(12, EVIOCGABS(ABS_X), {value=124, minimum=0, ...}) = 0 ioctl(12, EVIOCGABS(ABS_Y), {value=138, minimum=0, ...}) = 0 ioctl(12, EVIOCGABS(ABS_Z), {value=10, minimum=0, ...}) = 0 ioctl(12, EVIOCGABS(ABS_HAT0X), {value=0, minimum=4294967295, ...}) = 0 ioctl(12, EVIOCGABS(ABS_HAT0Y), {value=0, minimum=4294967295, ...}) = 0 ioctl(12, EVIOCGKEY(96), [ 0 ]) = 96 ioctl(18, EVIOCGABS(ABS_X), {value=0, minimum=0, ...}) = 0 ioctl(18, EVIOCGABS(ABS_Y), {value=0, minimum=0, ...}) = 0 ioctl(18, EVIOCGABS(ABS_RZ), {value=0, minimum=0, ...}) = 0 ioctl(18, EVIOCGABS(ABS_THROTTLE), {value=0, minimum=0, ...}) = 0 ioctl(18, EVIOCGABS(ABS_HAT0X), {value=0, minimum=4294967295, ...}) = 0 ioctl(18, EVIOCGABS(ABS_HAT0Y), {value=0, minimum=4294967295, ...}) = 0 ioctl(18, EVIOCGKEY(96), [ 0 ]) = 96 nanosleep({0, 33000000}, 0x7ffe41840250) = 0 futex(0x31ca380, FUTEX_WAIT_PRIVATE, 2, NULL <unfinished ...> +++ killed by SIGSEGV (core dumped) +++ war thunder: line 3: 3826 Segmentation fault (core dumped) MESA_GL_VERSION_OVERRIDE=4.1COMPAT strace ./aces
warning: Could not load shared library symbols for linux-vdso.so.1. Do you need "set solib-search-path" or "set sysroot"? [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/libthread_db.so.1". Core was generated by `./aces'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007f3851f5bde6 in ?? () from /usr/lib/xorg/modules/dri/radeonsi_dri.so [Current thread is 1 (Thread 0x7f384eccc700 (LWP 3923))]
https://bugs.freedesktop.org/show_bug.cgi?id=92850
--- Comment #1 from Nicolai Hähnle nhaehnle@gmail.com --- Hi, thanks for the report. Which version of Mesa are you using? Could you please provide a backtrace with debug symbols installed?
I notice you're using a MESA_GL_VERSION_OVERRIDE. Might the crash be related to that? Is apitrace able to produce useful traces in a crash like this for reproduction?
https://bugs.freedesktop.org/show_bug.cgi?id=92850
--- Comment #2 from bellamorte42@gmail.com --- Well, as I said apitrace didn't yield any error messages. I'm using mesa git from a few days ago. I've used probably 5 versions of mesa git with similar results. The 4.1COMPAT is required to work around the devs shoddy coding resulting in a black screen (I think it's due to using EXT_dsa instead of ARB as another bug report stated). Other people have been using Mesa apparently without crashing but with old Ubuntu and the 4.1COMPAT. I don't know how to provide a backtrace with debugging symbols, I'm still a little new to this.
https://bugs.freedesktop.org/show_bug.cgi?id=92850
--- Comment #3 from Nicolai Hähnle nhaehnle@gmail.com --- Backtrace: When running in gdb, enter the "bt" command after the crash. That will give you the backtrace.
Debug symbols: If you compile Mesa yourself, I believe running the configure script with --enable-debug in addition to the other usual options and recompiling everything should do the trick. If you're using some distribution package, there should usually be packages with a -dbg name that will install the required debug symbols.
Apitrace: Even if apitrace does not give you an error message, the trace itself (i.e. the generated .trace file) could be useful for reproducing the issue. Zip it (xz is popular) and upload it somewhere if possible.
Also, please provide the full output of glxinfo and dmesg for bugs like this.
_However_, even with all that said, it is entirely possible that the version override is messing something up. If other people have been using Mesa with the override successfully, they might have other hardware and just been lucky enough to be using a driver that happens to work with the override. Generally, using such overrides pretty much means all bets are off.
https://bugs.freedesktop.org/show_bug.cgi?id=92850
--- Comment #4 from higuita@gmx.net --- i too play war thunder but i'm not having problems with radeon mesa support.
I'm using mesa 11.0.4 on a AMD A10 APU, on slackwre64-current (so it was recent packages) and also using the 4.1COMPAT flag.
Please notice that i'm running the normal client, if you checked the "work-in-progress" flag on the laucher, you will get the new 64bit version of the game that AFAIK, still have problems/bugs.
https://bugs.freedesktop.org/show_bug.cgi?id=92850
--- Comment #5 from bellamorte42@gmail.com --- I've tried both versions of the client and have been having the issue for a while (before the new 64bit client was an option).
https://bugs.freedesktop.org/show_bug.cgi?id=92850
--- Comment #6 from bellamorte42@gmail.com --- Created attachment 119564 --> https://bugs.freedesktop.org/attachment.cgi?id=119564&action=edit backtrace
Here's the backtrace.
https://bugs.freedesktop.org/show_bug.cgi?id=92850
--- Comment #7 from bellamorte42@gmail.com --- Where should I upload the full trace to?
https://bugs.freedesktop.org/show_bug.cgi?id=92850
--- Comment #8 from Nicolai Hähnle nhaehnle@gmail.com --- higuita, thanks for the heads up!
bellamorte, the backtrace still has no debug symbols. Also, you're missing glxinfo and dmesg outputs.
https://bugs.freedesktop.org/show_bug.cgi?id=92850
--- Comment #9 from bellamorte42@gmail.com --- Created attachment 119593 --> https://bugs.freedesktop.org/attachment.cgi?id=119593&action=edit glxinfo
https://bugs.freedesktop.org/show_bug.cgi?id=92850
--- Comment #10 from bellamorte42@gmail.com --- Created attachment 119594 --> https://bugs.freedesktop.org/attachment.cgi?id=119594&action=edit dmesg
https://bugs.freedesktop.org/show_bug.cgi?id=92850
--- Comment #11 from bellamorte42@gmail.com --- I rebuilt mesa as instructed (--enable-debug) and that's what I got.
https://bugs.freedesktop.org/show_bug.cgi?id=92850
bellamorte42@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #119564|0 |1 is obsolete| |
--- Comment #12 from bellamorte42@gmail.com --- Created attachment 120003 --> https://bugs.freedesktop.org/attachment.cgi?id=120003&action=edit backtrace
Figured out how to keep my debugging symbols. New backtrace.
https://bugs.freedesktop.org/show_bug.cgi?id=92850
--- Comment #13 from Nicolai Hähnle nhaehnle@gmail.com --- Thanks! The crash happens in the Gallium state-tracker, i.e. hardware-independent code. About that apitrace: perhaps you can upload it somewhere like Dropbox or Google Drive?
https://bugs.freedesktop.org/show_bug.cgi?id=92850
--- Comment #14 from bellamorte42@gmail.com --- Link to apitrace https://www.dropbox.com/s/wxoywdk1pa0el2p/aces.7.trace?dl=0
https://bugs.freedesktop.org/show_bug.cgi?id=92850
--- Comment #15 from Nicolai Hähnle nhaehnle@gmail.com --- When I run the trace, all I get is a black window with occasional flickers of garbage drawn, and finally a clean exit at the end of the trace. I cannot reproduce the crash you've experienced.
https://bugs.freedesktop.org/show_bug.cgi?id=92850
--- Comment #16 from bellamorte42@gmail.com --- Created attachment 120092 --> https://bugs.freedesktop.org/attachment.cgi?id=120092&action=edit build
https://bugs.freedesktop.org/show_bug.cgi?id=92850
--- Comment #17 from bellamorte42@gmail.com --- Well, here's what I'm building mesa with.
https://bugs.freedesktop.org/show_bug.cgi?id=92850
--- Comment #18 from bellamorte42@gmail.com --- This is the dmesg I'm getting when I replay the trace.
[Nov24 12:41] traps: apitrace[4460] general protection ip:443625 sp:7ffe34202140 error:0 in apitrace[400000+66000]
https://bugs.freedesktop.org/show_bug.cgi?id=92850
--- Comment #19 from Nicolai Hähnle nhaehnle@gmail.com --- Those config options are fine. Which version of Mesa are you building (what does git show say?)
Do you consistently get the same crash and backtrace even after doing a complete rebuild of Mesa?
https://bugs.freedesktop.org/show_bug.cgi?id=92850
--- Comment #20 from bellamorte42@gmail.com --- This has been happening with every git version from mesa 11. I don't know if this bug existed before then. I don't know if the backtraces are the same tbh.
https://bugs.freedesktop.org/show_bug.cgi?id=92850
--- Comment #21 from bellamorte42@gmail.com --- Created attachment 120184 --> https://bugs.freedesktop.org/attachment.cgi?id=120184&action=edit backtrace latest git
Just compiled mesa again and generated a new backtrace. It looks the same to me.
https://bugs.freedesktop.org/show_bug.cgi?id=92850
--- Comment #22 from bellamorte42@gmail.com --- Oh, I caught an error in the terminal during the crash.
context mis-match in pipe_sampler_view_release()
https://bugs.freedesktop.org/show_bug.cgi?id=92850
haro41@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |haro41@gmx.de
--- Comment #23 from haro41@gmx.de --- I have a similiar segmentation fault error in game 'war thunder' (mesa 11.2-devel radeonsi). Unlike the original reporter, i dont use/need any GL version override.
If i configure latest git mesa with '--enable-debug', i get this additional output at console, before the crash:
'context mis-match in pipe_sampler_view_release()'
glxinfo |grep OpenGL:
OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD PITCAIRN (DRM 2.43.0, LLVM 3.7.0) OpenGL core profile version string: 4.1 (Core Profile) Mesa 11.2.0-devel (git-241f15a) OpenGL core profile shading language version string: 4.10 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL core profile extensions: OpenGL version string: 3.0 Mesa 11.2.0-devel (git-241f15a) OpenGL shading language version string: 1.30 OpenGL context flags: (none) OpenGL extensions: OpenGL ES profile version string: OpenGL ES 3.0 Mesa 11.2.0-devel (git-241f15a) OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00 OpenGL ES profile extensions:
If additinal infos are needed please let me know.
https://bugs.freedesktop.org/show_bug.cgi?id=92850
--- Comment #24 from bellamorte42@gmail.com --- MESA_GL_VERSION_OVERRIDE=4.1COMPAT no longer required to avoid a black screen.
https://bugs.freedesktop.org/show_bug.cgi?id=92850
--- Comment #25 from haro41@gmx.de --- @bellamorte42,
i am meanwhile able to run WT by the following workaround:
Do always a 'make clean' before autogen.sh configuring, to avoid some strange results.
append --enable-debug CFLAGS=-O0 CXXFLAGS=O0 to your custom autogen.sh params.
Do a make followed by installation as usual.
This works for me. Obviously is there something in state tracker that doesn't like to much compiler optimization.
(BTW: Even if WT linux 'launcher' works again, there is a new bug inside. Just use 'updater' to ensure you get [1.53.8.34])
https://bugs.freedesktop.org/show_bug.cgi?id=92850
--- Comment #26 from haro41@gmx.de --- sorry made a typo:
append: --enable-debug CFLAGS=-O0 CXXFLAGS=-O0
https://bugs.freedesktop.org/show_bug.cgi?id=92850
--- Comment #27 from bellamorte42@gmail.com --- Yep, that seems to work. It's odd that it's the only game I have that has that problem with context mis-match in pipe_sampler_view_release(). Doing some additional tests to make sure.
https://bugs.freedesktop.org/show_bug.cgi?id=92850
Michel Dänzer michel@daenzer.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|Drivers/Gallium/radeonsi |Mesa core Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org |org QA Contact|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org |org
--- Comment #28 from Michel Dänzer michel@daenzer.net --- Sounds like some code in st_glsl_to_tgsi.cpp is getting miscompiled with optimization. Is compiling only that file with -O0 enough to avoid the problem?
What optimization flags are being used normally?
dri-devel@lists.freedesktop.org