Summary: | Civilization V + Wine = Bug | ||
---|---|---|---|
Product: | Mesa | Reporter: | gabrielbyrnei |
Component: | Mesa core | Assignee: | Jose Fonseca <jfonseca> |
Status: | RESOLVED DUPLICATE | QA Contact: | |
Severity: | normal | ||
Priority: | medium | CC: | brianp, burkett.andrew, hverbeet, jfonseca, marcus, zajec5 |
Version: | 7.11 | ||
Hardware: | x86-64 (AMD64) | ||
OS: | Linux (All) | ||
See Also: |
http://bugs.winehq.org/show_bug.cgi?id=30052 https://bugs.freedesktop.org/show_bug.cgi?id=44466 https://bugzilla.novell.com/show_bug.cgi?id=747333 http://llvm.org/bugs/show_bug.cgi?id=12151 |
||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: |
Xorg log
valgrind report using clang built mesa 8.0.1 valgrind report using gcc built mesa 8.0.1 (and clang built llvm) patch w/ workaround attempt |
Description
gabrielbyrnei
2011-10-14 07:19:21 UTC
Only LLVM in the backtrace, reassigning to core for now. Maybe the environment variable DRAW_USE_LLVM=0 could work around the problem, but I'm not sure which Wine process you'd need to set that for... I can't see how this would fail at this point. It seems like a generic memory corruption... Created attachment 53862 [details]
Xorg log
I have the same bug with all the games I tried with wine since I have updated my Opensuse Tumbleweed to 12.1. I put in attachment the Xorg.0.log in order to have the version of the X server and the drivers. Without the variable I have the crash, and with the variable it works fine: guest@linux-30so:/essai/drive_c/Program Files/Microids/Egypte 3> unset DRAW_USE_LLVM guest@linux-30so:/essai/drive_c/Program Files/Microids/Egypte 3> ~/wine-git/wine Game.exe fixme:ntoskrnl:KeInitializeTimerEx stub: 0x110fe8 0 fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 10000 channels, pretending there's only 2 channels fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 10000 channels, pretending there's only 2 channels fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 10000 channels, pretending there's only 2 channels fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 10000 channels, pretending there's only 2 channels fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 10000 channels, pretending there's only 2 channels fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 10000 channels, pretending there's only 2 channels fixme:winmm:MXD_GetControlDetails What should the sw-side mixer controls map to? wine: Unhandled page fault on read access to 0xffffffff at address 0x7d44b87d (thread 0009), starting debugger... Unhandled exception: page fault on read access to 0xffffffff in 32-bit code (0x7d44b87d). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:7d44b87d ESP:0033ea38 EBP:7d73aff4 EFLAGS:00210246( R- -- I Z- -P- ) EAX:7c5fff2c EBX:7c4cf8d0 ECX:7c5f5b18 EDX:00000000 ESI:00000000 EDI:7c4cf8a8 Stack dump: 0x0033ea38: 7c5f5b18 00000000 0033ea6c 7c600fcc 0x0033ea48: 7d73aff4 7c600008 7c5f5b08 7c4bfb68 0x0033ea58: b75dbff4 b74e2df3 7d4b5e95 7c5f5a98 0x0033ea68: b75dbff4 7c5f5a98 00000000 00000020 0x0033ea78: 00000020 7d6271ef 00000020 b74e6ee1 0x0033ea88: 00000020 7ca76d05 7c625770 7caa8ff4 Backtrace: =>0 0x7d44b87d _ZN4llvm12PassRegistry21registerAnalysisGroupEPKvS2_RNS_8PassInfoEbb+0x2dd() in r600_dri.so (0x7d73aff4) 1 0x7d322d1b _ZN4llvm18initializeNoAAPassERNS_12PassRegistryE+0x11a() in r600_dri.so (0x7d77213c) 2 0x7d2da568 _ZN4llvm36initializeAliasAnalysisAnalysisGroupERNS_12PassRegistryE+0x47() in r600_dri.so (0x7c4c02c8) 3 0x7d36c3cb _ZN4llvm36initializeTypeBasedAliasAnalysisPassERNS_12PassRegistryE+0x4a() in r600_dri.so (0x7c4c02c8) 4 0x7d36c54e _ZN4llvm32createTypeBasedAliasAnalysisPassEv+0x6d() in r600_dri.so (0x7c5f5cc8) 5 0x7d0bce44 _ZN4llvm17LLVMTargetMachine22addCommonCodeGenPassesERNS_15PassManagerBaseENS_10CodeGenOpt5LevelEbRPNS_9MCContextE+0x23() in r600_dri.so (0x7c5f5cc8) 6 0x7d0bd76c _ZN4llvm17LLVMTargetMachine26addPassesToEmitMachineCodeERNS_15PassManagerBaseERNS_14JITCodeEmitterENS_10CodeGenOpt5LevelEb+0x4b() in r600_dri.so (0x7c5f5cc8) 7 0x7ce44a71 _ZN4llvm3JITC1EPNS_6ModuleERNS_13TargetMachineERNS_13TargetJITInfoEPNS_16JITMemoryManagerENS_10CodeGenOpt5LevelEb+0x210() in r600_dri.so (0x7c5f5cc8) 8 0x7ce4466f _ZN4llvm3JIT9createJITEPNS_6ModuleEPSsPNS_16JITMemoryManagerENS_10CodeGenOpt5LevelEbPNS_13TargetMachineE+0x8e() in r600_dri.so (0x7c6255f4) 9 0x7ce59d1a _ZN4llvm13EngineBuilder6createEv+0x159() in r600_dri.so (0x00000000) 0x7d44b87d _ZN4llvm12PassRegistry21registerAnalysisGroupEPKvS2_RNS_8PassInfoEbb+0x2dd in r600_dri.so: With the variable guest@linux-30so:/essai/drive_c/Program Files/Microids/Egypte 3> DRAW_USE_LLVM=0 ~/wine-git/wine Game.exe fixme:ntoskrnl:KeInitializeTimerEx stub: 0x110fe8 0 fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 10000 channels, pretending there's only 2 channels fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 10000 channels, pretending there's only 2 channels fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 10000 channels, pretending there's only 2 channels fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 10000 channels, pretending there's only 2 channels fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 10000 channels, pretending there's only 2 channels fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 10000 channels, pretending there's only 2 channels fixme:winmm:MXD_GetControlDetails What should the sw-side mixer controls map to? fixme:win:EnumDisplayDevicesW ((null),0,0x33f714,0x00000000), stub! fixme:d3d:swapchain_init Add OpenGL context recreation support to context_validate_onscreen_formats fixme:d3d:wined3d_device_decref Device released with resources still bound, acceptable but unexpected. fixme:d3d:wined3d_device_decref Leftover resource 0x12fe58 with type WINED3DRTYPE_SURFACE (0x1). fixme:win:EnumDisplayDevicesW ((null),0,0x33f710,0x00000000), stub! fixme:ddraw:DirectDrawEnumerateExA flags 0x00000007 not handled fixme:win:EnumDisplayDevicesW ((null),0,0x33e79c,0x00000000), stub! fixme:win:EnumDisplayDevicesW ((null),0,0x33ebd4,0x00000000), stub! fixme:d3d:swapchain_init Add OpenGL context recreation support to context_validate_onscreen_formats If anyone has any idea on what I could do to give more information, more trace, I will try my best. For what it's worth, all the cases of this bug that I've seen were on SUSE. I suppose this could be a packaging issue. I opened suse bug: https://bugzilla.novell.com/show_bug.cgi?id=747333 if you could install Mesa-debuginfo and Mesa-debugsource and get the baclktrace again? I'm also openSUSE 12.1 user and I experience the same problem, it's just Diablo II instead of Civilization in my case. When I let Mesa use LLVM, Diablo II crashes before even displaying anything, it was reported at Wine bugzilla: http://bugs.winehq.org/show_bug.cgi?id=14348 Workaround is to use DRAW_USE_LLVM=0. I suspected some Mesa packaging issue, so I've switched to Mesa git and self-compiled it, but this didn't help. Then I decided to downgrade LLVM. I've compiled & installed version 2.8 (instead of 3.0 provided by openSUSE) and then recompiled Mesa (same commit and config). It worked! It seems there is some problem when using LLVM 3.0 with Wine. I guess we should try to find the regression in LLVM, however it will take a lot of time (llvm doesn't use git - no "git bisect" and I've to recompile Mesa every time I recompile llvm). Note that https://bugs.freedesktop.org/show_bug.cgi?id=44466 / https://bugs.archlinux.org/task/27645 looks somewhat similar, although with a different backtrace and distribution. A comment in the Arch bug claims that compiling Mesa with -O1 instead of the default -O2 makes the bug go away. (In reply to comment #7) > I'm also openSUSE 12.1 user and I experience the same problem, it's just Diablo > II instead of Civilization in my case. When I let Mesa use LLVM, Diablo II > crashes before even displaying anything, it was reported at Wine bugzilla: > http://bugs.winehq.org/show_bug.cgi?id=14348 > Workaround is to use DRAW_USE_LLVM=0. > > I suspected some Mesa packaging issue, so I've switched to Mesa git and > self-compiled it, but this didn't help. > > Then I decided to downgrade LLVM. I've compiled & installed version 2.8 > (instead of 3.0 provided by openSUSE) and then recompiled Mesa (same commit and > config). It worked! > > It seems there is some problem when using LLVM 3.0 with Wine. I guess we should > try to find the regression in LLVM, however it will take a lot of time (llvm > doesn't use git - no "git bisect" and I've to recompile Mesa every time I > recompile llvm). There is a LLVM git mirror: http://llvm.org/git/llvm.git Is it possible that wine is doing OpenGL rendering from multiple threads? LLVM is not very thread safe at the moment. Brian reminded me that this could be related to the LLVM 3.0's elimination of LLVMInvalidateStructLayout() A good thing to try is to replace all LLVMStructCreateNamed() calls with ordinary LLVMStructType(), as we don't use recursive types. I'll provide a patch for that later on. Hmm, I'm mixing u(In reply to comment #10) > Brian reminded me that this could be related to the LLVM 3.0's elimination of > LLVMInvalidateStructLayout() > > A good thing to try is to replace all LLVMStructCreateNamed() calls with > ordinary LLVMStructType(), as we don't use recursive types. > > I'll provide a patch for that later on. I'm mixing up bugs. This comment only applies to bug 44466. This one seems different, and probably the best thing to do is to bisect. (In reply to comment #9) > Is it possible that wine is doing OpenGL rendering from multiple threads? LLVM > is not very thread safe at the moment. We do use GL from multiple threads, depending on the application, but typically that means rendering from one thread and doing resource updates from others. I confirm this bug, i try build mesa-git with standart static llvm-3.0 from opensuse and all DirectX games is unable to start. Now I use mesa-git and llvm-svn shared and do not have problems with DirectX games. I've bisected LLVM to find the first bad commit. This resulted (in twice confirmed) commit: commit 42634836e999dfcb59f1f5ea50dfd33442be4b9a Author: Eric Christopher <echristo@apple.com> Date: Fri Sep 16 20:36:16 2011 +0000 Have the llvm configure process look for clang, then llvm-gcc, and then gcc on all platforms. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@139934 91177308-0d34-0410-b5e6-96231b3b80d8 I've reported issue on the llvm bugzilla: http://llvm.org/bugs/show_bug.cgi?id=12151 Not sure what else I can do to help fixing this bug. Any more info you need from me? Does that mean it ends up using Clang to compile llvm and then linking it with gcc compiled Mesa? I think it is the case. Opensuse build llvm with a 3 stage process : At stage 1, it builds llvm + clang with gcc, At stage 2 it builds llvm + clang with the gcc created clang, At stage 3 it rebuilds llvm + clang with the clang created clang. IMHO before the incriminated commit the configure script didn't properly pick clang in the PATH and then the 3 stages were redundant, that's why it was working with LLVM 2.8 from opensuse. However it's weird that it does only affect opensuse. (In reply to comment #16) > However it's weird that it does only affect opensuse. There could be several reasons, really. I'm not sure what versions of everything most distros are currently shipping, but you don't hit this if you built r600g without llvm or didn't link with llvm 3, and probably building llvm with gcc instead of clang will avoid it as well. I still have a crash with a clang built Mesa. However the backtrace is different : Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:7b0a8cef ESP:0033e698 EBP:0033e700 EFLAGS:00210212( R- -- I -A- - ) EAX:7c4a8358 EBX:7bbefff4 ECX:7bbefff4 EDX:7c4a83a8 ESI:7bbefff4 EDI:7bbd45bc Stack dump: 0x0033e698: 00001302 00172bd8 00000000 00000000 0x0033e6a8: 00000000 00000000 00110014 00000000 0x0033e6b8: 00172bf8 00000001 7c4a8358 00000000 0x0033e6c8: b7740ff4 0000001c b77423c0 000c54c8 0x0033e6d8: b764cd09 b764904e 00172bd8 00000005 0x0033e6e8: 7c33ab38 b77423c0 0000001c 7bbefff4 Backtrace: fixme:dbghelp_dwarf:compute_location Unhandled attr op: d4 fixme:dbghelp_dwarf:compute_location Only supporting one breg (edi/24 -> st5/133) fixme:dbghelp_dwarf:compute_location Unhandled attr op: 1 =>0 0x7b0a8cef dri_create_context+0x2f(api=<is not available>, visual=<has been optimized away by compiler>, cPriv=<is not available>, major_version=<is not available>, minor_version=<is not available>, flags=0, error=0x0(nil), sharedContextPrivate=0x0(nil)) [/home/vlj/mesa-8.0.1/src/gallium/state_trackers/dri/sw/dri_context.c:68] in swrast_dri.so (0x0033e700) fixme:dbghelp_dwarf:compute_location Unhandled attr op: 0 fixme:dbghelp_dwarf:compute_location Unhandled attr op: 0 fixme:dbghelp_dwarf:compute_location Unhandled attr op: 0 1 0x7b0a59bf driCreateContextAttribs+0x10e(screen=<has been optimized away by compiler>, api=<has been optimized away by compiler>, config=<has been optimized away by compiler>, shared=<is not available>, num_attribs=<internal error>, attribs=<internal error>, error=<has been optimized away by compiler>, data=<has been optimized away by compiler>) [/home/vlj/mesa-8.0.1/src/gallium/targets/dri-swrast/../../../../src/mesa/drivers/dri/common/drisw_util.c:178] in swrast_dri.so (0x0033e750) fixme:dbghelp_dwarf:compute_location Unhandled attr op: 0 fixme:dbghelp_dwarf:compute_location Unhandled attr op: 0 fixme:dbghelp_dwarf:compute_location Unhandled attr op: 0 fixme:dbghelp_dwarf:compute_location Unhandled attr op: 9e 2 0x7b0a5572 driCreateNewContext+0x51(psp=0x33e758, config=0x33e758, shared=0x33e758, data=0x33e758) [/home/vlj/mesa-8.0.1/src/gallium/targets/dri-swrast/../../../../src/mesa/drivers/dri/common/drisw_util.c:195] in swrast_dri.so (0x0033e780) fixme:dbghelp_dwarf:compute_location Unhandled attr op: c8 3 0x7d4ddc33 drisw_create_context+0xd2(base=<is not available>, config_base=<has been optimized away by compiler>, shareList=<internal error>, renderType=0x33e788) [/home/vlj/mesa-8.0.1/src/glx/drisw_glx.c:404] in libgl.so.1 (0x0033e7b0) fixme:dbghelp_dwarf:compute_location Unhandled attr op: c7 fixme:dbghelp_dwarf:compute_location Unhandled attr op: 0 4 0x7d4b8453 CreateContext+0x92(dpy=<is not available>, generic_id=<internal error>, config=<is not available>, shareList_user=<is not available>, allowDirect=<is not available>, code=<is not available>, renderType=<has been optimized away by compiler>, screen=<is not available>) [/home/vlj/mesa-8.0.1/src/glx/glxcmds.c:276] in libgl.so.1 (0x0033e7f0) fixme:dbghelp_dwarf:compute_location Unhandled attr op: d1 5 0x7d4b83ac glXCreateContext+0xcb(dpy=<internal error>, vis=<is not available>, shareList=<has been optimized away by compiler>, allowDirect=<has been optimized away by compiler>) [/home/vlj/mesa-8.0.1/src/glx/glxcmds.c:381] in libgl.so.1 (0x0033e840) 6 0x7df03db2 in winex11 (+0x43db1) (0x00000015) 7 0x7df08105 in winex11 (+0x48104) (0x00000015) 8 0x7e9490a2 wglCreateContext+0x61() in gdi32 (0x01d04068) 9 0x7d540bab in wined3d (+0x30baa) (0x01d04068) 10 0x7d5e3ace in wined3d (+0xd3acd) (0x00000048) 11 0x7d5e401f wined3d_swapchain_create+0x7e() in wined3d (0x0033ed98) 12 0x7d65997f in ddraw (+0x997e) (0x0033ec40) 13 0x7d551de8 wined3d_device_init_3d+0x237() in wined3d (0x0016a188) 14 0x7d65cbdd in ddraw (+0xcbdc) (0x00133278) 15 0x7d65df89 in ddraw (+0xdf88) (0x00000000) 0x7b0a8cef dri_create_context+0x2f [/home/vlj/mesa-8.0.1/src/gallium/state_trackers/dri/sw/dri_context.c:68] in swrast_dri.so: 68 memset(&attribs, 0, sizeof(attribs)); Clang is more strict about C compliance (I experienced crashes because of a uninitialized pointer that passed with gcc) so this output should be taken with a grain of salt as it might be unrelated to the current bug. I'm attaching valgrinds report with clang built mesa and gcc built mesa. Created attachment 57892 [details]
valgrind report using clang built mesa 8.0.1
Created attachment 57893 [details]
valgrind report using gcc built mesa 8.0.1 (and clang built llvm)
(In reply to comment #19) > Created attachment 57892 [details] > valgrind report using clang built mesa 8.0.1 How did you compile mesa with clang? Did you set "CC=clang" and "CXX=clang++"? I am just wondering because I get errors in core parts: http://llvm.org/bugs/attachment.cgi?id=8140 (In reply to comment #10) > Brian reminded me that this could be related to the LLVM 3.0's elimination of > LLVMInvalidateStructLayout() > > A good thing to try is to replace all LLVMStructCreateNamed() calls with > ordinary LLVMStructType(), as we don't use recursive types. > > I'll provide a patch for that later on. Any news about this patch ? Created attachment 61717 [details] [review] patch w/ workaround attempt Please re-try with latest master which includes commit 9af1ba565dfd5cef9ee938bb7c04767d14878fbf Author: José Fonseca <jfonseca@vmware.com> Date: Wed May 16 15:00:23 2012 +0100 draw,llvmpipe: Avoid named struct types on LLVM 3.0 and later. Starting with LLVM 3.0, named structures are meant not for debugging, but for recursive data types, previously also known as opaque types. The recursive nature of these types leads to several memory management difficulties. Given that we don't actually need recursive types, avoid them altogether. This is an attempt to address fdo bugs 41791 and 44466. The issue is somewhat random so there's no easy way to check how effective this is. And if that doesn't work, try the attached path w/ another workaround attempt. |
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.