WineHQ Bugzilla – Bug 6547 – wine versions newer than 0.9.22 hang

Bugzilla

Last modified: 2008-01-28 13:58:20 CST

wine versions newer than 0.9.22 hang

Bug 6547 - wine versions newer than 0.9.22 hang


Summary:	wine versions newer than 0.9.22 hang

Status:	CLOSED FIXED

AppDB:	Show Apps affected by this bug
Product:	Wine
Classification:	Unclassified
Component:	-unknown
Version:	0.9.24.
Hardware:	x86-64 Linux

Importance:	P2 major
Target Milestone:	---
Assigned To:	Mr. Bugs

URL:
Keywords:	regression

Duplicates:	6648 6754 6798 6872 6875 7399 7429 8073 (view as bug list)
Depends on:
Blocks:
	Show dependency tree

Reported:	2006-10-28 21:16 CDT by Alex W. Jackson
Modified:	2008-01-28 13:58 CST (History)
CC List:	13 users (show)

See Also:
Regression SHA1:
Fixed by SHA1:
Distribution:	---
Staged patchset:

Attachments
0.9.22 and 0.9.23 strace outputs (99.09 KB, application/x-gzip) 2006-10-28 21:17 CDT, Alex W. Jackson	Details
View All Add an attachment (back traces, logs, proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description Alex W. Jackson 2006-10-28 21:16:30 CDT

The last Wine version that worked on my system (FC5 x86-64) was 0.9.22.  0.9.23
and 0.9.24 just hang forever when I attempt to run any application, including
builtin applications like winecfg.

Comment 1 Alex W. Jackson 2006-10-28 21:17:57 CDT

Created attachment 3960 [details]
0.9.22 and 0.9.23 strace outputs

Outputs of strace -ff -o when running winecfg from 0.9.22 (which works) and
from 0.9.23 (which hangs)

Comment 2 Mike McCormack 2006-10-28 22:18:12 CDT

Please do a regression analysis, as described in the "regression testing"
section of the GitWine wiki page, and tell us the ID of the commit which caused
the regression.

http://wiki.winehq.org/GitWine

Comment 3 Alexandre Julliard 2006-10-29 02:57:52 CST

Most likely the XInitThreads change. You should get a backtrace of the hanging
thread to find out which X11 function is deadlocking.

Comment 4 Alex W. Jackson 2006-10-29 03:10:59 CST

How do I do that?  I assume that I use winedbg, but how do I identify the thread
which is hung up?  I'm semi-familiar with gdb on Un*x but I have no experience
with winedbg and no experience debugging (or programming really) in Windows-land
either.

Comment 5 Alexandre Julliard 2006-10-29 03:37:05 CST

If you see the hang with winecfg or notepad then there should only be one thread
running. Otherwise a 'bt all' will show a backtrace for all the threads, you can
then see which one is inside an X11 call.

Comment 6 Alex W. Jackson 2006-10-29 04:08:09 CST

Every Wine-related process appears to be stopped at "0xffffe405 in ?? ()"  Isn't
that a (Linux) kernel space address...?  I don't have kernel-debuginfo
installed; please tell me if I'm mistaken so I can spare myself the fairly
enormous download.

Comment 7 Alex W. Jackson 2006-10-29 04:19:37 CST

The hangup is definitely occurring in wine-preloader.  Each time I attempt to
run a Wine application, after I ctrl-c the hung application a wine-preloader
process is left behind which will only die if I kill -9 it (just kill'ing it
leaves it [defunct]).  All of these processes turn out to be stopped at the
exact same (kernel space?) address when I attach gdb to them.

Comment 8 Alex W. Jackson 2006-10-29 05:21:27 CST

What am I doing wrong with winedbg?  Whether I run winecfg directly through
winedbg, or run winedbg from a separate terminal after running winecfg, I can't
get a proper backtrace.  All the thread backtraces look like this, with only two
lines:

=>1 0xffffe405 (0x00000001)
  2 0x00000000 (0x00000000)

Comment 9 Alexandre Julliard 2006-10-29 09:06:36 CST

I don't think kernel debug info would help much. Maybe you can get more
information by attaching to the hung process with gdb?

Comment 10 Alex W. Jackson 2006-10-29 14:49:06 CST

All right, I can get a full backtrace by running "gdb wine" and then attaching
it to the hung process, but the backtrace has no symbolic information, because
(I think) gdb can't automatically pick up shared libraries when you attach it to
an already-running process.

Would it help if I built wine from source so as to have the symbolic information
right in the binaries, rather than in a debuginfo package?

Comment 11 Alexandre Julliard 2006-10-30 03:24:18 CST

Building from source is probably a good idea, yes.

Comment 12 Alex W. Jackson 2006-10-30 07:07:05 CST

I've discovered that the lockup is somehow related to SCIM.  If I remove SCIM
from my profile by renaming ~/.xinput.d/, log out and log back in, Wine starts
normally.

Comment 13 Alex W. Jackson 2006-10-31 13:28:21 CST

Confirmed that the "Give XInitThreads another chance" commit is what caused the
regression (before this commit, Wine works with SCIM and does not hang)

Comment 14 Alexandre Julliard 2006-10-31 14:46:59 CST

You'll probably want to report this to the SCIM team. Did you get a meaningful
backtrace of the hang?

Comment 15 Alex W. Jackson 2006-11-01 06:29:20 CST

Sorry for posting second-hand information, but I've been told by some Japanese
users that other input methods (Canna, UIM) are also causing Wine >= 0.9.23 to
hang, not just SCIM.

Comment 16 Alexandre Julliard 2006-11-01 06:36:30 CST

That's very possible, there's a bug in Xlib where XFilterEvent calls the filters
with the display lock held, so if an IM filter gets the lock it deadlocks. I
added a workaround for the standard XIM lib, but others input methods probably
need the same treatment. If we know exactly what causes the deadlock we may be
able to find a way around it too.

Comment 17 Etsushi Kato 2006-11-08 02:37:10 CST

I think this is caused from a bug in Xlib.

See https://bugs.freedesktop.org/show_bug.cgi?id=1182, and the patch in comment
#12 (https://bugs.freedesktop.org/attachment.cgi?id=4874) should solve the problem.

Comment 18 Alexandre Julliard 2006-11-17 08:58:38 CST

*** Bug 6648 has been marked as a duplicate of this bug. ***

Comment 19 Vitaliy Margolen 2006-11-22 20:49:53 CST

*** Bug 6754 has been marked as a duplicate of this bug. ***

Comment 20 Alexandre Julliard 2006-11-28 05:57:20 CST

*** Bug 6798 has been marked as a duplicate of this bug. ***

Comment 21 Chris White 2006-11-29 09:39:45 CST

I got this in a wine-git I pulled on November 26th.  Seems to be isolated to 
Japanese IM's as stated before.  Setting XMODIFIERS to an empty value (export 
XMODIFIERS="") appears to temporarily fix this for applications.

