Open Bug 707699 Opened 13 years ago Updated 2 years ago

crash nsBlockFrame::GetChildLists

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Version:
9 Branch
Platform:
x86
Windows 7
Type:
defect

Tracking

()

Tracking Flags:
Tracking Status
firefox9 + ---
firefox10 - ---
firefox40 --- affected
firefox47 --- affected
firefox48 --- wontfix
firefox49 --- fix-optional
firefox-esr45 --- affected
firefox50 --- fix-optional
firefox51 --- fix-optional

People

(Reporter: kairo, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: crash, regression)

Crash Data

This bug was filed from the Socorro interface and is report bp-a021ac2b-c558-4f40-b878-226062111203 . ============================================================= Top stack frames: 0 xul.dll nsBlockFrame::GetChildLists layout/generic/nsBlockFrame.cpp:612 1 xul.dll nsFrameManager::ReResolveStyleContext layout/base/nsFrameManager.cpp:1510 2 xul.dll nsFrameManager::ReResolveStyleContext layout/base/nsFrameManager.cpp:1548 3 xul.dll nsFrameManager::ReResolveStyleContext layout/base/nsFrameManager.cpp:1569 I looked at multiple crashes in https://crash-stats.mozilla.com/report/list?signature=nsBlockFrame%3A%3AGetChildLists%28nsTArray%3Cmozilla%3A%3Alayout%3A%3AFrameChildList%2C%20nsTArrayDefaultAllocator%3E*%29 and it looks like only stack frames #0 and #1 are the same in all of them, #2 is either line 1548 or 1569 of nsFrameManager.cpp and below they differ, probable by what CSS is in use on different calls (that's purely my guess as a non-coder). This happens in 9 (beta), 10 (Aurora) and 11 (Nightly), and has risen up in the last days on 9.0b4 builds (to #27 overall in 9.* data yesterday, with 101 crashes per million ADU). In the last 4 weeks, this signature was not seen on Firefox 8 or lower, so this is a regression with Firefox 9.
tracking-firefox10: --- → ?
tracking-firefox9: --- → ?
This is #16 on 9.* yesterday, #13 in the 9.0b4 topcrash list.
Nothing jumps out in the correlations, so I think we should try to get some URLs to reproduce. 85% (86/101) vs. 77% (22247/28813) testpilot@labs.mozilla.com (Mozilla Labs - Test Pilot, https://addons.mozilla.org/addon/13661) 7% (7/101) vs. 0% (40/28813) {317B5128-0B0B-49b2-B2DB-1E7560E16C74} (SeoQuake SEO extension, https://addons.mozilla.org/addon/3036) 7% (7/101) vs. 0% (114/28813) {ada4b710-8346-4b82-8199-5de2b400a6ae} (ReminderFox, https://addons.mozilla.org/addon/1191) 6% (6/101) vs. 0% (24/28813) {056d0610-e44d-11df-bccf-0800200c9a66} 6% (6/101) vs. 0% (27/28813) {394DCBA4-1F92-4f8e-8EC9-8D2CB90CB69B}
Keywords: needURLs
94.6 % of the crashes happen on Windows 7. I cannot seem to get URLs, but looking at some of them manually it seems the crashes are happening quite a bit on game sites. Will keep digging.
OS: Windows NT → Windows 7
It first appeared in 9.0a1/20110826 but latter it was discontinuous from build to build so the regression range can't be narrowed down. It's similar (dupe?) to bug 708206. One comment mentions Facebook: bp-d76db119-be5b-4fb1-ba08-a27242111207.
Version: Trunk → 9 Branch
Not showing up in 9.0b5 in the top 300. We can continue to track and see what happens as we ramp up for b5.
Given the low crash volume, untracking for FF10.
tracking-firefox10: + → -
[rkaiser@cm-fs01 ~]$ gunzip --stdout /data/security_group/crash_urls/20120307-crashdata.csv.gz | awk -W compat -F\t '$1 ~ /nsBlockFrame::GetChildLists/ {print $2}' | sort | uniq -c | sort -nr 7 \N 4 3 http://www.facebook.com/ 2 about:blank 1 http://www.youtube.com/watch?v=50HQ3zL_Jdw 1 http://www.wawacity.ws/1S/explorer-les-films?search=twolatgh 1 http://www.terra.com.br/portal/ 1 http://www.orkut.com.br/Main#Application?... 1 http://www.google.de/search?tbm=isch&hl=de&source=hp&biw=1280&bih=877&q=danny+saucedo&... 1 http://www.google.co.in/search?q=holi+colorful+faces& 1 http://www.facebook.com/profile.php?id=1763004692 1 http://www.facebook.com/profile.php?id=100001679063215&sk=wall&notif_t=wall 1 http://www.facebook.com/profile.php?id=100000697008552&ref=tn_tnmn 1 http://www.facebook.com/profile.php?id=100000127487063 1 http://www.facebook.com/messages/... 1 http://www.facebook.com/messages/... 1 http://www.facebook.com/groups/230563310353162/ 1 http://www.facebook.com/ajax/pagelet/generic.php/PhotoViewerPagelet?... 1 http://www.facebook.com/ajax/pagelet/generic.php/PhotoViewerInitPagelet?... 1 http://www.facebook.com/ajax/pagelet/generic.php/MoreStoriesPagelet?... 1 http://www.facebook.com/ajax/pagelet/generic.php/MoreStoriesPagelet?... 1 http://www.facebook.com/ajax/pagelet/generic.php/MoreStoriesPagelet?... 1 http://www.facebook.com/ajax/pagelet/generic.php/MoreStoriesPagelet?... 1 http://www.ebay.de/sch/Werkzeuge-/30896/i.html 1 http://www.ebay.de/sch/Mercedes-Benz-/9855/i.html?Fahrzeugart=Limousine&_trkparms=... 1 http://www.coach.com/online/handbags/PoppyLandingView?langId=-1&storeId=10551&catalogId=10051&contentName=/CompanyInformation/CoachNews/poppylanding&LOC=LN1 1 <adult entertainment / pr0n URL> 1 http://vk.com/al_profile.php?... 1 http://tweepi.com/tools/follow_by_followers#40 1 https://www.facebook.com/login.php?login_attempt=1 1 https://mail.google.com/mail/?shva=1#inbox/... 1 http://otvet.mail.ru/question/37170185/ 1 http://demotywatory.pl/poczekalnia/page/6 "..." is where I removed potentially privacy-related parts (I hope Facebook profile and group IDs are still OK), and I noted where I removed the whole URL, I hopes we don't need to watch porn to reproduce.
Keywords: needURLs
Adding qawanted now that we have URLs.
Keywords: qawanted
I looked at correlations again for 10 and 11 and one extension that showed up in both is Tin Eye. Adding that in the mix when I try some of the URLs in Comment 7. nsBlockFrame::GetChildLists(nsTArray<mozilla::layout::FrameChildList, nsTArrayDefaultAllocator>*)|EXCEPTION_ACCESS_VIOLATION_READ (11 crashes) 9% (1/11) vs. 0% (10/79458) beamgeraet@web.de (Youtube Music Player, https://addons.mozilla.org/addon/10727) 9% (1/11) vs. 0% (165/79458) tineye@ideeinc.com (TinEye Reverse Image Search, https://addons.mozilla.org/addon/8922) 9% (1/11) vs. 1% (473/79458) adblockpopups@jessehakanen.net 9% (1/11) vs. 1% (743/79458) testpilot@labs.mozilla.com (Mozilla Labs - Test Pilot, https://addons.mozilla.org/addon/13661) 9% (1/11) vs. 1% (1085/79458) {23fcfd51-4958-4f00-80a3-ae97e717ed8b}
Not able to reproduce with any of the URLs so far, even with Tin Eye installed.
Mozilla/5.0 (Windows NT 6.1; rv:25.0) Gecko/20130725 Firefox/25.0 I couldn't reproduce the crash on the latest Nightly after installing the add-ons that I found in Comments 2 and 9 (ReminderFox, SeoQuake, Test Pilot and TinEye Reverse Image Search) and navigating to all the listed URL's in Comment 7. I also could not find any crash reports related with the signature: [@ nsBlockFrame::GetChildLists(nsTArray<mozilla::layout::FrameChildList, nsTArrayDefaultAllocator>*)] I'm removing the qawanted keyword for now, please let me know if anything else is needed from the QA side.
Keywords: qawanted
Crash Signature: [@ nsBlockFrame::GetChildLists(nsTArray<mozilla::layout::FrameChildList, nsTArrayDefaultAllocator>*)] → [@ nsBlockFrame::GetChildLists(nsTArray<mozilla::layout::FrameChildList, nsTArrayDefaultAllocator>*)] [@ nsBlockFrame::GetChildLists(nsTArray<mozilla::layout::FrameChildList>*)]
Got this signature on Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:40.0) Gecko/20100101 Firefox/40.0 ID:20150402030207 CSet: d222742756c4 Report ID Date Submitted bp-b223dd51-cc85-456b-b279-0c6092150403 03/04/2015 03:42 a.m. Seems to be some sort of e10s shutdown crash (i.e. I get "embarrassed tabs" while shutting down the system without closing Nightly first). Kindly let me know if there's anything worth collecting or if my crash is a separate bug.
status-firefox40: --- → affected
Flags: needinfo?(kairo)
(In reply to alex_mayorga from comment #12) > Kindly let me know if there's anything worth collecting or if my crash is a > separate bug. It's probably this one, but I don't know what else you can provide as I'm not a developer. FWIW, this is a low-volume crash that's ongoing in current versions.
Flags: needinfo?(kairo)
Crash Signature: [@ nsBlockFrame::GetChildLists(nsTArray<mozilla::layout::FrameChildList, nsTArrayDefaultAllocator>*)] [@ nsBlockFrame::GetChildLists(nsTArray<mozilla::layout::FrameChildList>*)] → [@ nsBlockFrame::GetChildLists(nsTArray<mozilla::layout::FrameChildList, nsTArrayDefaultAllocator>*)] [@ nsBlockFrame::GetChildLists(nsTArray<mozilla::layout::FrameChildList>*)] [@ nsBlockFrame::GetChildLists]
Crash volume for signature 'nsBlockFrame::GetChildLists': - nightly(version 50):0 crashes from 2016-06-06. - aurora (version 49):0 crashes from 2016-06-07. - beta (version 48):343 crashes from 2016-06-06. - release(version 47):853 crashes from 2016-05-31. - esr (version 45):72 crashes from 2016-04-07. Crash volume on the last weeks: W. N-1 W. N-2 W. N-3 W. N-4 W. N-5 W. N-6 W. N-7 - nightly 0 0 0 0 0 0 0 - aurora 0 0 0 0 0 0 0 - beta 43 53 51 43 59 35 42 - release 120 109 125 103 128 117 112 - esr 7 7 6 8 8 11 6 Affected platform: Windows
status-firefox47: --- → affected
status-firefox48: --- → affected
status-firefox-esr45: --- → affected
QA Whiteboard: qa-not-actionable
Severity: critical → S2

I think this is a similar situation to what tnikkel described in bug 1708808 comment 6; looking at recent reports, it looks like we're crashing while walking the whole frame tree, and we're tripping over some corruption that was left behind by something that went wrong earlier.

bp-25809414-9c40-4965-9da8-cb5390221013 is a crash with this GetChildLists signature, inside of MarkFramesInSubtreeApproximatelyVisible (the function that bug 1708808 is about, which walks the whole frame tree). We also have bp-968acb38-75db-47d6-beea-8b69c0221013 nsIFrame::ClearInvalidationStateBits which similarly walks the whole frame tree.

See Also: → 1708808
Crash Signature: [@ nsBlockFrame::GetChildLists(nsTArray<mozilla::layout::FrameChildList, nsTArrayDefaultAllocator>*)] [@ nsBlockFrame::GetChildLists(nsTArray<mozilla::layout::FrameChildList>*)] [@ nsBlockFrame::GetChildLists] → [@ nsBlockFrame::GetChildLists(nsTArray<mozilla::layout::FrameChildList, nsTArrayDefaultAllocator>*)] [@ nsBlockFrame::GetChildLists(nsTArray<mozilla::layout::FrameChildList>*)] [@ nsBlockFrame::GetChildLists] [@ nsContainerFrame::GetChildLists]

Since the crash volume is low (less than 15 per week), the severity is downgraded to S3. Feel free to change it back if you think the bug is still critical.

For more information, please visit auto_nag documentation.

Severity: S2 → S3
Crash Signature: [@ nsBlockFrame::GetChildLists(nsTArray<mozilla::layout::FrameChildList, nsTArrayDefaultAllocator>*)] [@ nsBlockFrame::GetChildLists(nsTArray<mozilla::layout::FrameChildList>*)] [@ nsBlockFrame::GetChildLists] [@ nsContainerFrame::GetChildLists] → [@ nsBlockFrame::GetChildLists] [@ nsBlockFrame::GetChildLists] [@ nsBlockFrame::GetChildLists] [@ nsContainerFrame::GetChildLists]
You need to log in before you can comment on or make changes to this bug.