http://bugs.winehq.org/show_bug.cgi?id=31883
Bug #: 31883 Summary: regression/dogfood: PCSX2 locks up when/shortly after initializing MTGS Product: Wine Version: 1.5.14 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winex11.drv AssignedTo: wine-bugs@winehq.org ReportedBy: billy65bob@gmail.com Classification: Unclassified
This has been happening since mid/early August when work began to remove the "Big X Lock."
Since then, attempting to initialise the GS has caused either one of two results 1. The MTGS fails to initialise 2. it initialises and completely locks up after a few seconds of continually degrading performance. Console output identifies the context_section critical section as the point of failure
I have attached 3 logs, their names indicate the WIENDEBUG value used. relay_wgl.log - failed to initialise (even after multiple attempts) relay.log - failed to initialise wgl.log - initialised and locked up shortly after
The first problematic build I have is dated August 14th, things get increasingly worse going forwards. The last problem free build is dated August 2nd
As for how things got worse (and isn't really relevant to the bug report), since 8/14, additional work kept being done. Initially I could scroll or move another wine window to fudge the locking a bit, this would either resolve it temporarily to at least give me a fighting chance to restart the renderer and play. It could still occasionally initialise it properly at this stage. Going forward, I could not longer used this trick and it started locking up constantly and reliably, to the point that I could no longer get a lucky break to run it for even a moment. Also worth noting that in some of the worst cases, the window created by the GS looks like it's initial update to a full black window is being done in 100x100 tiles over a few seconds.
http://bugs.winehq.org/show_bug.cgi?id=31883
--- Comment #1 from Kevin Meyer billy65bob@gmail.com 2012-10-04 08:02:10 CDT --- Bluh... Attachment upload failed... I've put it on my dropbox, it will take a little while to upload though.
https://dl.dropbox.com/u/23891252/logs.tar.bz2
http://bugs.winehq.org/show_bug.cgi?id=31883
--- Comment #2 from Rico kgbricola@web.de 2012-10-04 08:26:32 CDT --- Please run a regression test (see http://wiki.winehq.org/RegressionTesting ). and attach a backtrace of the hanging threads (See http://wiki.winehq.org/Backtraces).
http://bugs.winehq.org/show_bug.cgi?id=31883
--- Comment #3 from Kevin Meyer billy65bob@gmail.com 2012-10-04 10:17:19 CDT --- Created attachment 41972 --> http://bugs.winehq.org/attachment.cgi?id=41972 backtrace taken ASAHP after locking up
Using the latest revision I can I have tried to get you the backtrace and it seems it fell afoul of the "surfaces_section" in user32 this time. It's a complete first as far as I'm concerned.
then I tried again and it got stuck in the "surface" critical section - it kind of just hanged when I told it to backtrace. (this is also a first)
third time's the charm, I got a backtrace for most of the running threads via bt all, but debug information was rather absent...
a bunch of long compile times later, here's a possibly incomplete backtrace... I attached the debugger as soon as it froze, before it had a chance to say it timed out.
I'll get onto the bisection stuff in the morning.
http://bugs.winehq.org/show_bug.cgi?id=31883
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression Summary|regression/dogfood: PCSX2 |PCSX2 locks up when/shortly |locks up when/shortly after |after initializing MTGS |initializing MTGS |(dogfood)
http://bugs.winehq.org/show_bug.cgi?id=31883
--- Comment #4 from Rico kgbricola@web.de 2012-10-04 15:37:43 CDT --- Could you check, in one run if the blocking thread from the error: "err:ntdll:RtlpWaitForCriticalSection section 0x7e265040 "../../../wine-git/dlls/winex11.drv/opengl.c: context_section" wait timed out in thread 0009, blocked by 002d, retrying (60 sec)" is equal the thread which called xcb_wait_for_reply: "4 0x7dfb27b7 xcb_wait_for_reply+0x66() in libxcb.so.1 (0x7def7374)"
Though, make sure you use the values from the same run. If they are equal, please have a look at bug 31406. Does current git from libxcb help for you? (build instructions are here: http://forum.winehq.org/viewtopic.php?f=2&t=17203, but you don't need the debug patch anymore, so skip the line with "git apply ../<name>.patch").
http://bugs.winehq.org/show_bug.cgi?id=31883
--- Comment #5 from Kevin Meyer billy65bob@gmail.com 2012-10-04 21:35:35 CDT --- After reading the bug report, my initial response is: My distro already ships 1.8.1
Regardless, I have cloned xcb-git and xcb-proto-git and installed them. (someone should make a note somewhere that it doesn't build with python 3.x...). Amusingly there's a commit dated 25 sept which seems quite relevant..
Observations... It now seems to initialise reliably... It still freezes after several seconds, but the previously mentioned scrolling trick lets it continue for a little while again. If I don't do that, it will still print the context_section time out.
Also of note, with the freezes, I can now "pause" the VM thanks to the scrolling trick. Resuming it at this point seems to set it into a functional and playable state, which is almost what it was like back in 1.5.10.
http://bugs.winehq.org/show_bug.cgi?id=31883
--- Comment #6 from Kevin Meyer billy65bob@gmail.com 2012-10-04 22:13:04 CDT --- Oh bluh... I just realised I only built the 64bit version of the library. I've now built the 32bit version as well...
The program now initialises to 7-8 FPS, I've been unable to make it freeze/lock-up after multiple attempts. After some pause/resume invocations, it runs at the intended 60 FPS.
http://bugs.winehq.org/show_bug.cgi?id=31883
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |DUPLICATE
--- Comment #7 from Alexandre Julliard julliard@winehq.org 2012-10-10 11:20:14 CDT --- Duplicate then.
*** This bug has been marked as a duplicate of bug 31406 ***
http://bugs.winehq.org/show_bug.cgi?id=31883
t800 housegregory299@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |housegregory299@gmail.com
--- Comment #8 from t800 housegregory299@gmail.com 2012-10-10 11:38:15 CDT --- (In reply to comment #5)
After reading the bug report, my initial response is: My distro already ships 1.8.1
Regardless, I have cloned xcb-git and xcb-proto-git and installed them. (someone should make a note somewhere that it doesn't build with python 3.x...). Amusingly there's a commit dated 25 sept which seems quite relevant..
Observations... It now seems to initialise reliably... It still freezes after several seconds, but the previously mentioned scrolling trick lets it continue for a little while again. If I don't do that, it will still print the context_section time out.
Also of note, with the freezes, I can now "pause" the VM thanks to the scrolling trick. Resuming it at this point seems to set it into a functional and playable state, which is almost what it was like back in 1.5.10.
What distro you using ? It seems it was fixed for Ubuntu.
http://bugs.winehq.org/show_bug.cgi?id=31883
--- Comment #9 from Kevin Meyer billy65bob@gmail.com 2012-10-10 18:48:45 CDT --- (In reply to comment #8)
What distro you using ? It seems it was fixed for Ubuntu.
Ubuntu is a distro I absolutely detest for various reasons not suitable for discussion on bugzilla, in short I will never use it willingly or wish it upon my enemies.
My current of choice is Arch, which is rather well known for shipping the latest and greatest vanilla packages.
http://bugs.winehq.org/show_bug.cgi?id=31883
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #10 from Austin English austinenglish@gmail.com 2012-10-10 19:53:12 CDT --- (In reply to comment #9)
(In reply to comment #8)
What distro you using ? It seems it was fixed for Ubuntu.
Ubuntu is a distro I absolutely detest for various reasons not suitable for discussion on bugzilla, in short I will never use it willingly or wish it upon my enemies.
My current of choice is Arch, which is rather well known for shipping the latest and greatest vanilla packages.
It's also known to ship broken packages, see, http://bugs.winehq.org/show_bug.cgi?id=22316 et al.