Comment 22 Vitaliy Margolen 2006-12-11 23:42:40 CST

*** Bug 6872 has been marked as a duplicate of this bug. ***

Comment 23 Vitaliy Margolen 2006-12-12 09:10:23 CST

*** Bug 6875 has been marked as a duplicate of this bug. ***

Comment 24 Steven McCoy 2006-12-13 03:11:10 CST

*** Bug 6886 has been marked as a duplicate of this bug. ***

Comment 25 Vitaliy Margolen 2007-02-10 09:59:45 CST

It looks like Fedora Core 6 comes equipped with this bug right from the start.

Comment 26 Vitaliy Margolen 2007-02-12 19:13:19 CST

*** Bug 7399 has been marked as a duplicate of this bug. ***

Comment 27 Vitaliy Margolen 2007-02-14 20:18:45 CST

*** Bug 7429 has been marked as a duplicate of this bug. ***

Comment 28 Jos van Wolput 2007-04-14 03:51:18 CDT

Wine 0.9.35 works with SCIM.
Bug 6547 seems to be fixed!

Comment 29 Vitaliy Margolen 2007-04-14 11:10:51 CDT

Correct - it is fixed there was a workaround committed right before 0.9.35.

Comment 30 Vitaliy Margolen 2007-04-16 20:51:43 CDT

*** Bug 8073 has been marked as a duplicate of this bug. ***

Comment 31 Tony Lambregts 2007-04-27 22:14:35 CDT

Closing