Segmentation Fault in wine cvs after 0.9

[zhilla]

before submitting this as bug, some advice please...
on slackware 10.2 (gcc 3.3.6) i compile wine cvs, and it has worked so 
far. last version working is around or exactly 0.9.
now, it compiles/installs fine, but any program, including starting just 
"wine", "notepad" or anything else, ends up quickly with "Segmentation 
fault".
this is my simple custom buildscript...

PKGDATE=`date +%Y%m%d` &&
CHOST="i686-pc-linux-gnu" \
CFLAGS="-march=athlon-xp -O2 -pipe -fomit-frame-pointer -m3dnow -msse 
-mmmx" \
CXXFLAGS=$CFLAGS \
./configure \
--disable-debug && \
make && make depend && \
checkinstall -S --pkgname=wine --pkgarch=athlonxp --pkgversion=$PKGDATE -y
also, tried removing ~/.wine and creating new one, it starts automatic 
configure but compiled wine also segfaults.

then, changed processor optimizations to much more conservative
"-O2 -march=i486 -mcpu=i686"
and it it works like a charm.
athlon-xp optimizatins used in the first place are from 
http://gentoo-wiki.com/Safe_Cflags . if gentoo people claim these are 
safe cflags, and it worked until couple days ago, then something is 
definetly wrong, right?

[Dmitry Timoshkov]

"zhilla" <zhilla(a)spymac.com> wrote:
> then, changed processor optimizations to much more conservative
> "-O2 -march=i486 -mcpu=i686"
> and it it works like a charm.
> athlon-xp optimizatins used in the first place are from 
> http://gentoo-wiki.com/Safe_Cflags . if gentoo people claim these are 
> safe cflags, and it worked until couple days ago, then something is 
> definetly wrong, right?

When somebody plays with compiler flags it's definitely wrong. If you
are brave enough to use custom compiler switches you are must be qualified
enough to cope with any problems caused by that. Feel free to debug it on
your own. It's most likely that -fomit-frame-pointer is the culprit.

-- 
Dmitry.

[Mike McCormack]

zhilla wrote:
> http://gentoo-wiki.com/Safe_Cflags . if gentoo people claim these are 
> safe cflags, and it worked until couple days ago, then something is 
> definetly wrong, right?

This is the wrong type of question for wine-devel, and better asked in 
Gentoo forums or wine-users.

Mike

[zhilla]

Mike McCormack wrote:
> > http://gentoo-wiki.com/Safe_Cflags . if gentoo people claim these are 
> > safe cflags, and it worked until couple days ago, then something is 
> > definetly wrong, right?
> > This is the wrong type of question for wine-devel, and better asked in 
> > Gentoo forums or wine-users.

why it is wrong? developers are much more likely to know about compiler 
flags than users, and gentooers probably use much more bleeding edge 
version of gcc anyway (slack uses 3.3.6)
thanks dmitry for the tip, ill do some further testing.
and yeah, i forgot to mention those flags work great for any program i 
_ever_ tried to compile myself.

[Mike McCormack]

zhilla wrote:
> why it is wrong? developers are much more likely to know about compiler 
> flags than users, and gentooers probably use much more bleeding edge 
> version of gcc anyway

The way developers recommend compiling Wine is explained in the README 
file.  If you want our help, please try our recommendation first.

Mike

[Peter Beutner]

Mike McCormack schrieb:
> zhilla wrote:
> > http://gentoo-wiki.com/Safe_Cflags . if gentoo people claim these are
> > safe cflags, and it worked until couple days ago, then something is
> > definetly wrong, right?
>
> This is the wrong type of question for wine-devel, and better asked in
> Gentoo forums or wine-users.
> heh?
> why should that be discussed in gentoo forums?

And it's not like -fomit-frame-pointer is such a high-risky optimization flag.
Instead it is in general safe to use for 90% of applications out there( it basicly only
prevents that you get some useful debug traces, by saving a few instructions)
And like already stated, it used to work in wine too. Until some days ago.
So why shouldn't that reported here?

