Red Hat Bugzilla – Bug 441521
Starting wine freezes X the desktop
Last modified: 2008-06-12 04:47:45 EDT
Description of problem:
The system freezes when I run from gnome-terminal
With the freeze Ctrl-Alt-Backspace does not work and I can not use Ctrl-Alt-Fn
to switch to a virtual console.
Version-Release number of selected component (if applicable):
This is with rawhide with all updates as of 2008-04-08 12:00 UTC. I run rawhide
installed on my Dell Latitude-X1 notebook with 1.1GHz CPU and 1128MB RAM.
Install wine with rawhide and run wine notepad.exe.
Could you please add more information based on the reporting bug part of
wine version: 0.9.58
Selinux mode: enforcing
Window manager: gnome-session with metacity
wine works fine with fresh ~/.wine. With ~/.wine that I used in F8 it freezes
the system. This is hard freeze as I cannot ping the system and the following
script that I run in the background:
while true; do
date +%T >> $HOME/log.txt
after the reboot shows the time of the crash in ~/log.txt. Also after the crash
there is no disk activity as shown by a notebook indicator.
So it looks like a kernel bug. Should I change the component? I can also can try
to attach .wine after removing a windows application installed there.
Created attachment 301664 [details]
system.reg that causes the system freeze
The content of the attached .wine/system.reg causes the freeze. That is,
rm -rf ~/.wine
creates the default ~/.wine and runs notepad.exe normally. But replacing
.wine/system.reg with the attached file triggers the whole system freeze when
running "wine notepad.exe".
Created attachment 301687 [details]
minimal crashing system.reg
The attached system.reg contains single entry:
"Description"="Loads files to memory for later printing."
Using the file as ~/.wine/system.reg causes a total system freeze when running
"wine notepad.exe". The crash happens with a wireless networking enabled or
with networking disabled as set with NetworkManager.
Note that a default system.reg generated after
rm -rf ~/.wine; wine notepad.exe
does not contain the entry.
Thanks for the good bug report. I will see what I can do about this.
(In reply to comment #5)
> Thanks for the good bug report. I will see what I can do about this.
If necessary I can give an access to the notebook over ssh.
(In reply to comment #4)
> The attached system.reg contains single entry:
> [System\\CurrentControlSet\\Services\\Spooler] 1181644148
Removing that entry from the original system.reg file also fixes the issue and
the Windows application runs normally.
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
In reply to Comment #4:
That is not true. A newly generated ~/.wine/system.reg does have that Spooler
The difference is that the newly generated functional one has a:
instead of the non-functional old:
Changing that single number (and doing a 'service wine restart' just for fun)
made my wine work again.
I think the wine devs went a little too far in emulating MSWindows behaviour
when a -2 can bring down the entire OS rather than just crash wine ;]
Several people suffer from this bug, a bug was listed at wine:
But it was "closed invalid"
Quote: "Wine can't freeze your system, that's most likely a kernel driver bug."
Strangely enough this bug only occurs when wine preforms. Also, this bug occurs
on computers with different architectures, with complete different hardware...
Can you add a reference to this Fedora bug number in that upstream bug?
It contains a specific triggering mechanism that might enable the developers to
reproduce it and narrow down what is at fault.
I added the link to this bug in a comment at wine's Bugzilla, wine does not have
a upstream resolution.
Does anyone know already if this is a kernel bug or a x11 bug?
Any way this can get a priority boost?
It's rather insulting to Wine folks that a bug in FC9 that causes
a system crash is rated as priority 'low', severity 'low'.
Wine runs completely in user space, so by definition, anything it does
that causes a system freeze is *not* a Wine bug.
same issue here: https://bugzilla.redhat.com/show_bug.cgi?id=443552 ... that one
has at least correct severity ;-)
I added some kernel oopsies with 18.104.22.168-30.fc9.i686 and wine-1.0-rc4 there.
*** This bug has been marked as a duplicate of 443552 ***