Closed Bug 621551 Opened 15 years ago Closed 7 years ago

Firefox 4.0b8 crash in [@ nsIFrame::GetOffsetToCrossDoc(nsIFrame const*, int) ]

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Platform:
x86
Windows 7
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: marcia, Assigned: tnikkel)

References

Details

(Keywords: crash)

Crash Data

Attachments

(2 files)

crash sooner so we get useful stacks
1.39 KB, patch
roc
: review+
mounir
: checkin+
Details | Diff | Splinter Review
zipped up testcase (uses enhanced privileges)
1.23 KB, application/zip
Details
Seen while reviewing B8 crash stats. Currently #52 on the list. http://tinyurl.com/265ha78 to the crashes which are all Windows. pogo.com football is mentioned twice in the comments. Sample from the stack: Frame Module Signature [Expand] Source 0 xul.dll nsIFrame::GetOffsetToCrossDoc layout/generic/nsFrame.cpp:3789 1 xul.dll nsIFrame::GetOffsetToCrossDoc layout/generic/nsFrame.cpp:3817 2 xul.dll nsIFrame::GetOffsetToCrossDoc layout/generic/nsFrame.cpp:3817 3 xul.dll nsIFrame::GetOffsetToCrossDoc layout/generic/nsFrame.cpp:3817 4 xul.dll nsIFrame::GetOffsetToCrossDoc layout/generic/nsFrame.cpp:3817 5 xul.dll nsIFrame::GetOffsetToCrossDoc layout/generic/nsFrame.cpp:381
There are two distinct types of these crashes: stack overflow crashes, and others.
I suspect the stack overflow crashes are where the two frames between which the offset is being computed are not in the same document tree. Based on same crash comments indicating hitting the back button this could be caused around document transition. A path forward would be to detect this situation and crash sooner so that we get a complete stack and see who is calling GetOffsetToCrossDoc after the document has been disconnected.
Is there a better way to do this?
Assignee: nobody → tnikkel
Attachment #536236 - Flags: review?(dbaron)
Comment on attachment 536236 [details] [diff] [review] crash sooner so we get useful stacks dbaron is away and may not have time for reviews.
Attachment #536236 - Flags: review?(dbaron) → review?(roc)
To be clear this is a patch that I'd like to land to get some crash stacks and then back out at some point.
Comment on attachment 536236 [details] [diff] [review] crash sooner so we get useful stacks Review of attachment 536236 [details] [diff] [review]: -----------------------------------------------------------------
Attachment #536236 - Flags: review?(roc) → review+
Landed that patch on cedar http://hg.mozilla.org/projects/cedar/rev/c52ed5e53db9
Whiteboard: [landed on cedar][leave open after merging to mozilla-central]
Pushed: http://hg.mozilla.org/mozilla-central/rev/c52ed5e53db9
Whiteboard: [landed on cedar][leave open after merging to mozilla-central] → [landed on cedar]
Whiteboard: [landed on cedar]
Attachment #536236 - Flags: checked-in+
Isn't this what we have NS_RUNTIMEABORT for?
Are we able to find crash stacks based on the location where NS_RUNTIMEABORT is called and not NS_RUNTIMEABORT or something it calls? I.e. I want to be able to find these crashes in crash stats.
Attachment #536236 - Flags: checked-in+ → checkin+
Crash Signature: [@ nsIFrame::GetOffsetToCrossDoc(nsIFrame const*, int) ]
I see a lot of stacks when updating plugin geometry. The question is, how does a frame that isn't in the same document tree as the root prescontext get to be a plugin geometry update frame? We could just check thats its in the same document tree as the root prescontext before proceeding, but it would be nice to know how that happens.
I'm crashing all the time with this stack, while trying to print on the Mac. On Windows, it seems a little bit harder to trigger. Let me know if you want a testcase, and I'll see if I can come up with one.
Never mind, here is a zipped up testcase, that automatically prints and toggles the iframes display a lot of times. It uses enhanced privileges. Unzip it, open the file named 'parentframe.htm', allow the enhanced privileges. Then, it should normally crash within 10 seconds or so. It does for me here, on windows trunk.
This might be fallout from the print cloning thing, bug 487667.
(In reply to comment #14) > I'm crashing all the time with this stack, while trying to print on the Mac. In general, when printing anything?
(In reply to comment #17) > (In reply to comment #14) > > I'm crashing all the time with this stack, while trying to print on the Mac. > In general, when printing anything? No, while 'testing'. See zipped up testcase, which is a result from this 'testing'.
I can reproduce the crash on linux if I change the print target to /tmp/print.pdf Unfortunately the stack is totally corrupted.
Thanks for the testcase, very valuable.
The testcase actually crashes in one of the documents that are being printed. At first I thought it was in a non-printing document because the prescontext type was not a printing type. But it is a document created for printing and the type not being set might be part of the problem. This makes the testcase less interesting because from the comments on crash-stats users aren't crashing when printing, and I don't think the issue in the testcase is likely to be related to the majority of our crashes.
I might have seen this crash in non-printing ways, not sure. I'm afraid I don't have time to investigate, though.
Depends on: 692109
Depends on: 770041
Crash Signature: [@ nsIFrame::GetOffsetToCrossDoc(nsIFrame const*, int) ] → [@ nsIFrame::GetOffsetToCrossDoc(nsIFrame const*, int) ] [@ nsIFrame::GetOffsetToCrossDoc ]
We still have a few of these crashes coming in. The signature have changed though. bp-5dc17938-8b19-497a-af31-29e512170413
Crash Signature: [@ nsIFrame::GetOffsetToCrossDoc(nsIFrame const*, int) ] [@ nsIFrame::GetOffsetToCrossDoc ] → [@ Abort | trying to get the offset between frames in different document hierarchies? | mozalloc_abort | NS_DebugBreak | nsIFrame::GetOffsetToCrossDoc ]
(In reply to Mats Palmgren (:mats) from comment #23) > We still have a few of these crashes coming in. The signature have changed > though. > bp-5dc17938-8b19-497a-af31-29e512170413 The GetOffsetTo call is coming from https://hg.mozilla.org/releases/mozilla-release/annotate/e81854d6ce91/layout/base/nsDisplayList.cpp#l1196 which gets the offset between aFrame and a frame reached from aFrame purely by calling GetCrossDocParentFrame. So the two frames should definitely be in same document hierarchy. Something must be very messed up.
Closing because no crash reported since 12 weeks.
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: