Bug 31406 discussion

[Rico]

This is the topic to bug 31406 . The goal is to get an overview, which patch works for which game and which doesn't. The first post is used as overview, I'll update it from time to time. The bug is sometimes hard to hit, so the tests may be hard too. There will be more patches to check if the issue is fixed. If your game is hit by the bug, please add information like (in this example sacred):
game name: Sacred
gpu / gpu driver version: AMD HD 4300 / Gallium 0.4 on AMD RV710 - 2.1 Mesa 8.0.3
test: patch "Fix for the libxcb poll() issue - debug version" seems to work, but one obscure crash (needs further testing)
os: Fedora 17

As of 2012-09-24, working with "Fix for the libxcb poll() issue":
- World of Tanks
- d3d8/9 device test - wndproc/wndproc_windowed
- PlayOnline Viewer

As of 2012-09-24, need further testing "Fix for the libxcb poll() issue":
- Sacred, Sacred Underworld (demo: http://www.fileplanet.com/137063/130000 ... English%5D)
- Spec Ops: The Line
- Borderlands (seems to be fixed by "Fix for the libxcb poll() issue", but it may be also be fixed by libxcb commit 5ceeaaa4294201b3f613c07f9ec610c0e5f673c7)
- The Elder Scrolls V Skyrim (still crashes with: "Fix for the libxcb poll() issue" - see http://bugs.winehq.org/show_bug.cgi?id=31406#c62 ... does patch http://bugs.winehq.org/attachment.cgi?id=41611 help?)
- Mass Effect 2
- Mass Effect 3

How to patch and use libxcb:

Code: Select all

# get patches for libxcb / get libxcb source (only needed one time)
cd <some path>
git clone git://anongit.freedesktop.org/git/xcb/libxcb
# "Fix for the libxcb poll() issue - debug version"
wget http://bugs.winehq.org/attachment.cgi?id=41708 -O poll-debug.patch

# clean all, build (needed for every single patch)
cd <some path>/libxcb
git checkout -f
git clean -d -x -f
git apply ../<name>.patch
./autogen.sh (OR for 64bit systems: ./autogen.sh --build=i686-pc-linux-gnu "CFLAGS=-m32" "CPPFLAGS=-m32" "LDFLAGS=-m32")
make

# run wine to test (from another terminal)
LD_LIBRARY_PATH=<some path>/libxcb/src/.libs wine <app>

# Verify if the patch was applied correctly and you are using the correct lib by either locking into the terminal
the lib prints "Patched: libxcb poll debug patch (!c->in.reading)"

[Chiitoo]

Teegrins!

Sorry, it took a while for me to look into this again.
In any case, here are some results from my testing and whatnot.

Application Name: PlayOnline Viewer (FINAL FANTASY XI)
GPU / GPU Driver Version: nVidia GTX275 / nvidia-drivers-304.4 / xorg-server-1.13.0 / mesa-8.0.4-r1
Test: Using a 'live' build of the patched software does not seem to help, details below.
OS: Linux-3.5.3-gentoo-x86_64-AMD_Phenom-tm-_II_X6_1090T_Processor-with-gentoo-2.1

I still don't know what I am missing. That's not surprising though considering I have been using Linux full-time for only a little under two years now!

But I digress, as usual.

If I build and use the libxcb outside the package manager (Portage), as described in the post above, the application (PlayOnline Viewer, or pol.exe) does not hang in the loop.
However, if I use Portage to patch libxcb, it does not change a thing. As I said, I am probably missing something obvious right now, but what I can tell is that my system is indeed using the patched library from the following observations.

When using the 'debug version' of the patch, KDE fails to start:

Code: Select all

<some output missing in action>
Loading extension GLX
Loading extension NV-GLX
Loading extension NV-CONTROL
Loading extension XINERAMA
Patched: libxcb poll debug patch (!c->in.reading)
Patched: libxcb poll debug patch (!c->in.reading)
Patched: libxcb poll debug patch (!c->in.reading)
Patched: libxcb poll debug patch (!c->in.reading)
Patched: libxcb poll debug patch (!c->in.reading)
startkde: Starting up...
/usr/bin/startkde: eval: line 275: syntax error near unexpected token `('
/usr/bin/startkde: eval: line 275: `Patched: libxcb poll debug patch (!c->in.reading) 
DBUS_SESSION_BUS_ADDRESS='unix:abstract=/tmp/dbus-7fYBbdR7Nh,guid=280e5b281a70a8cf0abed1af50597c82'; export DBUS_SESSION_BUS_ADDRESS; 
DBUS_SESSION_BUS_PID=1726; DBUS_SESSION_BUS_WINDOWID=6291457;'
xinit: connection to X server lost

waiting for X server to shut down Server terminated successfully (0). Closing log file.

When using Enlightenment or/and Xfce4, going to Ctrl+Alt+F1 to check the terminal-output shows the “Patched: libxcb poll debug patch (!c->in.reading)” messages.

The latter (above) part actually made me notice something rather peculiar (or is it obvious to everyone else?), that is, when I change to another tty or graphical session, the application advances! Sometimes it requires a few 'hops' back and forth, but I can advance without a fail this way.

Does this happen to anyone else?

From all that it would seem like Wine is still not using the patched library even though the system is, and there shouldn't be anything else to use... or something. It would seem like have to do more testing and figuring out over my own issues here to be more helpful with this in general.

Moreover, as long as I didn't mix up the packages I built of wine-1.5.13, I do not need to patch wined3d_main.c for the issue to be gone, as long as I specify the custom LD_LIBRARY_PATH to the patched libxcb...

I will try to see if I can try out some of the other affected applications, and for those who might want to try out with PlayOnline Viewer, it can be downloaded here:

• http://www.playonline.com/ff11eu/download/media/vista01.html?pageID=media

This is great for testing since, at least for me, the loop is one of the first things that happen. Meaning one does not need an account, or even log in to be able to test it. Quick and simple!


I think that is all, fer now.
Probably forgot a ton of stuff due to multi-tasking way too little at the time of testing...

[Rico]

Application Name: PlayOnline Viewer (FINAL FANTASY XI)
GPU / GPU Driver Version: nVidia GTX275 / nvidia-drivers-304.4 / xorg-server-1.13.0 / mesa-8.0.4-r1
Test: Using a 'live' build of the patched software does not seem to help, details below.
OS: Linux-3.5.3-gentoo-x86_64-AMD_Phenom-tm-_II_X6_1090T_Processor-with-gentoo-2.1
...
If I build and use the libxcb outside the package manager (Portage), as described in the post above, the application (PlayOnline Viewer, or pol.exe) does not hang in the loop.

So the patch fixes the issue for you? I guess there is only a problem with the usage of Portage.

However, if I use Portage to patch libxcb, it does not change a thing. As I said, I am probably missing something obvious right now, but what I can tell is that my system is indeed using the patched library from the following observations.

Does Portage build by default the 32bit libs? Did you got the output “Patched: libxcb poll debug patch (!c->in.reading)” when starting wine and using the Portage build? I think it only builds and uses the 64bit version. You could see it in your observations, that the 64bit version is used. However I think you don't use the 32bit version.

When using the 'debug version' of the patch, KDE fails to start:

Well, KDE tries to eval the output and with the debug patch, it fails to do so. Off course, the non debug version should work as is. Sometimes software do just curiously assume and use some libs. A better solution would be to use stderr in the debug patch or to not use the output as it is in KDE. Since Enlightenment and Xfce4 are working, KDE isn't probably doing the best stuff here ...

The latter (above) part actually made me notice something rather peculiar (or is it obvious to everyone else?), that is, when I change to another tty or graphical session, the application advances! Sometimes it requires a few 'hops' back and forth, but I can advance without a fail this way.

Does this happen to anyone else?

I don't got it. What exactly happens wrong with the applied patch? What does "the application advances" mean? I think it's normal that the application will run as long as you don't kill it.

From all that it would seem like Wine is still not using the patched library even though the system is, and there shouldn't be anything else to use... or something. It would seem like have to do more testing and figuring out over my own issues here to be more helpful with this in general.

Moreover, as long as I didn't mix up the packages I built of wine-1.5.13, I do not need to patch wined3d_main.c for the issue to be gone, as long as I specify the custom LD_LIBRARY_PATH to the patched libxcb...

Yes, that's what's expected. Attachment 41611 partly reverts the regression and is not needed if you use the libxcb patch. The libxcb patch should fix it.

I will try to see if I can try out some of the other affected applications, and for those who might want to try out with PlayOnline Viewer, it can be downloaded here:

• http://www.playonline.com/ff11eu/downlo ... geID=media

This is great for testing since, at least for me, the loop is one of the first things that happen. Meaning one does not need an account, or even log in to be able to test it. Quick and simple!

I think that is all, fer now.
Probably forgot a ton of stuff due to multi-tasking way too little at the time of testing...

I'll try your app. There seems to be a problem with applying patches to Portage. There are several gentoo users, all of which use 64bit version, which are not able to build and use a correctly patched 32bit libxcb version. They claim that the patch doesn't work, which is why I added the output to check it in the first place. If you got that working with Portage, it might be good to know what tricks you did. Thank you for your report.

[Chiitoo]

So the patch fixes the issue for you? I guess there is only a problem with the usage of Portage.

Yeah, it would seem like it does. There's just something I'm not taking into consideration with it when going about it the 'right way', as one isn't supposed to compile and use things outside of Portage normally. I'll probably need to consult those with more knowledge on library usage and such.

Does Portage build by default the 32bit libs? Did you got the output “Patched: libxcb poll debug patch (!c->in.reading)” when starting wine and using the Portage build? I think it only builds and uses the 64bit version. You could see it in your observations, that the 64bit version is used. However I think you don't use the 32bit version.

As I understand it, when using a 'multilib profile', yes. The default profile (which I am using) is a multilib-enabled profile. Moreover, if I check the shared libraries being used for the pol.exe, it would indeed show files such as '60 KB /usr/lib32/libxcb.so.1.1.0' in the list.

Well, KDE tries to eval the output and with the debug patch, it fails to do so. Off course, the non debug version should work as is. Sometimes software do just curiously assume and use some libs. A better solution would be to use stderr in the debug patch or to not use the output as it is in KDE. Since Enlightenment and Xfce4 are working, KDE isn't probably doing the best stuff here ...

Yeah, in any case, it should confirm the the patched libxcb is indeed being used. I clearly don't quite understand why it seems like it isn't when running the applications via Wine, but it's likely something obvious I am missing.

I don't got it. What exactly happens wrong with the applied patch? What does "the application advances" mean? I think it's normal that the application will run as long as you don't kill it.

What I mean is, when the application is 'frozen in the loop', and I jump to another tty, the application gets over the freeze/loop and continues until I click on options and it will freeze again. If I change the tty again, it will be able to proceed further.

Yes, that's what's expected. Attachment 41611 partly reverts the regression and is not needed if you use the libxcb patch. The libxcb patch should fix it.

Ah, all right, thanks for clearing/confirming that!

I'll try your app. There seems to be a problem with applying patches to Portage. There are several gentoo users, all of which use 64bit version, which are not able to build and use a correctly patched 32bit libxcb version. They claim that the patch doesn't work, which is why I added the output to check it in the first place. If you got that working with Portage, it might be good to know what tricks you did. Thank you for your report.

I will definitely post my findings if I can figure it out before someone else does.

[Chiitoo]

Tiziano Müller provided a simple enough explanation to the Gentooers and to what I had been missing (and it's not the first time I forget to think about the emul-linux packages, sigh):

The problem here is that wine on amd64 uses the libxcb from
emul-linux-x86-xlibs in /usr/lib32 while the libxcb installs only the libxcb in
/usr/lib64

But I can confirm that the patch mentioned fixes deadlock issues with Dragon
Age 1 and 2.

So as long as I understand it all right, until the emul-linux package is modified, one could build a 'stand-alone' version of libxcb from git, and use that for running any affected applications.

The above guide is all that is needed to achieve that, though one may want to omit the parts that deal with the patch (since the actual git version is fixed now).


I hope this helps~
Thank you.

[piedar]

>=libxcb-1.8.1-r1 fixes this for me on Gentoo with app-emulation/wine-1.5.14. However, upgrading to x11-libs/libxcb-1.8.1-r1 isn't sufficient on amd64 since wine uses 32-bit libxcb from app-emulation/emul-linux-x86-xlibs-20120520 which was built with libxcb-1.7. https://bugs.gentoo.org/show_bug.cgi?id=437876
Unfortunately, it looks like Gentoo will hold off on bumping to libxcb-1.9* until it's compatible with python-3: https://bugs.freedesktop.org/show_bug.cgi?id=55690

Until that happens:

build a 'stand-alone' version of libxcb from git, and use that for running any affected applications. The above guide is all that is needed to achieve that, though one may want to omit the parts that deal with the patch (since the actual git version is fixed now).

For amd64:

Code: Select all

cd /tmp
curl http://cgit.freedesktop.org/xcb/libxcb/snapshot/libxcb-1.9.tar.gz | tar xz
cd libxcb-1.9
./autogen.sh --build=i686-pc-linux-gnu CFLAGS=-m32 CPPFLAGS=-m32 LDFLAGS=-m32
make

Now prepend

Code: Select all

env LD_LIBRARY_PATH=/tmp/libxcb-1.9/src/.libs

to your Steam launcher and you're set.

For x86 it's trivial:

Code: Select all

echo "=x11-libs/libxcb-1.8.1-r1 ~x86 >> /etc/portage/package.keywords
emerge -v1 libxcb

Thanks to everyone involved in getting this one sorted.