Just for the record:
I can confirm the segmentation fault(gcc 3.4.4), when compiled with -fomit-frame-pointer.
I will try to find out which patch has caused this.

[Mike McCormack]

Peter Beutner wrote:
> And it's not like -fomit-frame-pointer is such a high-risky optimization flag.
> Instead it is in general safe to use for 90% of applications out there

If it fails for 10% of applications out there, then it's *not* safe!

(it basicly only prevents that you get some useful debug traces, by 
saving a few instructions)

I think turning off the debugging features of Wine isn't such a great 
idea, and not something that should be encouraged.  The more people that 
do that, the more useless crash reports Wine developers will get.
> And like already stated, it used to work in wine too. Until some days ago.
> So why shouldn't that reported here?

If somebody wants to report that an unsupported flag makes Wine not 
work, then he should figure out the exact patch and flag combination 
that caused the regression, and that's the information that should be 
posted to WineHQ.
> Just for the record:
> I can confirm the segmentation fault(gcc 3.4.4), when compiled with -fomit-frame-pointer.
> I will try to find out which patch has caused this.

That would be a great idea.

Mike

[Peter Beutner]

Mike McCormack schrieb:
> Peter Beutner wrote:
> > And it's not like -fomit-frame-pointer is such a high-risky
> > optimization flag.
> > Instead it is in general safe to use for 90% of applications out there
>
> If it fails for 10% of applications out there, then it's *not* safe!
> The question is how often it only exposes a bug in the application(like in this case). ;)
> (it basicly only prevents that you get some useful debug traces, by
> saving a few instructions)
>
> I think turning off the debugging features of Wine isn't such a great
> idea, and not something that should be encouraged.  The more people that
> do that, the more useless crash reports Wine developers will get.

On the other hand the possibility to optimize wine isn't that bad either.
So just tell the users to send only crash reports from builds with debugging infos enabled.;)
> > And like already stated, it used to work in wine too. Until some days
> > ago.
> > So why shouldn't that reported here?
>
> If somebody wants to report that an unsupported flag makes Wine not
> work, then he should figure out the exact patch and flag combination
> that caused the regression, and that's the information that should be
> posted to WineHQ.
> then why not tell him that?
> Besides there is nowhere stated that there are only certain supported compiler flags which
> you should use.
> > Just for the record:
> > I can confirm the segmentation fault(gcc 3.4.4), when compiled with
> > -fomit-frame-pointer.
> > I will try to find out which patch has caused this.
>
> That would be a great idea.

Somebody was faster, there was just sent a patch which fixes the problem.
http://www.winehq.org/pipermail/wine-patches/2005-November/021883.html
> Mike

[Mike McCormack]

Peter Beutner wrote:
> Besides there is nowhere stated that there are only certain supported compiler flags which
> you should use.

Correct. Using any compiler flags other than what configure adds by 
default is unsupported, untested and unreliable.  Even seemingly 
harmless flags such as "-Wall" cause trouble.

Mike

[Marcus Meissner]

On Sun, Nov 06, 2005 at 11:39:44PM +0100, Peter Beutner wrote:
> Mike McCormack schrieb:
> > zhilla wrote:
> > > http://gentoo-wiki.com/Safe_Cflags . if gentoo people claim these are
> > > safe cflags, and it worked until couple days ago, then something is
> > > definetly wrong, right?
> >
> > This is the wrong type of question for wine-devel, and better asked in
> > Gentoo forums or wine-users.
> > heh?
> > why should that be discussed in gentoo forums?
>
> And it's not like -fomit-frame-pointer is such a high-risky optimization flag.
> Instead it is in general safe to use for 90% of applications out there( it basicly only
> prevents that you get some useful debug traces, by saving a few instructions)
> And like already stated, it used to work in wine too. Until some days ago.
> So why shouldn't that reported here?
>
> Just for the record:
> I can confirm the segmentation fault(gcc 3.4.4), when compiled with -fomit-frame-pointer.
> I will try to find out which patch has caused this.

The problem could be a patch, or it could be something else.

While -fomit-frame-pointer is a no-risk option in other programs, this is not the case for WINE.

Why?

Because we call binary code.

