[Bug 17406] New: Lord of the Rings Online and STEAM using wine 1.1.14 built against 2.6.28 kernel headers cannot access network
http://bugs.winehq.org/show_bug.cgi?id=17406
Summary: Lord of the Rings Online and STEAM using wine 1.1.14 built against 2.6.28 kernel headers cannot access network Product: Wine Version: 1.1.14 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: sandalle@sourcemage.org
One of my machines has glibc built against the Linux kernel 2.6.28 sanitized headers. After building WINE 1.1.14 (and 1.1.15), two programs I use (STEAM and Lord of the Rings Online (LotRO)) can no longer connect to the Internet. If I switch back to WINE 1.1.13, the applications work.
Another machine has glibc built against the Linux kernel 2.6.27 sanitized headers. WINE 1.1.13, 1.1.14, and 1.1.15 all operate normally.
I am currently testing switching the first machine from 2.6.28 sanitized headers to 2.6.25 (getting them to 2.6.27 would require more work, but I plan on doing this "eventually" anyways as 2.6.28 headers are causing issues with other programs as well).
I tried reinstalling LotRO with WINE 1.1.15 to see if a clean WINEPREFIX fixes this, but the problem persists.
All packages used above were compiled with the upstream sources. I will try the regression tests after confirming if switching to 2.6.25 sanitized headers also fixes this (to show it is, indeed, the 2.6.28 headers). Either way, a regression test should be run since WINE 1.1.13 runs fine, but 1.1.14 and 1.1.15 fail to run.
Downloads: LotRO Trial:http://www.lotro.com/trial/index.php STEAM: http://storefront.steampowered.com/download/SteamInstall.msi
http://bugs.winehq.org/show_bug.cgi?id=17406
--- Comment #1 from Eric Sandall sandalle@sourcemage.org 2009-02-15 15:05:01 --- I should note that WINE itself can access the network, as tested by running `wine iexplore.exe http://winehq.org/%60.
http://bugs.winehq.org/show_bug.cgi?id=17406
--- Comment #2 from Eric Sandall sandalle@sourcemage.org 2009-02-15 15:28:08 --- Building wine against 2.6.25 sanitized headers didn't fix it, so I think rebuilding the whole system would be required for that test. Switching back to 2.6.28 sanitized headers and running the regression tests instead. :)
http://bugs.winehq.org/show_bug.cgi?id=17406
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |INVALID
--- Comment #3 from Vitaliy Margolen vitaliy@kievinfo.com 2009-02-15 15:34:34 --- Sounds like a bug in your system not Wine. Since the only thing changes is kernel/headers/building process and not Wine itself.
Closing invalid. You are welcome to reopen if you have the patch that "broke" Wine for you.
http://bugs.winehq.org/show_bug.cgi?id=17406
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #4 from Dmitry Timoshkov dmitry@codeweavers.com 2009-02-16 01:01:23 --- You can start with comparing config.log files from a working and a not working build. Also it's not clear what "sanitized headers" mean, you may also try to find out what is the difference from normal ones.
http://bugs.winehq.org/show_bug.cgi?id=17406
--- Comment #5 from Eric Sandall sandalle@sourcemage.org 2009-02-16 13:46:28 --- I'll keep fiddling. I believe Vitaliy Margolen might be correct as I just built wine 1.1.15 from a git checkout (using the tag) and no configure options connected fine. So perhaps one of our optional packages is breaking WINE 1.1.14+.
The sanitized headers are using the userland kernel headers to build glibc (e.g. the headers installed by 2.6.28). I noticed that one box using 2.6.27 headers worked fine and another using 2.6.28 was broken, but that may be unrelated. ;)
http://bugs.winehq.org/show_bug.cgi?id=17406
Eric Sandall sandalle@sourcemage.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |UNCONFIRMED Resolution|INVALID |
--- Comment #6 from Eric Sandall sandalle@sourcemage.org 2009-02-17 02:25:55 --- I found the issue, but not which commit breaks it since 1.1.13. If I compile with -O3 in my CFLAGS/CXXFLAGS I run into this bug. WINE 1.1.13 builds and runs fine with -O3, it's not until 1.1.14 (and 1.1.15) that WINE has this issue.
I'll go through the git bisects as mentioned on http://wiki.winehq.org/RegressionTesting and see which patch breaks this.
http://bugs.winehq.org/show_bug.cgi?id=17406
Eric Sandall sandalle@sourcemage.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Lord of the Rings Online and|Lord of the Rings Online |STEAM using wine 1.1.14 |fails to connect to the |built against 2.6.28 kernel |Internet if WINE 1.1.14 is |headers cannot access |built with -O3 |network |
http://bugs.winehq.org/show_bug.cgi?id=17406
--- Comment #7 from Eric Sandall sandalle@sourcemage.org 2009-02-17 15:26:12 --- According to the regression testing, this is the culprit:
4be41680a3e18ea2b295415398fad25ac396a984 is first bad commit commit 4be41680a3e18ea2b295415398fad25ac396a984 Author: Andrew Talbot andrew.talbot@talbotville.com Date: Wed Jan 21 22:08:39 2009 +0000
rsaenh: Declare some functions static.
:040000 040000 70110a79b212c87f9981b94b1193bcb0d953240e 32935260eb81d986494dad4034d8ede652192ce3 M dlls
http://bugs.winehq.org/show_bug.cgi?id=17406
--- Comment #8 from Dmitry Timoshkov dmitry@codeweavers.com 2009-02-17 21:53:03 --- (In reply to comment #7)
According to the regression testing, this is the culprit: 4be41680a3e18ea2b295415398fad25ac396a984 is first bad commit commit 4be41680a3e18ea2b295415398fad25ac396a984 Author: Andrew Talbot andrew.talbot@talbotville.com Date: Wed Jan 21 22:08:39 2009 +0000 rsaenh: Declare some functions static.
Please try again, that patch is no-op, and can't be the source of any problem.
http://bugs.winehq.org/show_bug.cgi?id=17406
--- Comment #9 from Eric Sandall sandalle@sourcemage.org 2009-02-18 02:25:44 --- Another try, this time marking commits that fail to even build as bad, gives me this:
8e16e7871063df35ca3a6de6fb165767c00bd087 is first bad commit commit 8e16e7871063df35ca3a6de6fb165767c00bd087 Author: Alexandre Julliard julliard@winehq.org Date: Mon Jan 19 19:57:59 2009 +0100
libwine: Re-generate the Windows codepage data using the bestfit files.
:040000 040000 62180b43ff5e9edfdcc507c84446e5bc90226df1 c12ac4f2ae9cd3948c74f3e80fb32cfbf04ee887 M dlls :040000 040000 dac94cc7c0b7ee0bb2ad979416d1a52cce3fc43f ad051f5e030c3cf66cb9a308401c367ac41c2add M libs
Yet even testing that one worked. I'll try yet again. ;)
http://bugs.winehq.org/show_bug.cgi?id=17406
--- Comment #10 from Eric Sandall sandalle@sourcemage.org 2009-02-18 04:47:14 --- Created an attachment (id=19527) --> (http://bugs.winehq.org/attachment.cgi?id=19527) git-bisect log leading to 8e16e7871063df35ca3a6de6fb165767c00bd087 (not likely)
Here's the `git bisect log` which leads to: 8e16e7871063df35ca3a6de6fb165767c00bd087 is first bad commit commit 8e16e7871063df35ca3a6de6fb165767c00bd087 Author: Alexandre Julliard julliard@winehq.org Date: Mon Jan 19 19:57:59 2009 +0100
libwine: Re-generate the Windows codepage data using the bestfit files.
:040000 040000 62180b43ff5e9edfdcc507c84446e5bc90226df1 c12ac4f2ae9cd3948c74f3e80fb32cfbf04ee887 M dlls :040000 040000 dac94cc7c0b7ee0bb2ad979416d1a52cce3fc43f ad051f5e030c3cf66cb9a308401c367ac41c2add M libs
Which I doubt is the culprit.
http://bugs.winehq.org/show_bug.cgi?id=17406
--- Comment #11 from Eric Sandall sandalle@sourcemage.org 2009-02-18 04:48:54 --- Created an attachment (id=19528) --> (http://bugs.winehq.org/attachment.cgi?id=19528) git-bisect log leading to 4be41680a3e18ea2b295415398fad25ac396a984
Here's the `git bisect log` leading to: 4be41680a3e18ea2b295415398fad25ac396a984 is first bad commit commit 4be41680a3e18ea2b295415398fad25ac396a984 Author: Andrew Talbot andrew.talbot@talbotville.com Date: Wed Jan 21 22:08:39 2009 +0000
rsaenh: Declare some functions static.
:040000 040000 70110a79b212c87f9981b94b1193bcb0d953240e 32935260eb81d986494dad4034d8ede652192ce3 M dlls
Which apparently is a no-op. Both logs were made with the following command being run after each bisect: make distclean && CFLAGS='-march=nocona -m32 -pipe -DPIC -fPIC -O3' CXXFLAGS='-march=nocona -m32 -pipe -DPIC -fPIC -O3' LDFLAGS='-z combreloc -s -Wl,-O1' ./configure && make -j3 && LotROLinux
http://bugs.winehq.org/show_bug.cgi?id=17406
--- Comment #12 from Austin English austinenglish@gmail.com 2009-02-18 11:15:00 --- (In reply to comment #9)
Another try, this time marking commits that fail to even build as bad, gives me this:
That would be a separate regression, you can only test for one at a time.
Please test your results by reverting the commit before posting more false results.
http://bugs.winehq.org/show_bug.cgi?id=17406
--- Comment #13 from Eric Sandall sandalle@sourcemage.org 2009-02-18 23:46:06 --- Yeah, I know that'd be a separate regression, that's why I mentioned how I got there, but I've tried the "real way" twice now with the same results, only to be told that's a no-op and now a false result.
Perhaps you can tell me, short of testing all 303 patches between 1.1.13 and 1.1.14, the true way to find the bug? If I am doing the testing wrong, by all means please correct me.
http://bugs.winehq.org/show_bug.cgi?id=17406
--- Comment #14 from knan-wine@anduin.net 2009-02-24 14:14:17 --- Try "git bisect skip" for non-buildable revisions.
http://bugs.winehq.org/show_bug.cgi?id=17406
Rafał Mużyło galtgendo@o2.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |galtgendo@o2.pl
--- Comment #15 from Rafał Mużyło galtgendo@o2.pl 2009-03-04 13:34:13 --- This will seem unrelated and most probably it is, but what is your compiler version ?
http://bugs.winehq.org/show_bug.cgi?id=17406
--- Comment #16 from Rafał Mużyło galtgendo@o2.pl 2009-03-06 09:06:36 --- My question is cause I think you may be running into a compiler bug. If so, a certain no-op may not be a no-op after all.
http://bugs.winehq.org/show_bug.cgi?id=17406
--- Comment #17 from Eric Sandall sandalle@sourcemage.org 2009-03-06 11:13:55 --- I am using GCC 4.3.2. The only item changed from working to non-working is the WINE version. I haven't tried a new git bisect yet.
http://bugs.winehq.org/show_bug.cgi?id=17406
--- Comment #18 from Rafał Mużyło galtgendo@o2.pl 2009-03-06 11:30:14 --- So, does the problem still happen in 1.1.16 ?
And as for my theory, the (possible) bug I referred to should have been in 4.3.3 only, so this is probably not the case, still if the bug is reproducible with 1.1.16 and is not wine_gecko related, could you see if adding -fno-inline to CFLAGS helps ?
http://bugs.winehq.org/show_bug.cgi?id=17406
--- Comment #19 from Eric Sandall sandalle@sourcemage.org 2009-03-06 11:33:28 --- I haven't tried with 1.1.16, I'll try to do that tonight, along with the possible -fno-inline fix.
http://bugs.winehq.org/show_bug.cgi?id=17406
--- Comment #20 from Eric Sandall sandalle@sourcemage.org 2009-03-06 20:41:45 --- WINE 1.1.16 still has this issue, but using -fno-inline allows it to compile with -O3 again, thanks. :)
http://bugs.winehq.org/show_bug.cgi?id=17406
--- Comment #21 from Rafał Mużyło galtgendo@o2.pl 2009-03-06 20:59:38 --- That's very good...no, wait. That really sucks.
Now please do one more test: instead of -fno-inline use -fno-guess-branch-probability.
Please do it as soon as possible and if it still succeeds, post your exact gcc version (output of 'gcc -v').
http://bugs.winehq.org/show_bug.cgi?id=17406
--- Comment #22 from Eric Sandall sandalle@sourcemage.org 2009-03-07 02:48:05 --- Using '-fno-guess-branch-probability' also worked:
make[2]: Entering directory `/usr/src/wine-1.1.16/libs/port' gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wtype-limits -Wpointer-arith -fno-guess-branch-probability -march=nocona -m32 -pipe -DPIC -fPIC -O3 -o ffs.o ffs.c
$ gcc -v Reading specs from /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/specs Target: i686-pc-linux-gnu Configured with: /usr/src/gcc-4.3.2/configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --enable-threads=posix --with-system-zlib --build=i686-pc-linux-gnu Thread model: posix gcc version 4.3.2 (GCC)
http://bugs.winehq.org/show_bug.cgi?id=17406
--- Comment #23 from Rafał Mużyło galtgendo@o2.pl 2009-03-07 08:14:53 --- Given this info, I suspect that comment 7 was actually correct - due to a compiler bug that commit was not a no-op.
However, if that actually the case, there's no real fix for that that can be done in wine, as it's nearly impossible to tell in how many places in the code similar problems happen.
A while ago, I've opened a similar bug about freeciv in gcc bugzilla, now it seems that more apps are affected.
http://bugs.winehq.org/show_bug.cgi?id=17406
haarp liquitsnake@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |liquitsnake@gmx.net
--- Comment #24 from haarp liquitsnake@gmx.net 2009-03-07 11:33:29 --- *** Bug 17421 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=17406
--- Comment #25 from Eric Sandall sandalle@sourcemage.org 2009-03-07 13:29:28 --- If it's a GCC bug, should we link to the upstream bug? I can add '-fno-guess-branch-probability' to our package to work around this issue for now.
http://bugs.winehq.org/show_bug.cgi?id=17406
Andrew Talbot Andrew.Talbot@talbotville.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Andrew.Talbot@talbotville.co | |m
--- Comment #26 from Andrew Talbot Andrew.Talbot@talbotville.com 2009-03-12 15:15:55 --- I am attaching a set of patches that may help to determine the specific cause of the problem. The attached archive contains one patch - "init.diff" - that reorders the functions to avoid forward references and six other patches: one for each function that was made static in the original patch.
I suggest winding the build back to just before the identified patch was applied, and then applying the "init.diff" patch followed by one of the other patches as in the following example.
git reset --hard 2a0e659335ecf1d8967c75c9efe164c2d9d0214c git apply init.diff git apply mp_mod_2d.diff
Do the above and do a build for each of the six patches - each named after the function it makes static - in turn, in order to determine which of the six functions cause the bug.
http://bugs.winehq.org/show_bug.cgi?id=17406
--- Comment #27 from Andrew Talbot Andrew.Talbot@talbotville.com 2009-03-12 15:18:33 --- Created an attachment (id=19896) --> (http://bugs.winehq.org/attachment.cgi?id=19896) Patch set to try to determine which functions relate to the bug
http://bugs.winehq.org/show_bug.cgi?id=17406
--- Comment #28 from Eric Sandall sandalle@sourcemage.org 2009-03-13 03:19:07 --- (In reply to comment #26)
I am attaching a set of patches that may help to determine the specific cause of the problem. The attached archive contains one patch - "init.diff" - that reorders the functions to avoid forward references and six other patches: one for each function that was made static in the original patch.
I suggest winding the build back to just before the identified patch was applied, and then applying the "init.diff" patch followed by one of the other patches as in the following example.
git reset --hard 2a0e659335ecf1d8967c75c9efe164c2d9d0214c git apply init.diff git apply mp_mod_2d.diff
Do the above and do a build for each of the six patches - each named after the function it makes static - in turn, in order to determine which of the six functions cause the bug.
I will try this weekend, thanks!
http://bugs.winehq.org/show_bug.cgi?id=17406
--- Comment #29 from Rafał Mużyło galtgendo@o2.pl 2009-03-13 11:32:38 --- Frankly, this will be more useful for the gcc bug, than for this one - as it seems to be a compiler bug, there's no telling if and where it strikes in the different places of the code.
But it may lead to creating a testcase for gcc.
http://bugs.winehq.org/show_bug.cgi?id=17406
Jorge Morais please.no.spam.here+wine+bugzilla@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |please.no.spam.here+wine+bug | |zilla@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=17406
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dank@kegel.com
--- Comment #30 from Dan Kegel dank@kegel.com 2009-05-24 12:09:27 --- I'm not convinced it's a compiler bug. -O3 often uncovers subtle problems in applications.
If somebody could narrow the change down further as suggested in #26, we could figure out what's going on.
http://bugs.winehq.org/show_bug.cgi?id=17406
--- Comment #31 from Rafał Mużyło galtgendo@o2.pl 2009-05-24 12:34:24 --- In that case, I'll do something I should have done a few comments ago - give the address of the gcc bug. It's http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39333
As mentioned there, problem seems fixed in 4.4.0.
http://bugs.winehq.org/show_bug.cgi?id=17406
--- Comment #32 from Dan Kegel dank@kegel.com 2009-05-24 13:05:06 --- That helps, but there's still no testcase on the gcc side, so it's still not clear it's a gcc bug.
http://bugs.winehq.org/show_bug.cgi?id=17406
--- Comment #33 from Rafał Mużyło galtgendo@o2.pl 2009-05-24 13:29:00 --- You may try to construct a testcase from that coreutils file. While it's a case of opposite problem, it still may give a hint of what exactly goes wrong (and it looks promising, that is as if a testcase could be actually created from it without much work).
http://bugs.winehq.org/show_bug.cgi?id=17406
--- Comment #34 from Juan Lang juan_lang@yahoo.com 2009-11-11 15:42:29 --- What's the status with latest git?
http://bugs.winehq.org/show_bug.cgi?id=17406
--- Comment #35 from Eric Sandall sandalle@sourcemage.org 2010-03-20 01:55:46 --- (In reply to comment #34)
What's the status with latest git?
Compiling with "-O3" CFLAGS/CXXFLAGS and GCC 4.3.3 and Linux kernel headers 2.6.32 works fine with git (as of 2010-03-19) and 1.1.41. Sorry I didn't test every version, but I switched to using "-O2" as "-O3" caused issues with other apps (mainly Mozilla) as well.
http://bugs.winehq.org/show_bug.cgi?id=17406
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |FIXED
--- Comment #36 from Dmitry Timoshkov dmitry@codeweavers.com 2010-03-20 06:55:35 --- Fixed then.
http://bugs.winehq.org/show_bug.cgi?id=17406
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #37 from Alexandre Julliard julliard@winehq.org 2010-04-02 12:52:08 --- Closing bugs fixed in 1.1.42.
-
wine-bugs＠winehq.org