Crash [@ nsRefreshDriver::Tick] with resizing and opening new tabs

VERIFIED FIXED in Firefox 20

Status

()

Core
Layout
--
critical
VERIFIED FIXED
5 years ago
5 years ago

People

(Reporter: Jesse Ruderman, Assigned: vlad)

Tracking

({crash, regression, testcase})

Trunk
mozilla20
x86_64
Mac OS X
crash, regression, testcase
Points:
---

Firefox Tracking Flags

(firefox20+ fixed, firefox21+ fixed)

Details

(crash signature)

Attachments

(2 attachments)

(Reporter)

Description

5 years ago
Created attachment 669282 [details]
testcase (see comment 0)

Using a build that includes the patch for bug 731974,

1. Create a new profile 
2. Install https://www.squarefree.com/extensions/domFuzzLite3.xpi
3. Replace prefs.js with the following:
  user_pref("browser.sessionstore.resume_from_crash", false);
  user_pref("toolkit.startup.max_resumed_crashes", -1);
  user_pref("dom.min_background_timeout_value", 4);
  user_pref("nglayout.debug.disable_xul_cache", true);
4. Run with the testcase on the command line

Result: Crash [@ nsRefreshDriver::Tick], usually on the second time the testcase opens a new tab.

At least on my laptop running Mac OS X 10.7, and a debug build from Tinderbox that was built from http://hg.mozilla.org/mozilla-central/rev/d9e032542831.  It seems to be horribly dependent on timing.

This might hold clues to topcrash bug 798872.

Updated

5 years ago
Blocks: 798872
So what's happening here is that we're poking all our drivers in the timer, and when one of them runs, it causes a later one to be removed:

0[acd5f0]: [fc54401] ticking drivers...
0[acd5f0]: >> TickDriver: 3ebdeb8 (jsnow: 1349798419095175)
0[acd5f0]: >> TickDriver: 82e78c8 (jsnow: 1349798419095175)
0[acd5f0]: [7f570c8] RemoveRefreshDriver 82e7730
0[acd5f0]: >> TickDriver: 82e7730 (jsnow: 1349798419095175)

but we try to poke it anyway since we took a copy of our list before we started.  We hold refs to everything, so I can only guess that the Tick itself is doing something busted.  I have an idea on how to fix it, though.
Assignee: nobody → vladimir
Created attachment 669628 [details] [diff] [review]
don't Tick if we were disconnected

Simple fix -- just check if we were disconnected in Tick().  We have some helpers in DoTick/DoRefresh that are used for some internal test usages.  I also added the assertions to the main Tick call as well.  (This is on top of the patch in bug 731974; I'll fold them together when relanding, once I fix the winxp orange)
Attachment #669628 - Flags: review?(bzbarsky)
Comment on attachment 669628 [details] [diff] [review]
don't Tick if we were disconnected

I don't think you can assert !mFrozen.  Another driver could have done history.back() on us and then spun the event loop until we are in fact frozen, no?  So I suspect we need to just test for that just like we test for mPresContext.

r=me with that
Attachment #669628 - Flags: review?(bzbarsky) → review+
Duplicate of this bug: 798872
Landed as part of bug 731974 relanding.  https://hg.mozilla.org/integration/mozilla-inbound/rev/5b727a94eebd
Depends on: 822096
No longer depends on: 822096
tracking-firefox20: --- → ?
tracking-firefox21: --- → ?
Hm, forgot to resolve this; this should have been fixed when 731974 finally landed.  Is it still reproducible?
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
I haven't tested; just wanted to make sure it didn't get lost...

Updated

5 years ago
No longer blocks: 731974, 798872
Depends on: 731974
Target Milestone: --- → mozilla20

Updated

5 years ago
Keywords: verifyme
(Reporter)

Comment 8

5 years ago
Seems ok with the testcase in comment 0, and with the other testcases I had lying around.
Status: RESOLVED → VERIFIED

Comment 9

5 years ago
Tracking as fixed, QA please verify the testcase in FF20.
status-firefox20: --- → fixed
status-firefox21: --- → fixed
tracking-firefox20: ? → +
tracking-firefox21: ? → +
Keywords: qawanted
The Nightly debug builds from 2012-10-07 and 2012-10-08 seem to have some problems, they won't start on Mac. On Win, I couldn't reproduce the problem too.

Anyway, I don't see any crash on FF 20 2013-01-22-mozilla-aurora-debug using the STR in comment 0.

Updated

5 years ago
Keywords: qawanted, verifyme
I see 16 crashes on FF 20b1 in the last week:
https://crash-stats.mozilla.com/report/list?signature=nsRefreshDriver%3A%3ATick%28__int64%2C+mozilla%3A%3ATimeStamp%29
Any thoughts?
More crashes appeared on 20 betas. Can anyone please take a look ?
https://crash-stats.mozilla.com/report/list?signature=nsRefreshDriver%3A%3ATick%28__int64%2C+mozilla%3A%3ATimeStamp%29
You need to log in before you can comment on or make changes to this bug.