And occasionaly this code assumes values in the %ebp register. The best
example is EXC_CallHandler() for instance, where windows code looks at
the %ebp framechain.

One reason while it is implemented in assembler now.

So please try current CVS after Robs last patch has been applied.

Ciao, Marcus

On Sun, 06 Nov 2005 05:29:02 +0100, zhilla <zhilla(a)spymac.com> wrote:
> before submitting this as bug, some advice please...
> on slackware 10.2 (gcc 3.3.6) i compile wine cvs, and it has worked so  
> far. last version working is around or exactly 0.9.
> now, it compiles/installs fine, but any program, including starting just  
> "wine", "notepad" or anything else, ends up quickly with "Segmentation  
> fault".
> this is my simple custom buildscript...
>
> PKGDATE=`date +%Y%m%d` &&
> CHOST="i686-pc-linux-gnu" \
> CFLAGS="-march=athlon-xp -O2 -pipe -fomit-frame-pointer -m3dnow -msse  
> -mmmx" \
> CXXFLAGS=$CFLAGS \
> ./configure \
> --disable-debug && \
> make && make depend && \
> checkinstall -S --pkgname=wine --pkgarch=athlonxp --pkgversion=$PKGDATE  
> -y
> also, tried removing ~/.wine and creating new one, it starts automatic  
> configure but compiled wine also segfaults.
>
> then, changed processor optimizations to much more conservative
> "-O2 -march=i486 -mcpu=i686"
> and it it works like a charm.
> athlon-xp optimizatins used in the first place are from  
> http://gentoo-wiki.com/Safe_Cflags . if gentoo people claim these are  
> safe cflags, and it worked until couple days ago, then something is  
> definetly wrong, right?

well if you have to pretend your Athlon-xp is a 486 to get wine to work I  
would say there's a problem that needs looking at but you probably should  
pin it down a bit more precisely before reporting it.

you should also look at gcc doc to see what all these things mean before  
playing with them. Your post indicates you dont know much about CFLAGS  
apart from what someone added to a wiki page, although I would say those  
recommendations (rather than what you posted) have been very good for me  
on Gentoo with Athlon-xp for a couple of years.

I have not tried winecvs since 0.9

HTH

On Sun, 06 Nov 2005 19:11:26 +0100, <wino(a)piments.com> wrote:
> On Sun, 06 Nov 2005 05:29:02 +0100, zhilla <zhilla(a)spymac.com> wrote:
> > before submitting this as bug, some advice please...
> well if you have to pretend your Athlon-xp is a 486 to get wine to work  
> I would say there's a problem that needs looking at but you probably  
> should pin it down a bit more precisely before reporting it.
>
> you should also look at gcc doc to see what all these things mean before  
> playing with them. Your post indicates you dont know much about CFLAGS  
> apart from what someone added to a wiki page, although I would say those  
> recommendations (rather than what you posted) have been very good for me  
> on Gentoo with Athlon-xp for a couple of years.
>
> I have not tried winecvs since 0.9
>
> HTH

Re.
> > > CFLAGS="-march=athlon-xp -O2 -pipe -fomit-frame-pointer -m3dnow -msse
> > > -mmmx" \

You asked for advice, I wont say RTFM, I'll just quote it:

http://gcc.gnu.org/onlinedocs/gcc-3.4.1/gcc/i386-and-x86-64-Options.html#i38...

-mtune=cpu-type
Tune to cpu-type everything applicable about the generated code, except  
for the ABI and the set of available instructions. The choices for  
cpu-type are:
.....
athlon-4, athlon-xp, athlon-mp
Improved AMD Athlon CPU with MMX, 3dNOW!, enhanced 3dNOW! and full SSE  
instruction set support.
.....
-march=cpu-type
Generate instructions for the machine type cpu-type. The choices for  
cpu-type are the same as for -mtune. Moreover, specifying -march=cpu-type  
implies -mtune=cpu-type.

-mcpu=cpu-type
A deprecated synonym for -mtune.


Please dont compound the idea that all Gentoo users are cflag-psycopaths.  
;)

[Christoph Frick]

