http://bugs.winehq.org/show_bug.cgi?id=21405
Summary: IE6 / IE7 crashes with "longjmp causes uninitialized stack frame" Product: Wine Version: 1.1.36 Platform: x86 URL: http://forum.winehq.org/viewtopic.php?p=38270 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: chewi@aura-online.co.uk
Created an attachment (id=25776) --> (http://bugs.winehq.org/attachment.cgi?id=25776) Wine output
Using the latest winetricks, I've installed ie6 and ie7 (separately) on my x86 Gentoo machine. In both cases, after loading a page, iexplore.exe always terminates with "longjmp causes uninitialized stack frame". Interestingly, this doesn't happen on my x86-64 Gentoo machine. However, the 32-bit system is more up-to-date. For instance, it has glibc 2.11 while the 64-bit system has 2.10. I'm not the only person to have encountered this. See the given URL for a forum thread where a Ubuntu user has also encountered it. It may be easy for you to reproduce. Note that this occurs on all recent Wine releases back from 1.1.34 to 1.1.36.
http://bugs.winehq.org/show_bug.cgi?id=21405
James Gilliland neclimdul@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |neclimdul@gmail.com
--- Comment #1 from James Gilliland neclimdul@gmail.com 2010-01-17 18:22:01 --- I'm having the same problem and have found it connected to displaying images. If I visit a website that doesn't have any images things seem fine (wine IEXPLORE.exe http://example.com/noimages.html). But if I go to a site like winehq.org that is the default homepage, it crashes with this error after loading the first image. I've also tested and i seems that its not a specific image type causing it. I had the same crash on a page with a single png and a page with a single jpeg.
I should note, I'm also running on Gentoo but using 1.1.35.
Pages I used to test: http://nerdpalace.net/wine
http://bugs.winehq.org/show_bug.cgi?id=21405
--- Comment #2 from Ian iphands@gmail.com 2010-01-17 19:19:43 --- Created an attachment (id=25779) --> (http://bugs.winehq.org/attachment.cgi?id=25779) Dragon Naturally speaking crashes when the "accuracy center" web page is brought up.
+1 here...
My father uses Dragon NaturallySpeaking in wine. The "Accuracy Center" (which starts out as a local html interface) is launched (and calls IE?) the attached backtrace is generated.
We are seeing this issue on the Fedora 12 spun wine build. We did not see the issue on the Fedora 11 version. I will try to test a later version of wine as well.
Please let me know if I can perform some further debugging here. I would be new to wine debugging, but happy to help.
Thanks, -Ian Page Hands
http://bugs.winehq.org/show_bug.cgi?id=21405
Ian iphands@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |iphands@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=21405
Adrian Hands handsadrian@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |handsadrian@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=21405
--- Comment #3 from James Le Cuirot chewi@aura-online.co.uk 2010-01-18 04:07:36 --- Thanks guys. I just updated "system" which includes things like glibc. I ran Wine again and it worked. I then rebuilt Wine and now it doesn't work! I can't remember what the other system packages were but I'm pretty sure none of them were image libraries. It's looking like this might be a bug with glibc or some image library rather than Wine.
http://bugs.winehq.org/show_bug.cgi?id=21405
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW CC| |nerv@dawncrow.de Ever Confirmed|0 |1
--- Comment #4 from André H. nerv@dawncrow.de 2010-01-18 07:53:51 --- confirmed(3 persons have the same issue)
http://bugs.winehq.org/show_bug.cgi?id=21405
--- Comment #5 from James Gilliland neclimdul@gmail.com 2010-01-19 00:57:05 --- Glibc seems like a reasonable possiblity. F12 has glibc 2.11 and F11 had 2.10. So seems like everyone is seeing it with the update to 2.11.
The glibc changelog for 2.11 shows " Checking version of longjmp added that fails if an uninitialized stack frame would be created." which could be interesting if we can trace back to where this is happening. http://sourceware.org/ml/libc-alpha/2009-10/msg00063.html
I'll try to downgrade glibc to 2.10 this week and see if I can confirm the problem goes away.
http://bugs.winehq.org/show_bug.cgi?id=21405
--- Comment #6 from James Le Cuirot chewi@aura-online.co.uk 2010-01-19 03:56:25 --- Be careful. I don't know about Fedora but downgrading glibc on Gentoo will kill your system.
http://bugs.winehq.org/show_bug.cgi?id=21405
--- Comment #7 from James Le Cuirot chewi@aura-online.co.uk 2010-01-19 04:51:57 --- Here's the actual commit.
http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=b50f8e42ba3010f0141e6a...
But this appears to just be a new safety check. I think the real problem lies elsewhere. Maybe we shouldn't rule out the possibility that this is a bug in Internet Explorer. ;)
http://bugs.winehq.org/show_bug.cgi?id=21405
--- Comment #8 from James Le Cuirot chewi@aura-online.co.uk 2010-01-19 07:44:36 --- Created an attachment (id=25794) --> (http://bugs.winehq.org/attachment.cgi?id=25794) Backtrace with debug information
I rebuilt Wine with debugging information. Here's the new backtrace. It mentions line 209 of dlls/kernel32/fiber.c. The line just above this is siglongjmp( new_fiber->jmpbuf, 1 ) so this seems to be the right place. Although it doesn't say so explicitly, the point before that seems to be somewhere in HTMLDocument_get_body of dlls/mshtml/htmldoc.c.
http://bugs.winehq.org/show_bug.cgi?id=21405
--- Comment #9 from James Le Cuirot chewi@aura-online.co.uk 2010-01-19 07:50:03 --- Sorry, ignore the bit about mshtml. I've realised that we're using the native mshtml here. That explains the lack of debug information and the seemingly irrelevant point in the code. I am now out of my depth. ;)
http://bugs.winehq.org/show_bug.cgi?id=21405
--- Comment #10 from Alexandre Julliard julliard@winehq.org 2010-01-19 07:59:36 --- By nature fibers use multiple stacks, so they are not compatible with that longjmp check. You have to build without fortify options to avoid the check.
http://bugs.winehq.org/show_bug.cgi?id=21405
--- Comment #11 from James Le Cuirot chewi@aura-online.co.uk 2010-01-19 08:35:09 --- Okay so I rebuilt Wine with _FORTIFY_SOURCE=0 in my CFLAGS and that worked. But according to features.h, 0 should be the default. So I did a little more digging and found this in Gentoo GCC patches.
"NOTE: In Gentoo, @option{-D_FORTIFY_SOURCE=2} is set by default, and is activated when @option{-O} is set to 2 or higher. This enables additional compile-time and run-time checks for several libc functions. To disable, specify either @option{-U_FORTIFY_SOURCE} or @option{-D_FORTIFY_SOURCE=0}."
Aha! Now I could go pester the Gentoo Wine maintainers but if you know that this option breaks Wine then maybe Wine should force it to 0? That's my opinion but I'll leave it up to you.
http://bugs.winehq.org/show_bug.cgi?id=21405
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |kernel32
--- Comment #12 from André H. nerv@dawncrow.de 2010-01-19 08:59:31 --- blaming kernel32 as it has some Fixme-Comments like: /* FIXME:proper handling of signal stack */ which already sounds like that bug ill see if i can write a testcase
http://bugs.winehq.org/show_bug.cgi?id=21405
--- Comment #13 from Alexandre Julliard julliard@winehq.org 2010-01-19 09:45:19 --- (In reply to comment #11)
Aha! Now I could go pester the Gentoo Wine maintainers but if you know that
this option breaks Wine then maybe Wine should force it to 0? That's my opinion but I'll leave it up to you.
A check that causes the app to die on every false positive should definitely be opt-in, it shouldn't be up to Wine to request sane behavior.
http://bugs.winehq.org/show_bug.cgi?id=21405
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Component|kernel32 |-unknown Resolution| |INVALID
--- Comment #14 from Dmitry Timoshkov dmitry@codeweavers.com 2010-01-19 10:18:48 --- Then this bug is invalid.
http://bugs.winehq.org/show_bug.cgi?id=21405
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #15 from Dmitry Timoshkov dmitry@codeweavers.com 2010-01-19 10:19:02 --- Closing invalid.
http://bugs.winehq.org/show_bug.cgi?id=21405
--- Comment #16 from James Gilliland neclimdul@gmail.com 2010-01-19 11:12:05 --- Just to be clear so the rest of us can do the proper leg work, you mean its being tossed downstream to Gentoo and Fedora to deal with?
http://bugs.winehq.org/show_bug.cgi?id=21405
--- Comment #17 from Alexandre Julliard julliard@winehq.org 2010-01-19 11:39:13 --- Yes you should file a bug with the distros. If they refuse to fix it then we can consider adding a workaround.
http://bugs.winehq.org/show_bug.cgi?id=21405
--- Comment #18 from James Le Cuirot chewi@aura-online.co.uk 2010-01-19 13:07:07 --- Here's the Gentoo bug. http://bugs.gentoo.org/show_bug.cgi?id=301536
http://bugs.winehq.org/show_bug.cgi?id=21405
--- Comment #19 from Adrian Hands handsadrian@gmail.com 2010-01-20 18:38:22 --- Here is the Fedora bz (thanks Ian!): https://bugzilla.redhat.com/show_bug.cgi?id=557316
http://bugs.winehq.org/show_bug.cgi?id=21405
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dank@kegel.com
--- Comment #20 from Dan Kegel dank@kegel.com 2010-01-23 14:57:48 --- Looks like they're refusing to fix it.
I wonder if the longjmp examples at http://evanjones.ca/software/threading.html would also trigger the warning.
http://bugs.winehq.org/show_bug.cgi?id=21405
--- Comment #21 from Alexandre Julliard julliard@winehq.org 2010-01-23 16:44:09 --- Any user-space threading implementation will have the same problem.
http://bugs.winehq.org/show_bug.cgi?id=21405
Rafał Mużyło galtgendo@o2.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |galtgendo@o2.pl
--- Comment #22 from Rafał Mużyło galtgendo@o2.pl 2010-01-25 08:05:41 --- Any chance on discussing it with glibc people ?
Just to see, what they'd suggest - turning off the check or a different sollution.
http://bugs.winehq.org/show_bug.cgi?id=21405
--- Comment #23 from Dan Kegel dank@kegel.com 2010-01-25 08:10:28 --- Can one disable the check for just the source file containing the longjmp? The distros might go for that. If that works, we could build it in to our Makekfiles.
http://bugs.winehq.org/show_bug.cgi?id=21405
--- Comment #24 from Rafał Mużyło galtgendo@o2.pl 2010-01-25 08:14:12 --- And on a semi-related note: the example titled "Simple longjmp Fiber Example" indeed does trigger that check.
http://bugs.winehq.org/show_bug.cgi?id=21405
--- Comment #25 from Rafał Mużyło galtgendo@o2.pl 2010-01-25 08:24:35 --- As for comment 23: doing that would required just a simple modification of Makefile.am: adding a '-U_FORTIFY_SOURCE to EXTRADEFS of that lib.
Well, it would disable it for the whole module, but trying to do it for a one file would be probably a bit annoying in wine' build system.
However (most probably) the point of Fedora devs is: can't it really be done that it works with that check ?
If not, why and why glibc people though it shouldn't be more of a problem than other _FORTIFY_SOURCE checks ?
http://bugs.winehq.org/show_bug.cgi?id=21405
--- Comment #26 from James Le Cuirot chewi@aura-online.co.uk 2010-01-25 08:33:15 --- I don't think this is the only implementation of userspace threads on Linux. I know that Ruby 1.8 uses "green" threads. Wouldn't that suffer from the same problem?
http://bugs.winehq.org/show_bug.cgi?id=21405
--- Comment #27 from Dan Kegel dank@kegel.com 2010-01-25 08:35:09 --- Or we could just do #ifdef _FORTIFY_SOURCE #undef _FORTIFY_SOURCE #endif in the affected source file, I guess.
Maybe that's what the distros are trying to tell us.
http://bugs.winehq.org/show_bug.cgi?id=21405
--- Comment #28 from James Le Cuirot chewi@aura-online.co.uk 2010-01-25 08:42:23 --- I think Rafał's right, they're concerned that disabling the check must mean that this is some kind of nasty hack that should be avoided and fixed properly. If there really is no other way then I'm sure they'd be fine with the #ifdef or Makefile.am solution but if that's the case, I'd like to know why Ruby is different.
http://bugs.winehq.org/show_bug.cgi?id=21405
--- Comment #29 from Alexandre Julliard julliard@winehq.org 2010-01-25 09:02:49 --- The point is not that we can hack the makefile to disable the check, of course we can do that. The point is that some distros are enabling by default a check that causes legitimate code to crash and burn. That's a distro bug IMHO; safety checks that fail so ungracefully should be opt-in, not opt-out.
http://bugs.winehq.org/show_bug.cgi?id=21405
--- Comment #30 from Rafał Mużyło galtgendo@o2.pl 2010-01-25 09:15:05 --- But the other point is that most of other _FORTIFY_SOURCE checks are either just noisy with warnings ("return unused" and "format string") or aborts when there most probably is a problem (like those in strn[cpy|cat]).
So either glibc people impose too strict check or there is a way to make it work even with that check.
http://bugs.winehq.org/show_bug.cgi?id=21405
--- Comment #31 from Alexandre Julliard julliard@winehq.org 2010-01-25 10:16:18 --- The check could arguably be considered too strict, but it's opt-in at the glibc level, as it should be. It's the distros that are changing the default.
Many other checks are also too strict, especially the "return unused" ones, which is why making fortify the default distro-wide is not a good idea, at least not in its current state.
http://bugs.winehq.org/show_bug.cgi?id=21405
--- Comment #32 from Dan Kegel dank@kegel.com 2010-01-25 12:44:51 --- I bet they can get away with it because a) there aren't that many user-space threading packages, and b) those packages can easily selectively disable FORTIFY_SOURCE where needed. So I rather doubt Fedora's going to back down.
http://bugs.winehq.org/show_bug.cgi?id=21405
Maarten Lankhorst m.b.lankhorst@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |REOPENED CC| |m.b.lankhorst@gmail.com Resolution|INVALID |
--- Comment #33 from Maarten Lankhorst m.b.lankhorst@gmail.com 2010-01-29 06:05:57 --- It may not be a wine bug, but all major distributions set their settings in a way it will affect wine. Fedora, ubuntu and gentoo are all affected, so wine cannot simply ignore this.
As a workaround you can add this as first line to dlls/kernel32/fiber.c: #undef _FORTIFY_SOURCE
http://bugs.winehq.org/show_bug.cgi?id=21405
--- Comment #34 from Rafał Mużyło galtgendo@o2.pl 2010-01-29 08:06:22 --- The main question stays the same: are you sure it can't be done in a sane way without turning that check off ?
Cause the above proves only it (probably) can't be done, the way it's done now.
http://bugs.winehq.org/show_bug.cgi?id=21405
--- Comment #35 from Alexandre Julliard julliard@winehq.org 2010-01-29 08:52:58 --- (In reply to comment #34)
The main question stays the same: are you sure it can't be done in a sane way without turning that check off ?
Yes. The glibc check cannot possibly support stack switching, and there's nothing we can do in Wine to change that fact. The check could conceivably be made smarter in glibc, but that's probably not trivial.
http://bugs.winehq.org/show_bug.cgi?id=21405
--- Comment #36 from James Le Cuirot chewi@aura-online.co.uk 2010-01-29 09:00:39 --- Sorry to keep beating this drum but no one's answered why Ruby manages to do it without this workaround. No doubt you won't be familiar with the Ruby source but considering 1.8 does its threading in userspace (one of the common complains about it), it could be worth a look?
http://bugs.winehq.org/show_bug.cgi?id=21405
Maarten Lankhorst m.b.lankhorst@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED
--- Comment #37 from Maarten Lankhorst m.b.lankhorst@gmail.com 2010-01-29 17:28:38 --- Patch committed for now
http://bugs.winehq.org/show_bug.cgi?id=21405
--- Comment #38 from Rafał Mużyło galtgendo@o2.pl 2010-01-29 18:42:20 --- Just a minor thing: would one off the wine devs mind filing a bug against glibc ? While comment 35 suggests it will be a WONTFIX/NOTABUG, it would be nice to know if the upstream agrees with that comment.
http://bugs.winehq.org/show_bug.cgi?id=21405
--- Comment #39 from Jeff Zaroyko jeffz@jeffz.name 2010-01-29 18:55:51 --- (In reply to comment #38)
Just a minor thing: would one off the wine devs mind filing a bug against glibc ? While comment 35 suggests it will be a WONTFIX/NOTABUG, it would be nice to know if the upstream agrees with that comment.
It's already been said that it's opt-in at the glibc level, it's the distros changing the default which created the problem.
http://bugs.winehq.org/show_bug.cgi?id=21405
--- Comment #40 from Rafał Mużyło galtgendo@o2.pl 2010-01-30 06:25:35 --- (In reply to comment #39) Definitely NOT my point. I'm saying that either: - upstream knows about the issue and is ignoring it (upstream will advise to turn the check off) - upstream knows about it and is working on it (check will eventually be refined) - upstream knows how to do it *without* triggering that check after all
Cause if the upstream is not aware of the problem, it can't fix it.
http://bugs.winehq.org/show_bug.cgi?id=21405
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #41 from Alexandre Julliard julliard@winehq.org 2010-02-05 11:39:17 --- Closing bugs fixed in 1.1.38.
http://bugs.winehq.org/show_bug.cgi?id=21405
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |andrea.vai@unipv.it
--- Comment #42 from Dmitry Timoshkov dmitry@codeweavers.com 2010-09-04 00:40:05 CDT --- *** Bug 24253 has been marked as a duplicate of this bug. ***
-
wine-bugs＠winehq.org