http://bugs.winehq.org/show_bug.cgi?id=11050
Summary: Wine hangs on machines with Via Unichrome graphics Product: Wine Version: 0.9.52. Platform: Other OS/Version: other Status: UNCONFIRMED Severity: critical Priority: P2 Component: wine-x11driver AssignedTo: wine-bugs@winehq.org ReportedBy: karllinuxtest.relton@ntlworld.com
Wine appears to be hanging and freezing X11 in Ubuntu Gutsy distribution on machines with Via Unichrome graphics.
Even running wineprefixcreate is enough to cause the problem - needless to say trying wine with any executable (e.g. notepad) then gives the same symptoms.
Wine hangs, and the X11 freezes (no mouse movement, no keyboard response). The machine itself is okay - one can ssh in and kill the offending process which then unfreezes X.
The offending process is rundll32.exe - which sits at 99% CPU.
Looking at Ubuntu forums, several other people have hit the same problem: see http://ubuntuforums.org/archive/index.php/t-584308.html
This happens on my PC with Via Unichrome graphics, my other two PCs (Nvidia and Intel graphics) are fine.
I backtracked my install of wine all the way to the Feisty shipped version (0.9.33), and it has the same problem. This suggests some interaction between the graphics libraries in Gutsy and wine that was not present in previous releases.
I'll attach a log with +relay. In that you will see there is a page fault (line 27514), starting debugger ... The final couple of lines in the log I think occur when I kill the runaway rundll32.exe process.
If I hide the winex11.drv.so file so that wine cannot load it, then wineprefixcreate will complete correctly and wine can be used ... but of course in text mode only! This confirms some interaction with the graphics that seems only present when X11 is running its 'via' driver.
I am happy to try and help debug - but would appreciate pointers of what I should do next, e.g. what channels to enable.
http://bugs.winehq.org/show_bug.cgi?id=11050
--- Comment #1 from Roderick Colenbrander thunderbird2k@gmx.net 2008-01-05 05:08:28 --- I suspect the problem has to do with some OpenGL initialization Wine has to do at startup. This needs to be done in all cases even when OpenGL / Direct3D won't be used as without it OpenGL / Direct3D won't function.
You should try to 'hide' libGL.so and see what happens if you start Wine then.
http://bugs.winehq.org/show_bug.cgi?id=11050
--- Comment #2 from Karl Relton karllinuxtest.relton@ntlworld.com 2008-01-05 05:14:24 --- Created an attachment (id=10056) --> (http://bugs.winehq.org/attachment.cgi?id=10056) wineprefixcreate with +relay
Log is too large to attach in full, so I have snipped everything up until it starts loading winex11.drv.
http://bugs.winehq.org/show_bug.cgi?id=11050
--- Comment #3 from Karl Relton karllinuxtest.relton@ntlworld.com 2008-01-05 08:08:20 --- Yes - hiding libGL.so enables wineprefixcreate to complete (albeit with an error about not being able to load builtin opengl32.dll because libGL.so is not found - as one would expect).
I'll unhide libGL.so and try wine with +opengl and +wgl and see if I get any more info.
http://bugs.winehq.org/show_bug.cgi?id=11050
--- Comment #4 from Karl Relton karllinuxtest.relton@ntlworld.com 2008-01-05 09:04:22 --- Created an attachment (id=10059) --> (http://bugs.winehq.org/attachment.cgi?id=10059) wineprefixcreate with +opengl,+wgl
Nothing too exciting revealed here - just shows the opengl info.
http://bugs.winehq.org/show_bug.cgi?id=11050
--- Comment #5 from Roderick Colenbrander thunderbird2k@gmx.net 2008-01-05 09:25:01 --- As I expected it is a GLX issue. If you can code you could check dlls/winex11.drv/opengl.c 'has_opengl' to see where it fails. I don't expect there is a Wine bug but a driver bug.
http://bugs.winehq.org/show_bug.cgi?id=11050
--- Comment #6 from Karl Relton karllinuxtest.relton@ntlworld.com 2008-01-05 11:20:51 --- It falls over in function X11DRV_WineGL_InitOpenglInfo on the call to pglXDestroyContext (line 353 of opengl.c):
TRACE("Direct rendering enabled: %s\n", WineGLInfo.glxDirect ? "True" : "False");
if(vis) XFree(vis); if(ctx) { pglXMakeCurrent(gdi_display, None, NULL); pglXDestroyContext(gdi_display, ctx); <--- DIES HERE } wine_tsx11_unlock(); return TRUE;
Hmmm - where to go now?
http://bugs.winehq.org/show_bug.cgi?id=11050
--- Comment #7 from Karl Relton karllinuxtest.relton@ntlworld.com 2008-01-05 11:40:31 --- I should add that if I comment out the line to pglXDestroyContext, then wineprefixcreate completes successfully - not that I am suggesting that as a real solution.
http://bugs.winehq.org/show_bug.cgi?id=11050
--- Comment #8 from Roderick Colenbrander thunderbird2k@gmx.net 2008-01-05 12:52:33 --- This is the driver bug I was fearing. In order to print out GL/GLX a GLX context is created, so that GL/GLX calls can be made. Once the info is printed we don't need the context anymore and kill it. We do so only if we got a valid context before. In your case the context looks valid (else no GL/GLX call is possible) but killing the context for some reason doesn't work.
This shouldn't happen at all and is a driver or Mesa bug. I would contact them.
http://bugs.winehq.org/show_bug.cgi?id=11050
James Hawkins truiken@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |INVALID
--- Comment #9 from James Hawkins truiken@gmail.com 2008-01-05 12:55:37 --- Invalid.
http://bugs.winehq.org/show_bug.cgi?id=11050
James Hawkins truiken@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #10 from James Hawkins truiken@gmail.com 2008-01-05 12:55:59 --- Closing.
-
wine-bugs＠winehq.org