On Sun, Nov 06, 2005 at 05:29:02AM +0100, zhilla wrote:
> before submitting this as bug, some advice please...
> on slackware 10.2 (gcc 3.3.6) i compile wine cvs, and it has worked so 
> far. last version working is around or exactly 0.9.
> now, it compiles/installs fine, but any program, including starting just 
> "wine", "notepad" or anything else, ends up quickly with "Segmentation 
> fault".
> this is my simple custom buildscript...

i can confirm this. i use -mtune=athlon-tbird but somewhere after
between 20050930 and CVS-current this "error" slipped into wine. i can
not easily test against the patch, that did this to wine. so far the
funny thing i came around:
WINEDEBUG=+all wine 
and everything works.

i tried gdb wine-pthread. and it seems to crash somewhere in the locale
detection - but the stack is smashed there allready. i will try the
"trick" with the non-athlon cflags also on my end and report back.

oh well and btw: gcc 4.0.2.pre (or so) is my compiler.
> PKGDATE=`date +%Y%m%d` &&
> CHOST="i686-pc-linux-gnu" \
> CFLAGS="-march=athlon-xp -O2 -pipe -fomit-frame-pointer -m3dnow -msse 
> -mmmx" \
> CXXFLAGS=$CFLAGS \
> ./configure \
> --disable-debug && \
> make && make depend && \
> checkinstall -S --pkgname=wine --pkgarch=athlonxp --pkgversion=$PKGDATE -y
> also, tried removing ~/.wine and creating new one, it starts automatic 
> configure but compiled wine also segfaults.
>
> then, changed processor optimizations to much more conservative
> "-O2 -march=i486 -mcpu=i686"
> and it it works like a charm.
> athlon-xp optimizatins used in the first place are from 
> http://gentoo-wiki.com/Safe_Cflags . if gentoo people claim these are 
> safe cflags, and it worked until couple days ago, then something is 
> definetly wrong, right?

-- 
cu

On Mon, 07 Nov 2005 10:25:17 +0100, Christoph Frick <frick(a)sc-networks.de>  
wrote:
> oh well and btw: gcc 4.0.2.pre (or so) is my compiler.

come on fellas! now you're using unstable , pre-release compilers.

please dont waste time here. There enough true disfunctionality in Wine  
that needs to be tracked down and corrected without deliberately trying to  
break things.

[Christoph Frick]

On Mon, Nov 07, 2005 at 12:31:37PM +0100, wino(a)piments.com wrote:
> > oh well and btw: gcc 4.0.2.pre (or so) is my compiler.
> > come on fellas! now you're using unstable , pre-release compilers.
> > please dont waste time here. There enough true disfunctionality in Wine  
> > that needs to be tracked down and corrected without deliberately trying to  
> > break things.

sorry this compiler came with the distribution - i have no other choice.
i also have the impression, that its quite common to linux distributions
to use the latest alpha-code to impress the with the high version
numbers on the box.

i used various gcc versions over the last years but always used the same
compiler flags - never had any problems until last week after the 0.9
release. if -fomit-frame-ponters is the culprit and wine will from now
on never ever work with this setting, then add a error to the
configure or warn-and-remove from the CFLAGS; but if the resulting code
from the same compiler works fine with 20050830 and 20050920 and even
with post-09-cvs when using WINEDEBUG=+all, then something is fishy in
wine and at least its good to talk about it... and prevent this in the
future. obviously also others had the problem with "released" compilers.

-- 
cu

On Mon, 07 Nov 2005 14:17:13 +0100, Christoph Frick <frick(a)sc-networks.de>  
wrote:
> something is fishy in
> wine and at least its good to talk about it... and prevent this in the
> future.

quite so, I think this got sorted pretty quickly by Rob so the patch  
should get into cvs to solve the anomoly.
> i also have the impression, that its quite common to linux distributions
> to use the latest alpha-code to impress the with the high version
> numbers on the box.

well I dont know who works like that but they'd better make sure whatever  
is one the box works once installed since no-one will remain impressed for  
long and there's a world of choice now.

BTW what distro are you using?