Created attachment 59983 [details] furmark crash in wine, mesa compiled with CFLAGS="-O2" So I had this bug across some gcc versions and mesa versions (since about the time llvm 3.0 came out) and I figured I should probably report it since it didn't go away until now. I'm on a notebook with Redwood, HD 6550M with current libdrm git, mesa git, xf86-video-ati git, gcc (GCC) 4.7.0 20120407. The problem is this: If I compile mesa with CFLAGS="-O2" I immedately get a crash in all (32 bit) 3D applications/games I have tested in wine (before even displaying the main window). An example is furmark, see attachment. It tries to access an apparently invalid address at 0x7cae670a and at this position there is r600_dri.so. If I compile mesa with CFLAGS="-O1" (or "-Os") this does not happen. In fact, if I install mesa compiled with "-O2" and only replace /usr/lib32/xorg/modules/dri/r600_dri.so with one from a mesa build compiled with "-O1" it also works. Another curiosity is that when I do this: ~/.wine/drive_c/FurMark % WINEDEBUG=+all wine FurMark.exe &> /dev/null then I get the same crash, as expected. But when I do this: ~/.wine/drive_c/FurMark % WINEDEBUG=+all wine FurMark.exe &> furmarkdebug.txt it starts fine to the main window. Only later, when clicking on benchmark, I get a very similar crash to the above. Native 32 bit games work fine with an "-O2" compiled mesa. Internal wine programs like regedit, explorer or wine internet explorer work also. If you can tell me how I can obtain more information about this obscure bug I will gladly do.
It looks similar to what I'm experiencing over here. I'm also available to help. Christoph, was this problem reported under Arch?
(In reply to comment #1) > It looks similar to what I'm experiencing over here. I'm also available to > help. Christoph, was this problem reported under Arch? I'm on archlinux, yes. I believe there were several problems at the same time. 1) https://bugs.archlinux.org/task/27645 linked to https://bugs.freedesktop.org/show_bug.cgi?id=44466 Which is NOT the issue I have now. 2) https://bugs.archlinux.org/task/28527 links to http://bugs.winehq.org/show_bug.cgi?id=29982 which then links back to 1) and http://llvm.org/bugs/show_bug.cgi?id=12151 and https://bugs.freedesktop.org/show_bug.cgi?id=41791 and https://bugzilla.novell.com/show_bug.cgi?id=747333 They could all be related but nobody seems to know anything for sure. It often comes up that DRAW_USE_LLVM=0 may be helping but for me it does definitely not. Some time ago I even tried compiling mesa with --disable-gallium-llvm didn't make a difference. So maybe these are too different issues that just look similar.
Does it work with -O2 -fno-strict-aliasing? The Mesa tree is known not to be strict aliasing clean. If that's not it, maybe you can isolate the specific optimization enabled by -O2 but not -O1 which triggers the crash. I suspect this bug may be invalid anyway though: you shouldn't set CFLAGS directly but use OPT_FLAGS and friends.
(In reply to comment #3) > Does it work with -O2 -fno-strict-aliasing? The Mesa tree is known not to be > strict aliasing clean. If that's not it, maybe you can isolate the specific > optimization enabled by -O2 but not -O1 which triggers the crash. > > I suspect this bug may be invalid anyway though: you shouldn't set CFLAGS > directly but use OPT_FLAGS and friends. Well, I set it to -O2 for testing. Archlinux does set the CFLAGS so if this is wrong, Archlinux is doing it wrong? Archlinux's default CFLAGS are by the way: CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2" (I personally use -march=native) So I tried setting my CFLAGS to CFLAGS="$CFLAGS -fno-strict-aliasing". Compiling lib32 mesa looks like this now: gcc -m32 -c -I. -I../../../src/gallium/include -I../../../src/gallium/auxiliary -I../../../src/gallium/drivers -march=native -fomit-frame-pointer -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -fno-strict-aliasing -Wall -std=c99 -Werror=implicit-function-declaration -Werror=missing-prototypes -fno-strict-aliasing -fno-builtin-memcmp -m32 -march=native -fomit-frame-pointer -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -fno-strict-aliasing -fPIC -m32 -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DTEXTURE_FLOAT_ENABLED -DHAVE_POSIX_MEMALIGN -DIN_DRI_DRIVER -DUSE_XCB -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DGLX_USE_TLS -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DHAVE_ALIAS -DHAVE_MINCORE -DHAVE_LIBUDEV -DHAVE_XEXTPROTO_71 -D__STDC_CONSTANT_MACROS -DHAVE_LLVM=0x0300 -fvisibility=hidden -I/usr/include -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS util/u_rect.c -o util/u_rect.o -fno-strict-aliasing does not fix the wine crashes.
*** This bug has been marked as a duplicate of bug 48351 ***
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.