Created attachment 325468 [details] emerge --info libxcb I may be very far from the actual issue here, but it is what it looks like... I was debating on filing a bug for a version bump due to the git-version having a fix as of sept. 24, but since this issue is seemingly blocking it (for amd64 at least), I figured something should be done about this first. Since wine-1.5.10, several applications hang in a loop of sorts, and patching libxcb with the proposed patches doesn't seem to help, that is, when patching, compiling, and installing by using Portage. When doing it outside of Portage, things seem to be working. The following commit seems to fix it as well, but only if libxcb is built following the directions here (omitting the patching part since the commit works as well): http://forum.winehq.org/viewtopic.php?f=2&t=17203 The above thread also contains more information and details of my testing. Unfortunately, I can not currently try if everything is fine on x86 (though perhaps I could do a x86 install via VirtualBox). The upstream bug: https://bugs.freedesktop.org/show_bug.cgi?id=54671 commit 23911a707b8845bff52cd7853fc5d59fb0823cef Author: Uli Schlachter <psychon@znc.in> Date: Mon Sep 24 22:07:51 2012 +0200 Fix a multi-thread deadlock This fixes a deadlock which was seen in-the-wild with wine. It could happen that two threads tried to read from the socket at the same time and one of the thread got stuck inside of poll()/select(). The fix works by making sure that the writing thread doesn't steal the reading thread's reply. Debugged-by: Erich Hoover <ehoover@mines.edu> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54671 Signed-off-by: Uli Schlachter <psychon@znc.in> I'm sorry, if I'm simply missing something very obvious here, and if my first bug reported ends up being redundant. Any clues as to how fix this or where to go from here would be very much appreciated! Thank you.
Created attachment 325470 [details] x11-libs/libxcb-9999 build log
Created attachment 325472 [details] x11-libs/libxcb-9999 ebuild The ebuild used to build from git (simply a copy from the official tree modified to fetch from git instead).
Portage 2.2.0_alpha134 (default/linux/amd64/10.0, gcc-4.5.4, glibc-2.15-r2, 3.5.3-gentoo x86_64) ================================================================= System Settings ================================================================= System uname: Linux-3.5.3-gentoo-x86_64-AMD_Phenom-tm-_II_X6_1090T_Processor-with-gentoo-2.1 Timestamp of tree: Mon, 01 Oct 2012 09:15:01 +0000 ccache version 3.1.7 [disabled] app-shells/bash: 4.2_p37 dev-java/java-config: 2.1.11-r3 dev-lang/python: 2.7.3-r2, 3.2.3 dev-util/ccache: 3.1.7 dev-util/cmake: 2.8.8-r3 dev-util/pkgconfig: 0.27.1 sys-apps/baselayout: 2.1-r1 sys-apps/openrc: 0.9.8.4 sys-apps/sandbox: 2.5 sys-devel/autoconf: 2.13, 2.68 sys-devel/automake: 1.9.6-r3, 1.11.6 sys-devel/binutils: 2.22-r1 sys-devel/gcc: 4.5.4 sys-devel/gcc-config: 1.7.3 sys-devel/libtool: 2.4-r1 sys-devel/make: 3.82-r3 sys-kernel/linux-headers: 3.4-r2 (virtual/os-headers) sys-libs/glibc: 2.15-r2 Repositories: gentoo multimedia enlightenment java-overlay proaudio lcd-filtering glc stuff sunrise testi_overlay Installed sets: @e17 ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="*" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=amdfam10 -O2 -fomit-frame-pointer -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/config /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-march=amdfam10 -O2 -fomit-frame-pointer -pipe" DISTDIR="/mnt/iso/Romuja/Portage/distfiles" EMERGE_DEFAULT_OPTS="--quiet-build=n" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="rsync://trumpetti.atm.tut.fi/gentoo/ ftp://trumpetti.atm.tut.fi/gentoo/ http://trumpetti.atm.tut.fi/gentoo/" LANG="en_GB.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" LINGUAS="en_GB en_US en fi ja" MAKEOPTS="-j7" PKGDIR="/mnt/iso/Romuja/Portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/mnt/iso/Romuja/Portage" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/var/lib/layman/multimedia /var/lib/layman/enlightenment /var/lib/layman/java-overlay /var/lib/layman/pro-audio /var/lib/layman/lcd-filtering /var/lib/layman/glc /var/lib/layman/stuff /var/lib/layman/sunrise /usr/local/portage" SYNC="rsync://rsync.fi.gentoo.org/gentoo-portage" USE="3dnow 3dnowext X aac aalib accessibility acl acpi alsa amd64 anthy apng berkdb bzip2 cairo cdda cdr cdrom cjk cleartype cli consolekit corefonts cracklib crypt cups cxx dbus declarative device-mapper dirac dri dvb dvd encode exceptions extras ffmpeg flac fortran g15 gd gdbm gdu gif gimp glib gmplayer gnutls gphoto2 gpm gstreamer gtk iconv immqt-bc jack jackmidi java jpeg jpeg2k kde lame lcd lcdfilter libcaca lm_sensors midi mmx mmxext mng modules mp3 mp4 mpd mpeg mplayer mudflap multilib mysql ncurses nls npp nptl nptlonly nsplugin ogg openal opengl openmp pae pam pcntl pcre perl png policykit pppd python qt3support qt4 readline reflection schroedinger scim session sql sqlite sse sse2 sse4a ssl ssse3 svg sysfs tcpd threads truetype type3 udev uim unicode v4l vorbis webkit x264 xml xorg xvid zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump" CAMERAS="canon" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="evdev" KERNEL="linux" LCD_DEVICES="g15" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="en_GB en_US en fi ja" PHP_TARGETS="php5-3" PYTHON_TARGETS="python3_2 python2_7" RUBY_TARGETS="ruby18 ruby19" USERLAND="GNU" VIDEO_CARDS="nvidia" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON ================================================================= Package Settings ================================================================= x11-libs/libxcb-9999 was built with the following: USE="(multilib) -doc (-selinux) -static-libs"
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.
(In reply to comment #4) > 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. Ah, yes, makes sense. It's not the first time I forget to think about the emul-linux packages (had an issue with certain applications in the past, that would be fixed when one or more of these (methinks it was the sdl one back then) was updated)... So do I understand it correct, that the emul-linux-x86-xlibs package needs updating for this to take effect for the amd64 users? I never really looked into those yet, but they seem quite simple 'collections' of libraries indeed.
Comment on attachment 325470 [details] x11-libs/libxcb-9999 build log We don't have a -9999 ebuild in the tree.
(In reply to comment #6) > Comment on attachment 325470 [details] > x11-libs/libxcb-9999 build log > > We don't have a -9999 ebuild in the tree. Indeed. I was debating if it would make any sense or not to post those logs, but I figured it's better than nothing, and could get them quickly. The purpose was to show how I tested building from git with Portage, since I noticed the official ebuild actually has fetching from git but it's not being used, I simply used that to create a temporary -9999 ebuild (I guess it's worth mentioning that the results are the same with the -1.8.1 ebuild). That is, I simply commented out the following lines: #[[ ${PV} != 9999* ]] && \ # SRC_URI="http://xcb.freedesktop.org/dist/${P}.tar.bz2" It also shows (one of the ways) how I was patching libxcb while testing. If any more logs or info is needed, I will do my best to provide them, but from what Tiziano Müller mentioned, I imagine the issue can't be fixed with this packages (libxcb), or can it? Thanks!
Forgot to add: I wonder how long it will take for upstream to put out a version with the particular commit? Meaning, should we perhaps have a bug for an -9999 ebuild, so that users who are not amd64 could have the fix via Portage already if they wanted to (or could this be that bug; it already has a possible proposal for an ebuild after all). Or would it be acceptable to simply wait it out. In any case, I'm guessing the emul-linux-x86-xlibs package is what needs a bug regarding this issue with amd64? Thanks again!
libxcb-1.9 is out with the following fixes: Alan Coopersmith (4): Fix "sppported" typo in doxygen comment for XCB_CONN_CLOSED_EXT_NOTSUPPORTED Always include "config.h" at the start of all C source files. Add AC_USE_SYSTEM_EXTENSIONS to allow use of more system functionality Return connection failure if display string specifies non-existent screen Colin Walters (1): c_client: Fix parallel-make issue creating 'man' directory Jeremy Huddleston (1): xcb_connect: launchd: Don't fall back on tcp if $DISPLAY is a path to a launchd socket Julien Danjou (4): Allow undocumented code to be built Split manpage list in two (static/built) Do not list manpages, use a wildcard Move static man to man Michael Stapelberg (1): c_client.py: generate manpages Peter Harris (1): Allow xcb_send_request with >MAX_IOV iovecs Uli Schlachter (4): Add a .gitignore for src/man/ Fix a multi-thread deadlock Include static man pages in "make dist" Release libxcb 1.9 where "Fix a multi-thread deadlock" is the most important one.
Ohoh! I didn't expect them to release a new one so soon! That is convenient indeed. Thank you for that comment, and thanks for editing the title as well! I was thinking about editing it myself since I noticed it is possible, but I wasn't sure what would be most appropriate... Still very much learning the conventions here. Thanks again!
It seems that http://cgit.freedesktop.org/xcb/libxcb/commit/?id=c3deeaf714630531d693a6a902b8dabf791858b1 introduced an incompatibility with python-3.
On closer examination the python-3 situation looks even worse, I suggest waiting until upstream addresses these issues in an 1.9.1 release possibly.
Marked the now irrelevant attachments obsolete. Indeed libxcb-1.9 does not build with python 3.2, but it does build with 2.7 seemingly fine from what I could see (tested by renaming the 1.8.1 ebuild to 1.9).
I will leave this bug strictly about the app-emulation/wine issue. The version bump will have to be deferred until upstream fixes https://bugs.freedesktop.org/show_bug.cgi?id=55690 After it is fixed in libxcb, then a separate bug can be opened to request a new version of emul-linux-x86-xlibs.
Fixed in 1.8.1-r1.
(In reply to comment #0) > Created attachment 325468 [details] > emerge --info libxcb > > I may be very far from the actual issue here, but it is what it looks > like... I was debating on filing a bug for a version bump due to the > git-version having a fix as of sept. 24, but since this issue is seemingly > blocking it (for amd64 at least), I figured something should be done about > this first. > > Since wine-1.5.10, several applications hang in a loop of sorts, and > patching libxcb with the proposed patches doesn't seem to help, that is, > when patching, compiling, and installing by using Portage. > > When doing it outside of Portage, things seem to be working. The following > commit seems to fix it as well, but only if libxcb is built following the > directions here (omitting the patching part since the commit works as well): > http://forum.winehq.org/viewtopic.php?f=2&t=17203 > > The above thread also contains more information and details of my testing. > Unfortunately, I can not currently try if everything is fine on x86 (though > perhaps I could do a x86 install via VirtualBox). > > The upstream bug: https://bugs.freedesktop.org/show_bug.cgi?id=54671 > > > commit 23911a707b8845bff52cd7853fc5d59fb0823cef > Author: Uli Schlachter <psychon@znc.in> > Date: Mon Sep 24 22:07:51 2012 +0200 > > Fix a multi-thread deadlock > > This fixes a deadlock which was seen in-the-wild with wine. > > It could happen that two threads tried to read from the socket at the > same time > and one of the thread got stuck inside of poll()/select(). > > The fix works by making sure that the writing thread doesn't steal the > reading > thread's reply. > > Debugged-by: Erich Hoover <ehoover@mines.edu> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54671 > Signed-off-by: Uli Schlachter <psychon@znc.in> > > > I'm sorry, if I'm simply missing something very obvious here, and if my > first bug reported ends up being redundant. Any clues as to how fix this or > where to go from here would be very much appreciated! > > Thank you. As workaround you should emerge wine with USE="-win32 -mono win64" but you'll need backup old wineprefix (until emul-linux-x86-xlibs will be fixed by gentoo-devs) and run your game with clean wine64 prefix.
Fixing emul-linux-x86-xlibs deadlock for app-emulation/wine (Dirty workaround #2) 1. emerge -b =x11-libs/libxcb-1.8.1-r1 in 1686 chroot 2. Copy and unpack libxcb-1.8.1-r1.tbz2 to /usr/local (xcb libraries will be in /usr/local/libxcb/usr/lib) 3. Navigate to game directory for example it will be TESV Skyrim 4. Then run game by: LD_LIBRARY_PATH=/usr/local/libxcb/usr/lib/ wine TESV.exe 5. PROFIT!!! Tested with app-emulation/wine-9999 and TESV Skyrim
(In reply to comment #17) > Fixing emul-linux-x86-xlibs deadlock for app-emulation/wine (Dirty > workaround #2) > 1. emerge -b =x11-libs/libxcb-1.8.1-r1 in 1686 chroot > 2. Copy and unpack libxcb-1.8.1-r1.tbz2 to /usr/local (xcb libraries will be > in /usr/local/libxcb/usr/lib) > 3. Navigate to game directory for example it will be TESV Skyrim > 4. Then run game by: > LD_LIBRARY_PATH=/usr/local/libxcb/usr/lib/ wine TESV.exe > 5. PROFIT!!! > Tested with app-emulation/wine-9999 and TESV Skyrim or LD_LIBRARY_PATH=/usr/local/usr/lib/ blahblah if libxcb directory wasn't be created.
(In reply to comment #18) > or LD_LIBRARY_PATH=/usr/local/usr/lib/ blahblah if libxcb directory wasn't > be > created. Yeah, that's similar to how I 'worked around' it as well, for the time being (other than using wine-1.5.9). Only difference being that I used git outside Portage, built it without installing, and then used the LD path for Wine. I haven't noticed any issues with it yet, though it's likely not the best way to go about it... Thank you all again!
*** Bug 438988 has been marked as a duplicate of this bug. ***
