Red Hat Bugzilla – Bug 206345
wine-0.9.20 winecfg crashes
Last modified: 2007-11-30 17:11:43 EST
Description of problem:
Running winecfg after a fresh install of wine throws an exception,
puts up a garbled warning dialog window, and generally leaves an unworkable mess.
Version-Release number of selected component (if applicable):
always*, on two different machines
Steps to Reproduce:
1. yum uninstall wine*
2. rm -rf ~/.wine
3. yum install wine*
winecfg throws an exception, puts up a warning dialog window filled with
seemingly random glyphs, and either produces no .wine (after clicking the left
button in the garbled warning dialog), or produces a .wine (after clicking the
right button in the garbled warning dialog), but in this case subsequent
invocations of wine throw the same exception, put up the same garbled dialog
box, then crash.
winecfg runs properly, and, after selecting all its defaults, .wine is created,
and subsequent invocations of wine don't crash.
This occurs on both my machines:
moby(~) uname -a
Linux moby.eshu.net 2.6.17-1.2174_FC5 #1 Tue Aug 8 15:30:55 EDT 2006 i686 i686
a whitebox 2.4Mhz P4 w/ Intel d865 mobo, and
pequod(6.1) uname -a
Linux pequod 2.6.17-1.2174_JPC1 #1 Thu Aug 17 13:41:36 PDT 2006 i686 i686 i386
a Thinkpad-T42p 2379-DYU.
Using a wine-0.9.20 built from the winehq source tarball produces a wine
installation where winecfg, etc. work fine.
The winehq folks thought that it might be some missing dependencies and
suggested dl-ing the source tarball, then doing ./configure --verbose to find
the libraries that it needed. I did this and installed the libraries that it wanted.
On one machine - moby - I then built and installed wine from source.
On the other, pequod, I simply installed the neccessary rpms to make ./configure
--verbose stop complaining, but didn't build and install anything, simply
performed steps 1. - 4. above (actually I ran strace -o /tmp/winetrace/winecfg
-ff -F -tt winecfg and clicked the LH button in the dialog). Subsequently I'll
post attachments with a screenshot of the garbled dialog window, a log of the
console output, a list of the rpms installed at the time, and a tarball of the
* Another thing that's quite odd is that back on moby, after verifying that wine
built from sources doesn't display the mis-behavior, I did a make uninstall in
the wine-0.9.20 build directory and then repeated steps 1. - 4. only to discover
that the wine rpms now produce a working wine installation without the
mis-behavior. Prior to building wine from sources, I repeated steps 1. - 4. on
moby several times, adding and subtracting various rpm's, tweaking system
configurations, and corresponding w/ the winehq folks (cf.
http://bugs.winehq.org/show_bug.cgi?id=2622), etc. It is also the case that I
can repeat steps 1. - 4. on pequod and invariably produce the same mis-behavior.
Created attachment 136194 [details]
screenshot of garbled warning dialog
Could the garbling be the result of the rpm failing to run fontconfig or the
like in %post?
Created attachment 136195 [details]
console output from commandline invocation of winecfg
This was immediately post yum install wine*
Created attachment 136197 [details]
A tarball of the output from strace while running winecfg
Created attachment 136198 [details]
list of rpms installed while generating the prior attachments
PS. This could be related to one of the bugs jumbled together in
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186846, but it seemed
better to open a new bug, since 186846 is such a mish-mash.
Ok, here we go: I just took my time to read through the bug over at winehq... I
don't know why they are still thinking that the fedora packaging is broken and
that I am to stupid to pull in easy stuff like fontforge or freetype. Anyways
rest assured that to my knowledge everything needed is pulled in at build time.
So I don't think the problem results from something missing from the rpms. OTOH
winecfg here works just fine. The warning dialog is for sure not related to a
Could you do me a favour and try this:
set /proc/sys/kernel/randomize_va_space to 0
set /proc/sys/kernel/exec-shield to 0
set /proc/sys/vm/legacy_va_layout to 0
and maybe even if you get the time start with selinux disabled and if your
systems permits it disable prelinking, (or do some combinations). I suspect that
it rather has to to with one of these...
(In reply to comment #6)
> So I don't think the problem results from something missing from the rpms.
> Could you do me a favour and try this:
> set /proc/sys/kernel/randomize_va_space to 0
> set /proc/sys/kernel/exec-shield to 0
> set /proc/sys/vm/legacy_va_layout to 0
While /proc/sys/kernel/exec-shield doesn't exist on my system ( it is
incompatible with Suspend2 [which, unlike suspend, works]), I did change the
others, but no change.
> and maybe even if you get the time start with selinux disabled and if your
> systems permits it disable prelinking, (or do some combinations).
I don't use selinux (too much of a PITA). I don't really have the time to turn
off prelinking and re-install all my system, but, in any case, I last installed
and tested wine on pequod totally between prelink cron jobs, so I don't think
> I suspect that
> it rather has to to with one of these...
Well, how can we explain the fact that both my machines initially had the same
sysmptoms, but, after I built and installed wine from source on my desktop,
moby, then did a make uninstall, and re-installed the rpms, the problem went away?
I'd repeat the rpm -e, build from source tarball, make install, make uninstall,
rpm -i process on my laptop, pequod, but then I fear I wouldn't be able to
re-create the problem, perhaps until 0.9.21 comes along.
Is this still an issue?
On a clean install of FC6, w/ wine-0.9.24-1.fc6, I see:
wine: creating configuration directory '/home/joe/.wine'...
Failed to open the service control manager.
wine: '/home/joe/.wine' created successfully.
but no crashes, &c. I bet that I can just ignore the message about service
control manager, whatever that is.
Probably. If you have trouble again with this please open a new bug
report/reopen. I will close this one for now.