http://bugs.winehq.org/show_bug.cgi?id=32948
Bug #: 32948 Summary: Wine crashes on file operation in 32 bits mode Product: Wine Version: 1.5.23 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: numkem@gmail.com Classification: Unclassified
Just after upgrading to KDE 4.10 on Arch, every file diaglog inside office applications makes the application hang than it produce this stack trace.
http://bugs.winehq.org/show_bug.cgi?id=32948
--- Comment #1 from Sebastien Bariteau numkem@gmail.com 2013-02-11 06:59:12 CST --- Created attachment 43508 --> http://bugs.winehq.org/attachment.cgi?id=43508 Stacktraced produced every time
http://bugs.winehq.org/show_bug.cgi?id=32948
Sebastien Bariteau numkem@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Wine crashes on file |Wine crashes on file dialog |operation in 32 bits mode |KDE 4.10
http://bugs.winehq.org/show_bug.cgi?id=32948
--- Comment #2 from Austin English austinenglish@gmail.com 2013-02-11 13:17:30 CST --- Was wine upgraded as well, perhaps?
http://bugs.winehq.org/show_bug.cgi?id=32948
--- Comment #3 from Sebastien Bariteau numkem@gmail.com 2013-02-11 13:20:48 CST --- I'm running Arch Linux so I have the latest right now (1.5.23-2).
I've also tried with a 64 bits wine prefix and it does the same thing for office. With other software I'm not experiencing this issues since I get the generic file dialog from Wine.
http://bugs.winehq.org/show_bug.cgi?id=32948
Brian Hill brian.m.hill@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |brian.m.hill@gmail.com
--- Comment #4 from Brian Hill brian.m.hill@gmail.com 2013-02-15 11:20:54 CST --- I'm getting this as well.
Attempting to open any file dialog on Office 2010 using Wine 1.5.23 causes Office 2010 to crash. Reverting to Wine 1.5.22 fixes the problem so it does not appear to be a KDE issue.
Also using Arch Linux.
http://bugs.winehq.org/show_bug.cgi?id=32948
--- Comment #5 from Sebastien Bariteau numkem@gmail.com 2013-02-15 14:19:00 CST --- I confirm that downgrading to 1.5.22 fixes the issue.
http://bugs.winehq.org/show_bug.cgi?id=32948
--- Comment #6 from Rosanne DiMesio dimesio@earthlink.net 2013-02-15 14:43:41 CST --- I'm not getting any crash in 1.5.23, but I'm still on KDE 4.8.
Sebastien and Brian: is this with a clean 32 bit wineprefix (no overrides other than riched20, Windows version set to XP)? If it is, please run a regression test.
http://bugs.winehq.org/show_bug.cgi?id=32948
--- Comment #7 from Sebastien Bariteau numkem@gmail.com 2013-02-19 11:20:12 CST --- I've tried to do a regression test with the best of my knowledge by looking at the PKGBUILD for the wine package on Arch linux and none of the commits between 1.5.22 and 1.5.23 are being a problem.
I've used this to build Wine itself : CC="ccache gcc" CFLAGS="-g -O0" ./configure --with-x --without-gstreamer --verbose --disable-tests && make
And this to test : WINEARCH=win32 WINEPREFIX=~/.wine_test/ ./wine ~/.wine_test/drive_c/Program\ Files/Microsoft\ Office/Office12/EXCEL.EXE than trying to save a spreadsheet.
http://bugs.winehq.org/show_bug.cgi?id=32948
--- Comment #8 from Rosanne DiMesio dimesio@earthlink.net 2013-02-19 15:13:43 CST --- You didn't answer my question about a clean wineprefix.
1.5.24 is out now. Please retest with a clean wineprefix. If the problem persists, follow these instructions for running a regression test: http://wiki.winehq.org/RegressionTesting
http://bugs.winehq.org/show_bug.cgi?id=32948
--- Comment #9 from Sebastien Bariteau numkem@gmail.com 2013-03-05 06:38:07 CST --- It is indeed a clean prefix. I've tried with 1.5.25 that was released recently and I get the exact same problem.
I tried following the direction for the regression testing and I can't seem to find a bisect that would be causing the problem.
http://bugs.winehq.org/show_bug.cgi?id=32948
--- Comment #10 from Rosanne DiMesio dimesio@earthlink.net 2013-03-05 07:36:20 CST --- (In reply to comment #9)
I tried following the direction for the regression testing and I can't seem to find a bisect that would be causing the problem.
Did all the bisects turn up good, or they did all turn up bad?
http://bugs.winehq.org/show_bug.cgi?id=32948
--- Comment #11 from Sebastien Bariteau numkem@gmail.com 2013-03-05 07:37:13 CST --- They all turned up good.
http://bugs.winehq.org/show_bug.cgi?id=32948
Rosanne DiMesio dimesio@earthlink.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |UPSTREAM
--- Comment #12 from Rosanne DiMesio dimesio@earthlink.net 2013-03-05 08:01:00 CST --- (In reply to comment #11)
They all turned up good.
If Wine you compiled yourself does not have the problem, then the problem must be with the Arch packages. Report the problem to your distro.
Marking upstream.
http://bugs.winehq.org/show_bug.cgi?id=32948
Mamy Ratsimbazafy chok@archlinux.us changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |chok@archlinux.us
--- Comment #13 from Mamy Ratsimbazafy chok@archlinux.us 2013-03-06 16:49:18 CST --- Hello,
I have the same issue. It's actually the same bug as this one http://bugs.winehq.org/show_bug.cgi?id=24606
Arch is using -D_FORTIFY_SOURCE=2 by default, probably until 1.5.23 it was deactivated for wine, that's why it's only since 1.5.23 version that we have the bug.
I confirm that adding -D_FORTIFY_SOURCE=0 in the CFLAGS config of arch's wine corrects the issue.
http://bugs.winehq.org/show_bug.cgi?id=32948
jbh@alchemy.lu changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jbh@alchemy.lu
--- Comment #14 from jbh@alchemy.lu 2013-03-21 04:28:16 CDT --- As far as I know, archlinux has been using -D_FORTIFY_SOURCE=2 for a long time now. It used to patch the wine buildscript to avoid this issue, but it was removed since wine itself created a workaround. It's curious that it would become a problem again now.
http://bugs.winehq.org/show_bug.cgi?id=32948
Marcus Meissner marcus@jet.franken.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |marcus@jet.franken.de
--- Comment #15 from Marcus Meissner marcus@jet.franken.de 2013-03-21 04:31:42 CDT --- do you know what gcc commandlines happen during build?
and perhaps point at the arch build repo for checking?
http://bugs.winehq.org/show_bug.cgi?id=32948
--- Comment #16 from jbh@alchemy.lu 2013-03-21 04:32:46 CDT --- Beh, I'm actually the reason it was removed for 1.5.23... Supposedly it had been worked around in wine, and I bothered the packager to remove the fix from the archlinux build script. Sorry for the noise!
On the other hand afaik this still ought to be fixed in wine itself, so something must be wrong with the fix in wine itself.
http://bugs.winehq.org/show_bug.cgi?id=32948
--- Comment #17 from Marcus Meissner marcus@jet.franken.de 2013-03-21 04:58:48 CDT --- Then please answer my question
http://bugs.winehq.org/show_bug.cgi?id=32948
--- Comment #18 from jbh@alchemy.lu 2013-03-21 05:18:11 CDT --- (In reply to comment #15)
do you know what gcc commandlines happen during build?
This is from the output off running the archlinux buildscript below with the "export CFLAGS="${CFLAGS/-D_FORTIFY_SOURCE=2/} -D_FORTIFY_SOURCE=0"" and CXXFLAGS fix commented out.
gcc -c -I../../../wine/libs/port -I. -I../../../wine/include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wwrite-strings -Wpointer-arith -Wlogical-op -I/usr/include/freetype2 -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 -o getopt1.o ../../../wine/libs/port/getopt1.c
and perhaps point at the arch build repo for checking?
Not sure what you mean here? This is the script used by archlinux to build wine in a x86_64 (multilib) environment: https://projects.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=... reply to comment #15)
http://bugs.winehq.org/show_bug.cgi?id=32948
--- Comment #19 from jbh@alchemy.lu 2013-03-21 05:19:54 CDT --- https://projects.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=...
http://bugs.winehq.org/show_bug.cgi?id=32948
--- Comment #20 from Marcus Meissner marcus@jet.franken.de 2013-03-21 11:28:27 CDT --- the build script referenced does not match the gcc commandline posted.
e.g. it does not contain portions of this: make CFLAGS+="-mincoming-stack-boundary=2" CXXFLAGS+="-mincoming-stack-boundary=2"
Btw, if you remove the CFLAGS+= and CXXFLAGS+= adjustments from here (and move them up where you edit CFLAGS already), you probably also fix the fortify_source reenablement
http://bugs.winehq.org/show_bug.cgi?id=32948
--- Comment #21 from jbh@alchemy.lu 2013-03-22 03:10:52 CDT --- (In reply to comment #20)
the build script referenced does not match the gcc commandline posted.
e.g. it does not contain portions of this: make CFLAGS+="-mincoming-stack-boundary=2" CXXFLAGS+="-mincoming-stack-boundary=2"
Btw, if you remove the CFLAGS+= and CXXFLAGS+= adjustments from here (and move them up where you edit CFLAGS already), you probably also fix the fortify_source reenablement
The command line was from the 64bit build earlier in the script...
I can try removing the "-mincoming-stack-boundary=2" completely as it also shouldn't be needed... Don't think this has anything to do with the issue though..
https://bugs.winehq.org/show_bug.cgi?id=32948
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Distribution|--- |ArchLinux
https://bugs.winehq.org/show_bug.cgi?id=32948
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #22 from Austin English austinenglish@gmail.com --- Closing.
https://bugs.winehq.org/show_bug.cgi?id=32948
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |RESOLVED
--- Comment #23 from Austin English austinenglish@gmail.com --- This was inadvertently caught up in my unclosed bugs filter. NOTOURBUG should only be closed when fixed upstream.
Setting back to RESOLVED NOTOURBUG.
Sorry for the spam.