Closed Bug 1060194 Opened 10 years ago Closed 7 years ago

ASSERTION: old rule tree still referenced: 'Not Reached', file ../../../gecko/layout/style/nsStyleSet.cpp, line 1969

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Platform:
ARM
Gonk (Firefox OS)
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX
Project Flags:
tracking-b2g backlog
Tracking Flags:
Tracking Status
b2g-v2.0 --- affected
b2g-v2.1 --- affected
b2g-v2.2 --- affected
b2g-master --- affected

People

(Reporter: allstars.chh, Unassigned, NeedInfo)

Details

Attachments

(1 file, 1 obsolete file)

the tree of style contexts that are still alive but should not be
267.34 KB, text/plain
Details 
I met this on Nexus4
This error keeps showing without doing anything.


Gecko
commit 3757575378f34afd3f9a7d4553d2eeca1cd1f0f9
Merge: c440dec 5a8c3cf
Author: Ryan VanderMeulen <ryanvm@gmail.com>
Date:   Thu Aug 28 16:21:43 2014 -0400

    Merge inbound to m-c. a=merge

Gaia
commit 7616583ebf507860ae22066e38a1205d311400ae
Merge: 93a13e8 9d58a2a
Author: Kevin Grandon <kevingrandon@yahoo.com>
Date:   Thu Aug 28 19:55:52 2014 -0700

    Merge pull request #23427 from KevinGrandon/bug_1055713_navigate_current_browser_window
    
    Bug 1055713 - Entering a URL when in a browser window should navigate the current browser window
Do you still see this, Yoshi?
Flags: needinfo?(allstars.chh)
yes, just try latest m-c

commit 89f4a647c549ec43791b0dfd771d3b923e93736c
Author: Ryan VanderMeulen <ryanvm@gmail.com>
Date:   Mon Oct 12 18:04:55 2015 -0400

    Backout eab6f9c125cc (bug 1211694) to see if it fixes the crashes reported in bug 1213979. a=me
    
    --HG--
    extra : amend_source : f08a20212360b2729c3a313c818981d806c12321


The message is still there,
except the line number has been changed to 2222.
Flags: needinfo?(allstars.chh)
Naoki, is this something your team could help track down?
Flags: needinfo?(nhirata.bugzilla)
Yes, having regression window-wanted will help.  Having said that I'm not sure if this would be in their query.  I will ping them to see if they can include this in their list.
Flags: needinfo?(nhirata.bugzilla)
QA Contact: pcheng
After some research about this bug I've gathered the following information:

1) This issue is ONLY visible in logcat using engineering debug builds. This does not occur on user builds and does not occur on engineering builds.

2) This issue is most visible right after flashing. This error is displayed several times during device initialization before it enters FTU, and it continues to display a few times during FTU. After FTU this issue tends to display when changing browser orientation. Central seems to exhibit this issue more often than 2.2 as the error is also seen during locking/unlocking device. It's not happening as often as bug reporter described 'keeps showing without doing anything' but it does happen a number of times if you start logcat right after flashing or if you do certain actions described above.

3) This issue is reproducible on all branches of Flame therefore not a regression:

Device: Flame 2.5 Central
BuildID: 20151013043002
Gaia: d400cda6bf0f8b30dcf7d7d71bfa61f29a3f1588
Gecko: 607a236c229994df99766c005f9ec729532d7747
Gonk: c4779d6da0f85894b1f78f0351b43f2949e8decd
Version: 44.0a1 (2.5) 
Firmware Version: v18Dv4
User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0

