Bug 928353
| Summary: | firefox i686 crashes for a number of web pages | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Kamil Páral <kparal> | ||||||||||
| Component: | firefox | Assignee: | Martin Stransky <stransky> | ||||||||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||
| Severity: | unspecified | Docs Contact: | |||||||||||
| Priority: | unspecified | ||||||||||||
| Version: | 19 | CC: | alekcejk, awilliam, gecko-bugs-nobody, gkulyk, jreznik, kengert, kevin, mtasaka, robatino, scp.stjohn, stransky | ||||||||||
| Target Milestone: | --- | ||||||||||||
| Target Release: | --- | ||||||||||||
| Hardware: | i686 | ||||||||||||
| OS: | Unspecified | ||||||||||||
| Whiteboard: | AcceptedBlocker [disabled opimization as a workaround] | ||||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||||
| Doc Text: | Story Points: | --- | |||||||||||
| Clone Of: | Environment: | ||||||||||||
| Last Closed: | 2013-04-09 04:24:00 UTC | Type: | Bug | ||||||||||
| Regression: | --- | Mount Type: | --- | ||||||||||
| Documentation: | --- | CRM: | |||||||||||
| Verified Versions: | Category: | --- | |||||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||||
| Embargoed: | |||||||||||||
| Bug Depends On: | |||||||||||||
| Bug Blocks: | 834084 | ||||||||||||
| Attachments: |
|
||||||||||||
|
Description
Kamil Páral
2013-03-27 13:51:58 UTC
I forgot to add: This happens ONLY for i686 version, x86_64 works fine. The p11-kit output above could be related to bug 927601, but maybe not to the crash itself. Proposing as Alpha blocker: It must be possible to run the default web browser and a terminal application from all release-blocking desktop environments. Please attach full the Firefox crash backtrace: http://fedoraproject.org/wiki/Debugging_guidelines_for_Mozilla_products Created attachment 717114 [details] crash stacktrace Mozilla crash is here: https://crash-stats.mozilla.com/report/index/bp-bdcffa04-0aee-43c9-a46c-da9ff2130327 Crash stacktrace attached. Created attachment 717117 [details]
more crash info
This is some more crash information (from print DumpJSStack()) that was requested on the wiki but wasn't logged into the gdb log above, I don't know why.
Discussed at 2013-03-27 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-03-27/f19alpha-blocker-review-3.2013-03-27-16.01.log.txt . Accepted as a blocker per criterion cited in comment #1 (also note explanatory paragraph: Web browser requirements: The web browser must be able to download files, load extensions (if applicable), and log into FAS.") *** Bug 928506 has been marked as a duplicate of this bug. *** I'm unable to reproduce it with latest trunk. It means it's already fixed in trunk or some external library is involved here or there's something specific we have in F19 xulrunner. (In reply to comment #7) > I'm unable to reproduce it with latest trunk. Does that mean, you did your own build of Firefox 22 using the Fedora compiler? > Does that mean, you did your own build of Firefox 22 using the Fedora compiler?
It means in Fedora 19 so far:
Trunk (optimized & unoptimized) => OK
FF 19.0.2 unoptimized => OK
FF 19.0.2 optimized => Crash
So we can ship Firefox 19 built without optimalization as a workaround/hotfix.
I've tried the current fedora 19 build of firefox 20 (xulrunner-20.0-1.fc19.i686.rpm together with firefox-20.0-1.fc19.i686.rpm). What shall I say - it keeps crashing. I'm not sure which construction causes the issue but it's not caused by -O3 optimization - it crashes with -O2 too. Another option is to disable JIT for i686 because the crash is there. (In reply to comment #11) > I'm not sure which construction causes the issue but it's not caused by -O3 > optimization - it crashes with -O2 too. Another option is to disable JIT for > i686 because the crash is there. I'd say it would be ok for Alpha as a temporary workaround. Created attachment 730981 [details] qupzilla backtrace I noticed a lot of crashes in Rawhide and F19 in applications including firefox which are works fine in F18. For example also crashes qupzilla, chromium from russian-fedora-free repo (it actually don't crash but shows Oops on many sites). There is also strange crash in kactivitymanagerd bug 923828. So I assume that can be some broken common system component for those Rawhide/F19 crashes. WebKit's and QtScript's JavaScriptCore JIT is probably hit by the same underlying (toolchain? kernel?) bug. The workaround is in xulrunner-20.0-3.fc19 & xulrunner-20.0-3.fc20. After a short test (I visited pages that used to crash immediately) it seems like xulrunner-20.0-3.fc19 really solves this. Thanks. Discussed at 2013-04-03 freeze exception review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-04-03/f19alpha-blocker-review-4.2013-04-03-16.01.log.txt . It looks like the workaround works, but we need it to be submitted as an update via Bodhi at this point - Bodhi has been turned on for F19. Once it's submitted as an update and pushed stable we can make this bug no longer a blocker. However, it's up to the developers whether they want to consider it 'closed' at that point, or leave it open since the package is only a workaround. If you want the bug to be closed when the update is pushed stable, mark the update as fixing this bug; if you don't, don't. Adam, note that multiple people have reported similar issues in multiple software packages. The workaround here is only done for one of those packages. It seems likely that a core software component other than firefox/xulrunner is causing the problems for multiple packages. Did you discuss if solving the underlying issue should be a blocker? See comment 13 and comment 14. Kai: sorry, forgot to note that. Yes, and it isn't: the Alpha requirement is just that the default browser work, and the default browser for both release blocking spins is Firefox. Other bits can be fixed with post-release updates. Adam, thanks for the clarification. Given the time of the day, it's already past usual european work hours, I can try to submit an update in bodhi instead of waiting for Martin. My attempt was rejected, I don't have permission to submit a xulrunner update. I can do it later if it looks like we're going for a TC4 tonight. ah, crap, I can't do it either; looks like xulrunner is a protected package. I'll try and find someone who can. > Yes, and it isn't: the Alpha requirement is just that the default browser work,
> and the default browser for both release blocking spins is Firefox.
No, it isn't. Firefox isn't even ON the KDE spin, unless something's still wrong with the compose. The default browser on the KDE spin is currently Konqueror + KWebKitPart, the underlying library is qtwebkit. (There's also KHTML on the spin, which can be selected in Konqueror, but KWebKitPart/QtWebKit has higher default priority.)
Also please note that the related bug #923828 (which we suspect to be caused by the same underlying bug, see again comment #13 and comment #14) affects a core desktop component, and other core parts of a KDE environment (e.g. the KatePart, used for all text editing tasks) also use JavaScript and so might also be affected by this issue (though we do not have sufficient data to decide whether, how nor when this happens). kev: d'oh, sorry, must've had a brain freeze there. it may be best to split the KDE bits out into a separate bug, to avoid errors in tracking, as we have an update that 'fixes' it for Firefox but not for Qt/KDE stuff? nominate that as a blocker. thanks! xulrunner-20.0-3.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/xulrunner-20.0-3.fc19 Looks like also only 32-bit qupzilla crashes but 64-bit is fine. Someone working on real fix for crashes in different 32-bit applications? xulrunner-20.0-3.fc19 seems to be in TC5. and I was able to go to Fedora Wiki and Freenode Webchat so this looks fixed to me. Moving to VERIFIED, also based on test results reported in Bodhi. As it was chosen to use this bug only for Firefox and not for the other affected applications, I propose to: - revert the subject to talk about Firefox/Xulrunner only - use separate bugs to track the remaining crashes. Since disabling optimization has helped, the bug is likely in gcc. I've filed bug 949553 to track that. Yes, we definitely need separate bugs for the KDE parts of this. As things stand there's nothing to require the KDE bits get fixed for Alpha. Kevin, if you think they really need to be fixed (or that it would be good to get fixes in), please file bugs and propose as blocker or FE. thanks! The problem is that I don't have any concrete report that would qualify as a blocker: * Konqueror somehow does not seem to be affected by the Qupzilla crashes even though both use QtWebKit. Qupzilla isn't even on our spin (nor any spin that I know of, even), so needless to say, it crashing is not a blocker. * There are crashes inside the KDE workspace (bug #923828), but the reporter can only reproduce them on a debugging kernel. (I have absolutely no idea why the kernel makes any difference.) So I'm feeling very uneasy about this latent bug, BUT without any concrete report that qualifies, I don't think there's a case for a blocker. :-( xulrunner-20.0-3.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report. kev: alpha will be using a debug kernel, if that affects the importance of 923828. the xulrunner update went stable, closing. kev, if it's any consolation, remember we really *don't* need that much to work out of the box at alpha stage - it is an *alpha*, after all. as long as you can get it installed and run yum, people shouldn't mind too much. you can always concentrate on making sure fixed/workaround-ed builds are available as 0-days for alpha. Ugh, independently of that bug, I think we should really ship at least the milestones with a release kernel. (In fact, I think we should ship ONLY release kernels in Rawhide, and let the people who actually want a debug kernel install kernel-debug, that's what it is for.) Anyway, I proposed bug #923828 as a blocker, but it seems not very reproducible even with a debug kernel. :-( Firefox is crashing KDE when certain links are clicked in the browser. OS Version Linux 3.9.9-302.fc19.x86_64 KDE Version 4.10.5 Firefox 22,.0 reopem this bug report as it is obviously not fixed On the contrary, it very clearly was fixed. Whatever you're seeing is caused by some other bug; the symptom is similar, but 'it crashes when I click on a link' is a pretty generic symptom and doesn't mean a lot. |