Bug 206345 - wine-0.9.20 winecfg crashes
wine-0.9.20 winecfg crashes
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: wine (Show other bugs)
5
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Andreas Bierfert
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-09-13 15:46 EDT by Joe Christy
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-11-20 05:28:13 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
screenshot of garbled warning dialog (23.94 KB, image/png)
2006-09-13 15:49 EDT, Joe Christy
no flags Details
console output from commandline invocation of winecfg (564 bytes, text/plain)
2006-09-13 15:52 EDT, Joe Christy
no flags Details
A tarball of the output from strace while running winecfg (1.21 MB, application/x-bzip)
2006-09-13 15:54 EDT, Joe Christy
no flags Details
list of rpms installed while generating the prior attachments (127.21 KB, text/plain)
2006-09-13 15:57 EDT, Joe Christy
no flags Details

  None (edit)
Description Joe Christy 2006-09-13 15:46:02 EDT
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):
wine-0.9.20-1.fc5

How reproducible:
always*, on two different machines

Steps to Reproduce:
1. yum uninstall wine*
2. rm -rf ~/.wine
3. yum install wine*
4. winecfg
  
Actual results:
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.

Expected results:
winecfg runs properly, and, after selecting all its defaults, .wine is created,
and subsequent invocations of wine don't crash.

Additional info:
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
i386 GNU/Linux
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
GNU/Linux
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
strace outputs.

* 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.
Comment 1 Joe Christy 2006-09-13 15:49:39 EDT
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?
Comment 2 Joe Christy 2006-09-13 15:52:18 EDT
Created attachment 136195 [details]
console output from commandline invocation of winecfg

This was immediately post yum install wine*
Comment 3 Joe Christy 2006-09-13 15:54:12 EDT
Created attachment 136197 [details]
A tarball of the output from strace while running winecfg
Comment 4 Joe Christy 2006-09-13 15:57:01 EDT
Created attachment 136198 [details]
list of rpms installed while generating the prior attachments
Comment 5 Joe Christy 2006-09-13 16:01:09 EDT
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.
Comment 6 Andreas Bierfert 2006-09-17 03:37:24 EDT
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
%post scriplet. 

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...
Comment 7 Joe Christy 2006-09-17 21:07:00 EDT
(In reply to comment #6)
> ...
> So I don't think the problem results from something missing from the rpms.

I agree.

> ...
> 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
that's it.

> 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.
Comment 8 Andreas Bierfert 2006-11-03 19:10:33 EST
Is this still an issue?
Comment 9 Joe Christy 2006-11-06 17:49:27 EST
On a clean install of FC6, w/ wine-0.9.24-1.fc6, I see:

moby(~) winecfg
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.
Comment 10 Andreas Bierfert 2006-11-20 05:28:13 EST
Probably. If you have trouble again with this please open a new bug
report/reopen. I will close this one for now.

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