http://bugs.winehq.org/show_bug.cgi?id=26862
Summary: Portal 2 crashes at various points of game with disabled GLSL Product: Wine Version: 1.3.18 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: NightNord@gmail.com
Tested on both fglrx and mesa drivers, so that's probably not a driver bug.
When GLSL _disabled_ game crashes at any loading screen, with only possible exception of new-game loading screen. When GLSL enabled, mesa driver locks up, but fglrx goes though and loads the game.
(Steam version, with cracks applied to make game running)
http://bugs.winehq.org/show_bug.cgi?id=26862
Night Nord NightNord@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Portal 2 crashes at various |Portal 2 crashes at loading |points of game with |with disabled GLSL |disabled GLSL |
--- Comment #1 from Night Nord NightNord@gmail.com 2011-04-20 12:35:48 CDT --- Correction: only moment where it doesn't crash is savegame just-before-first-portal-opened and saves after that before level end. Loading next level or any save from next level, or trying to start new game results in crash.
http://bugs.winehq.org/show_bug.cgi?id=26862
--- Comment #2 from Night Nord NightNord@gmail.com 2011-04-20 12:37:59 CDT --- Created an attachment (id=34244) --> (http://bugs.winehq.org/attachment.cgi?id=34244) +d3d,+d3d_caps,+trace,+seh debug log
It seems that game exists 'validly' by catching some strange error which is not reflected in log.
http://bugs.winehq.org/show_bug.cgi?id=26862
Night Nord NightNord@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Portal 2 crashes at loading |Portal 2 crashes at |with disabled GLSL |level/save loading with | |disabled GLSL
http://bugs.winehq.org/show_bug.cgi?id=26862
--- Comment #3 from Ken Sharp kennybobs@o2.co.uk 2011-04-20 15:10:29 CDT ---
(Steam version, with cracks applied to make game running)
What "cracks"?
Is there no backtrace at all? Does the game have it's own debugger?
http://bugs.winehq.org/show_bug.cgi?id=26862
--- Comment #4 from Night Nord NightNord@gmail.com 2011-04-20 15:38:00 CDT --- 1) The pirate ones. That's a DRM system failing (bug #26835), is there any other "cracks" to apply to "fix" it? 2) No, there was backtrace, but I've removed it to make wine developer happier. They love digging bugs without proper information, I know. Well, actually, it could be winedbg which failed again, but I don't see any suspicious messages, that would notify about this. I suppose that that's a game who handles this exceptions and then bails out without error. 3) Err... Game with own debugger? I really doubt that there is many of such games, if at all.
http://bugs.winehq.org/show_bug.cgi?id=26862
Jerome Leclanche adys.wh@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |adys.wh@gmail.com
--- Comment #5 from Jerome Leclanche adys.wh@gmail.com 2011-04-20 17:56:09 CDT --- (In reply to comment #4)
- Err... Game with own debugger? I really doubt that there is many of such
games, if at all.
Steam has its own debugger. Attach the relevant dummp from <steamroot>/dumps/
http://bugs.winehq.org/show_bug.cgi?id=26862
--- Comment #6 from Night Nord NightNord@gmail.com 2011-04-21 03:25:55 CDT --- That's not a debugger, but rather corefile catcher. And it's working only when game is running under Steam, which is not this case (bug #26835)
http://bugs.winehq.org/show_bug.cgi?id=26862
--- Comment #7 from Jerome Leclanche adys.wh@gmail.com 2011-04-21 03:27:26 CDT --- (In reply to comment #6)
That's not a debugger, but rather corefile catcher. And it's working only when game is running under Steam, which is not this case (bug #26835)
Try wine portal2.exe -novid -nobreakpad -nominidumps
http://bugs.winehq.org/show_bug.cgi?id=26862
--- Comment #8 from Night Nord NightNord@gmail.com 2011-04-21 05:24:51 CDT --- Created an attachment (id=34261) --> (http://bugs.winehq.org/attachment.cgi?id=34261) Trimmed +all log of crash, last 10000 lines
0xc000005 is STATUS_ACCESS_VIOLATION, which is not so meaningful. Only thing I could imagine - there is less constants in shader than it tries to assign.
I've cut log after exception handler completion.
http://bugs.winehq.org/show_bug.cgi?id=26862
--- Comment #9 from Night Nord NightNord@gmail.com 2011-04-21 05:30:05 CDT --- Created an attachment (id=34262) --> (http://bugs.winehq.org/attachment.cgi?id=34262) Crash backtrace produced by -nominidumps -nobreakpad
Ok, sorry, I've forgotten to look if this system could be disabled, thanks for tip. Attaching log now.
http://bugs.winehq.org/show_bug.cgi?id=26862
--- Comment #10 from Night Nord NightNord@gmail.com 2011-04-22 07:28:50 CDT --- One Nvidia user confirmed in AppDB entry comment, that NVidia are free from this bug, but I'm still getting it on git kernel (with working s3tc on r600g, so game is now looking just as on fglrx) and git mesa drivers. It seems to be some nvidia's non-conformance wine relaying on. But we still need some mesa-users (intel) confirmation (they should also have this crash than).
http://bugs.winehq.org/show_bug.cgi?id=26862
Stefan Dösinger stefandoesinger@gmx.at changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED CC| |stefandoesinger@gmx.at Resolution| |INVALID
--- Comment #11 from Stefan Dösinger stefandoesinger@gmx.at 2011-05-01 07:25:27 CDT --- Fwiw, this bug is invalid like the other crash on amd cards without GLSL. ARB shaders support only shader model 2.0, this game very likely uses 3.0 without checking for support. On Nvidia we have GL_NV_fragment_program2 and GL_NV_vertex_program3 which allow us to implement shader model 3.0 with ARB shaders. On other cards no equivalent extension exists. This applies to mesa and fglrx alike.
http://bugs.winehq.org/show_bug.cgi?id=26862
--- Comment #12 from Night Nord NightNord@gmail.com 2011-05-01 14:41:00 CDT --- On a side note - this happens only on pure win32 setup. No crash on shared WoW64 setup for unknown reason. Does your resolution still apply?
http://bugs.winehq.org/show_bug.cgi?id=26862
--- Comment #13 from Stefan Dösinger stefandoesinger@gmx.at 2011-05-01 14:49:04 CDT --- That's strange for sure, but it could also be coincidence(e.g. different handling of the exception, or the app randomly passing in a different pixel shader when the call fails). You're welcome to debug this, but I won't spend my time on trying to figure out why a 32 bit and WoW64 setup behave differently.
I can reopen the bug if you want to, but don't expect too much action on it.
http://bugs.winehq.org/show_bug.cgi?id=26862
--- Comment #14 from Night Nord NightNord@gmail.com 2011-05-01 16:05:03 CDT --- Well, I guess it's not a big deal. It has it's workarounds (use shared WoW) and now fglrx don't crash too often with GLSL enabled.
I'm not very good in wine debugging and I'm currently on gcc-4.6.0 which may produce some bugs by itself, so I would prefer to leave this bug as INVALID by now. If I'll find anything, I'll told you, thanks.
http://bugs.winehq.org/show_bug.cgi?id=26862
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #15 from Austin English austinenglish@gmail.com 2011-05-16 04:34:40 CDT --- Closing.