Device: Flame 2.2
BuildID: 20151013063005
Gaia: 885647d92208fb67574ced44004ab2f29d23cb45
Gecko: a897f20b456b
Gonk: bd9cb3af2a0354577a6903917bc826489050b40d
Version: 37.0 (2.2) 
Firmware Version: v18Dv4
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Device: Flame 2.1
BuildID: 20150723183010
Gaia: 9dba58d18006e921546cec62c76074ce81e16518
Gecko: 41e10c6740be
Gonk: bd9cb3af2a0354577a6903917bc826489050b40d
Version: 34.0 (2.1) 
Firmware Version: v18Dv4
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Device: Flame 2.0
BuildID: 20150723003004
Gaia: b16ba05481e577bc644ed8966f587a70fe2148e6
Gecko: 2e6f1d4deff9
Gonk: bd9cb3af2a0354577a6903917bc826489050b40d
Version: 32.0 (2.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Notes:
1. We're unable to check Aries due to bug 1184336.
2. I checked Flame 2.0 on a different base because v18Dv4 base seems to crash on homescreen; screen wouldn't turn on.
QA Whiteboard: [QAnalyst-Triage?]
status-b2g-v2.0: --- → affected
status-b2g-v2.1: --- → affected
status-b2g-v2.2: --- → affected
status-b2g-master: --- → affected
Flags: needinfo?(jmercado)
Keywords: regressionwindow-wanted
Finding a window for this issue is not possible.
Flags: needinfo?(jmercado)
I see this message a lot for a while in debug builds, but it doesn't seem to cause any obvious harm.  Naoki, how should we proceed with this bug?  should we just put it in our backlog?
Flags: needinfo?(nhirata.bugzilla)
Based on https://bugzilla.mozilla.org/show_bug.cgi?id=1062119#c24, it's redrawing with no visible perception to someone.  I would say it may be a performance issue; we could potentially be faster if we didn't have to redraw so much?

Possibly pass this to Milan for perf?  Otherwise, it's going to be a backlog...  that's just my thought.
Flags: needinfo?(nhirata.bugzilla) → needinfo?(npark)
Milan, what do you think? (Comment 8)
Flags: needinfo?(npark) → needinfo?(milan)
Between Mats and David, they should be able to tell us if this assertion is pointing to something bad going on, or if things have changed since the original implementation to mean this is not a problem anymore.
Flags: needinfo?(milan)
Flags: needinfo?(mats)
Flags: needinfo?(dbaron)
This assertion is still bad as far as I know.  IIRC, it could lead to crashes, or worse.
Flags: needinfo?(mats)
I don't know if it will help further analysis, but Yoshi, can you MOZ_CRASH when this happens, so that we have a stack, and perhaps also show the index and size of the array where the assertion fails?
(In reply to Mats Palmgren (:mats) from comment #11)
> This assertion is still bad as far as I know.  IIRC, it could lead to
> crashes, or worse.

No, at some point I changed things so that we would just leak rather than crash.  (Depending on what the cause is, the leak might be short-term or nearly permanent.)
BTW, if somebody in Taipei with a debugging setup is seeing this, I could debug it while I'm in Taipei this week or next; otherwise I won't have a B2G debugging setup until I'm back home and have access to a phone that isn't my primary phone (and then even barely, since I really need to get a new desktop with more disk space so I can have an additional B2G tree).
[Tracking Requested - why for this release]:
As far as I know this has been around for a while- and while this could be a performance issue, at the same time as Naoki says, it's not causing any crashes, so moving to backlog for now.  Perhaps we can make it a 2.6 blocker later, since that release is aimed at increasing stability.
tracking-b2g: --- → backlog
So I tried to flash a debug build onto my flame to debug this, but I ended up with a flame that won't boot anymore.

(It might be related that flash.sh said "target reported max download size of 301989888 bytes" multiple times.)
:dbaron, are you on Flame v18D-nightly-v4 base image?
(In reply to Pi Wei Cheng [:piwei] from comment #17)
> :dbaron, are you on Flame v18D-nightly-v4 base image?

I wasn't before, but I just updated (and clobbered and repulled backup-flame), and it doesn't seem to have helped.
What I see today is:

I/Gecko   (  935): [Child 935] ###!!! ASSERTION: style context has old rule node: 'mRoots[i]->RuleNode()->RuleTree() == mRuleTree', file /home/dbaron/builds/ssd/mozilla-central/mozilla/layout/style/nsStyleSet.cpp, line 317
I/Gecko   (  935): [Child 935] ###!!! ASSERTION: old rule tree still referenced: 'Not Reached', file /home/dbaron/builds/ssd/mozilla-central/mozilla/layout/style/nsStyleSet.cpp, line 2227

and then a bit later:

I/Gecko   (  935): [Child 935] ###!!! ASSERTION: destroying style context from old rule tree too late: 'styleSet->GetRuleTree() == mRuleNode->RuleTree() || styleSet->IsInRuleTreeReconstruct()', file /home/dbaron/builds/ssd/mozilla-central/mozilla/layout/style/nsStyleContext.cpp, line 136

PID 935 is the homescreen.
Interestingly, all the leaves appear to be display:none.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: