Closed Bug 799242 Opened 7 years ago Closed 7 years ago

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

Categories

(Core :: Layout, defect, critical)

x86_64
macOS
defect
Not set
critical

Tracking

()

VERIFIED FIXED
mozilla20
Tracking Status
firefox20 + fixed
firefox21 + fixed

People

(Reporter: jruderman, Assigned: vlad)

References

Details

(Keywords: crash, regression, testcase)

Crash Data

Attachments

(2 files)

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.
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
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+
Depends on: 822096
No longer depends on: 822096
Hm, forgot to resolve this; this should have been fixed when 731974 finally landed.  Is it still reproducible?
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
I haven't tested; just wanted to make sure it didn't get lost...
No longer blocks: 731974, 798872
Depends on: 731974
Target Milestone: --- → mozilla20
Keywords: verifyme
Seems ok with the testcase in comment 0, and with the other testcases I had lying around.
Status: RESOLVED → VERIFIED
Tracking as fixed, QA please verify the testcase in FF20.
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.
Keywords: qawanted, verifyme
You need to log in before you can comment on or make changes to this bug.