Bug 928353 - firefox i686 crashes for a number of web pages
firefox i686 crashes for a number of web pages
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: firefox (Show other bugs)
19
i686 Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Martin Stransky
Fedora Extras Quality Assurance
AcceptedBlocker [disabled opimization...
:
: 928506 (view as bug list)
Depends On:
Blocks: F19Alpha/F19AlphaBlocker
  Show dependency treegraph
 
Reported: 2013-03-27 09:51 EDT by Kamil Páral
Modified: 2013-07-17 18:25 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-04-09 00:24:00 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
firefox crashreporter (547.22 KB, image/png)
2013-03-27 09:51 EDT, Kamil Páral
no flags Details
crash stacktrace (37.07 KB, text/plain)
2013-03-27 10:49 EDT, Kamil Páral
no flags Details
more crash info (1.08 KB, text/plain)
2013-03-27 10:50 EDT, Kamil Páral
no flags Details
qupzilla backtrace (3.72 KB, text/plain)
2013-04-02 17:12 EDT, nucleo
no flags Details

  None (edit)
Description Kamil Páral 2013-03-27 09:51:58 EDT
Created attachment 717085 [details]
firefox crashreporter

Description of problem:
If I boot F19 Alpha TC2 Live i686 and try to open certain web pages in Firefox, Firefox crashes.

Pages that work:
http://google.com

Pages that crashes the browser:
http://fedoraproject.org/wiki
http://webchat.freenode.net
http://www.seznam.cz

FF doesn't crash always for the pages above, but very often. It crashes when it attempts to draw the page.

The terminal output says:

> $ firefox http://seznam.cz
> 
> (process:2210): GLib-CRITICAL **: g_slice_set_config: assertion `sys_page_size == 0' failed
> p11-kit: 'timet >= 0' not true at when_and_offset_to_time_t
> p11-kit: 'timet >= 0' not true at calc_date
> p11-kit: 'timet >= 0' not true at when_and_offset_to_time_t
> p11-kit: 'timet >= 0' not true at calc_date
> p11-kit: 'timet >= 0' not true at when_and_offset_to_time_t
> p11-kit: 'timet >= 0' not true at calc_date
> p11-kit: 'timet >= 0' not true at when_and_offset_to_time_t
> p11-kit: 'timet >= 0' not true at calc_date
> p11-kit: 'timet >= 0' not true at when_and_offset_to_time_t
> p11-kit: 'timet >= 0' not true at calc_date
> p11-kit: 'timet >= 0' not true at when_and_offset_to_time_t
> p11-kit: 'timet >= 0' not true at calc_date
> p11-kit: duplicate 'StartCom Certification Authority' certificate found in: ca-bundle.trust.crt
> p11-kit: 'timet >= 0' not true at when_and_offset_to_time_t
> p11-kit: 'timet >= 0' not true at calc_date
> p11-kit: duplicate 'Class 3 Public Primary Certification Authority' certificate found in: ca-bundle.trust.crt

and then it displays "crashreporter" dialog. I wasn't able to obtain the core file, it seems that crashreporter prevents creating it.

Version-Release number of selected component (if applicable):
firefox-19.0.2-2.fc19.i686

How reproducible:
90%

Steps to Reproduce:
1. boot F19 Alpha TC2 Live i686 and try to open firefox with some of the web sites above
Comment 1 Kamil Páral 2013-03-27 09:54:15 EDT
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.
Comment 2 Martin Stransky 2013-03-27 09:57:28 EDT
Please attach full the Firefox crash backtrace:

http://fedoraproject.org/wiki/Debugging_guidelines_for_Mozilla_products
Comment 3 Kamil Páral 2013-03-27 10:49:08 EDT
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.
Comment 4 Kamil Páral 2013-03-27 10:50:25 EDT
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.
Comment 5 Adam Williamson 2013-03-27 13:04:24 EDT
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.")
Comment 6 Kai Engert (:kaie) 2013-03-28 06:57:39 EDT
*** Bug 928506 has been marked as a duplicate of this bug. ***
Comment 7 Martin Stransky 2013-03-29 12:43:51 EDT
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.
Comment 8 Kai Engert (:kaie) 2013-03-29 16:30:49 EDT
(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?
Comment 9 Martin Stransky 2013-04-01 04:29:28 EDT
> 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.
Comment 10 Gert Michael Kulyk 2013-04-01 14:48:05 EDT
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.
Comment 11 Martin Stransky 2013-04-01 18:16:10 EDT
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.
Comment 12 Jaroslav Reznik 2013-04-02 03:59:18 EDT
(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.
Comment 13 nucleo 2013-04-02 17:12:11 EDT
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.
Comment 14 Kevin Kofler 2013-04-02 17:56:04 EDT
WebKit's and QtScript's JavaScriptCore JIT is probably hit by the same underlying (toolchain? kernel?) bug.
Comment 15 Martin Stransky 2013-04-03 07:29:12 EDT
The workaround is in xulrunner-20.0-3.fc19 & xulrunner-20.0-3.fc20.
Comment 16 Gert Michael Kulyk 2013-04-03 09:34:45 EDT
After a short test (I visited pages that used to crash immediately) it seems like xulrunner-20.0-3.fc19 really solves this. Thanks.
Comment 17 Adam Williamson 2013-04-03 14:35:41 EDT
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.
Comment 18 Kai Engert (:kaie) 2013-04-03 15:16:46 EDT
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?
Comment 19 Kai Engert (:kaie) 2013-04-03 15:21:21 EDT
See comment 13 and comment 14.
Comment 20 Adam Williamson 2013-04-03 15:24:46 EDT
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.
Comment 21 Kai Engert (:kaie) 2013-04-03 16:13:31 EDT
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.
Comment 22 Kai Engert (:kaie) 2013-04-03 16:15:16 EDT
My attempt was rejected, I don't have permission to submit a xulrunner update.
Comment 23 Adam Williamson 2013-04-03 16:47:57 EDT
I can do it later if it looks like we're going for a TC4 tonight.
Comment 24 Adam Williamson 2013-04-03 19:10:43 EDT
ah, crap, I can't do it either; looks like xulrunner is a protected package. I'll try and find someone who can.
Comment 25 Kevin Kofler 2013-04-03 21:50:34 EDT
> 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.)
Comment 26 Kevin Kofler 2013-04-03 21:56:12 EDT
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).
Comment 27 Adam Williamson 2013-04-03 22:02:23 EDT
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!
Comment 28 Fedora Update System 2013-04-04 04:22:18 EDT
xulrunner-20.0-3.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/xulrunner-20.0-3.fc19
Comment 29 nucleo 2013-04-04 16:08:08 EDT
Looks like also only 32-bit qupzilla crashes but 64-bit is fine.
Comment 30 nucleo 2013-04-05 15:17:12 EDT
Someone working on real fix for crashes in different 32-bit applications?
Comment 31 Jens Petersen 2013-04-08 00:24:48 EDT
xulrunner-20.0-3.fc19 seems to be in TC5.
Comment 32 Jens Petersen 2013-04-08 00:54:38 EDT
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.
Comment 33 Kai Engert (:kaie) 2013-04-08 09:23:23 EDT
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.
Comment 34 Adam Williamson 2013-04-08 18:46:49 EDT
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!
Comment 35 Kevin Kofler 2013-04-08 19:08:57 EDT
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. :-(
Comment 36 Fedora Update System 2013-04-08 23:42:24 EDT
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.
Comment 37 Adam Williamson 2013-04-09 00:22:43 EDT
kev: alpha will be using a debug kernel, if that affects the importance of 923828.
Comment 38 Adam Williamson 2013-04-09 00:24:00 EDT
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.
Comment 39 Kevin Kofler 2013-04-09 03:51:44 EDT
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. :-(
Comment 40 SP 2013-07-17 18:21:57 EDT
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
Comment 41 SP 2013-07-17 18:22:57 EDT
reopem this bug report as it is obviously not fixed
Comment 42 Adam Williamson 2013-07-17 18:25:37 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.