Created attachment 44162 [details] wine output I have a similar bug to this one at the winehq bugtracker, but I think it pertains more to mesa now. As the title states, counter strike source crashes at start up for me. A full log of wine's output will be attached. I think this bug is related to the r600 gallium driver because the game does load, play, and display with gallium's softpipe driving it, although it is painfully slow. Also I believe the critical section of the log is the following: trace:dbghelp:get_wine_loader_name returning L"wine" trace:dbghelp:elf_load_file Processing elf file 'L"wine"' at 00000000 trace:dbghelp:elf_load_file Processing elf file 'L".//wine"' at 00000000 trace:dbghelp:elf_load_file Processing elf file 'L"/home/bpaterni/bin/wine"' at 00000000 trace:dbghelp:elf_load_file Processing elf file 'L"/usr/local/bin/wine"' at 00000000 trace:dbghelp:SymFromName (0xffffffff, libwine.so.1!__wine_main_environ, 0xffed654) trace:dbghelp:SymFromName null process fixme:dbghelp:elf_search_auxv can't find symbol in module Inconsistency detected by ld.so: dl-deps.c: 626: _dl_map_object_deps: Assertion `nlist > 1' failed! I've looked through wine's source and elf_search_auxv is being called from MiniDumpWriteDump in dlls/dbghelp/minidump.c which apparently is being called from within steam/counter strike. Because of this, I'm not sure how to proceed in debugging since steam/counter strike are both closed. Hopefully someone here has a clever idea on getting to the bottom of this... environment: Linux kernel (git master, linus' tree -- although I have tried drm-next + s3tc, same result) Debian unstable/experimental mesa (git master @ f95892b46a9a6b5d90437998ef9a3babd55e9c7d) wine (git master)
I'm able to at least run the CS:S stress tests with current git versions of Wine and r600g on Evergreen, although rendering correctness and performance still have some way to go. The "Inconsistency detected by ld.so: ..." line in the log looks suspicious, although it's unclear to me if it's related to the cause of the crash. Normally when source engine games crash they write a minidump in "dumps" in your Steam directory, you can open those with winedbg to get a backtrace. The dbghelp FIXME and ld.so message make me suspect it might have failed to produce a usable minidump this time though.
Hmm, I have a similar problem will all Steam games (which are mostly HL2-engine based). After starting a game, when the loading process finishes, the game immediately exits. @Henri: Does starting a new game in HL2 work for you? Maybe also with forcing dxlevel 8.
(In reply to comment #2) > @Henri: Does starting a new game in HL2 work for you? Maybe also with forcing > dxlevel 8. It does, though I haven't tried with dxlevel 8. If you're running into winehq bug 24064 that's a different issue though.
Yes, I was hitting the GameOverlayRenderer bug. However after hotfixing this, dxlevel 81 is still the farthest I can go. All DX9 render paths either cause GPu resets or crash the kernel. @Henri: Which dxlevel have you selected (what does mat_dxlevel say)?
(In reply to comment #4) > Yes, I was hitting the GameOverlayRenderer bug. However after hotfixing this, > dxlevel 81 is still the farthest I can go. All DX9 render paths either cause > GPu resets or crash the kernel. > > @Henri: Which dxlevel have you selected (what does mat_dxlevel say)? I didn't explicitly select anything, but mat_dxlevel is at 95. For reference, what kernel and hardware are you using?
Radeon HD 4770 [RV740] with the latest d-r-t
(In reply to comment #1) > The "Inconsistency detected by ld.so: ..." line in > the log looks suspicious, although it's unclear to me if it's related to the > cause of the crash. I wonder if that line has something to do with the libc6 (2.13-0exp3) I have installed from Debian's experimental repos... > Normally when source engine games crash they write a > minidump in "dumps" in your Steam directory, you can open those with winedbg to > get a backtrace. The dbghelp FIXME and ld.so message make me suspect it might > have failed to produce a usable minidump this time though. I believe you are correct, Steam is writing minidumps in dumps/, but winedbg doesn't appear to be of any help. Though 'bt' does report "Exception c0000005" if that is of any significance?
Update: CS: Source now successfully boots up to the menu! However I'm unsure whether this is due to fix in mesa, wine, or libc6. Though now if I attempt to start and load a game from the menu, everything appears to go though smoothly until the last few bits are initialized. From there I'm put into a loop of GPU lockups and GPU resets. Therefore this bug may be related to #36421 now. The game still renders the match welcome screen throughout these GPU lockup/reset cycles though, and I am able to eventually switch to different workspace to kill the cstrike process. Additionally, the in game stress test renders reasonably well until the camera begins to enter the room with the transparent player model with flames behind it (forgive me if I'm not using the correct terminology). At this point (before the flames "turn on") the stress test freezes and goes into the gpu reset loop described above.
Created attachment 46749 [details] css kernel backtraces
I'm pretty sure you're seeing the common GPU reset problems when using the HL2 engine DX9 renderpath. So yes, that's the bug #36421 you already mentioned.
Thanks for the confirmation there. I did end up running Steam/CS: Source through zach rusin's apitrace tool, getting the following trace: http://uploading.com/files/1213aed2/css.glapi.trace/ the erroneous call seems to be 235567 glDrawBuffer(mode = GL_BACK) 235567: warning: glGetError(glDrawBuffer) = GL_INVALID_OPERATION Mesa: User error: GL_INVALID_OPERATION in glDrawBuffer(buffer=0x405) Hopefully this helps greatly in the debugging process. :)
I'm going to go ahead and close this bug since it is no longer reproducible on my system. The issue for me now is bug 38581
I presume this was fixed by: http://cgit.freedesktop.org/mesa/mesa/commit/?id=04554c7d3a3b28e8103e50ed54f1ac57c6c11017
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.