Closed Bug 392532 Opened 17 years ago Closed 17 years ago

[FIX] Infinite recursion crash when getting nsPIDOMWindow off docshell (switching View->Layout->Wide View)

Categories

(Core :: DOM: Core & HTML, defect, P3)

Product:
Core
Component:
DOM: Core & HTML
Type:
defect

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: bzbarsky, Assigned: jst)

References

Details

(Keywords: crash, regression)

Attachments

(2 files, 1 obsolete file)

One possible fix.
1.47 KB, patch
bzbarsky
: review+
bzbarsky
: superreview+
Details | Diff | Splinter Review
Same fix with assertion in docshell.
3.19 KB, patch
jst
: review+
jst
: superreview+
vlad
: approvalM9-
vlad
: approval1.9+
Details | Diff | Splinter Review
See bug 389634 comment 5.
Flags: blocking1.9?
Blocks: 389634
Keywords: crash
Assignee: nobody → jst
Flags: blocking1.9? → blocking1.9+
OS: Linux → All
Hardware: PC → All
Summary: Infinite recursion crash when getting nsPIDOMWindow off docshell → Infinite recursion crash when getting nsPIDOMWindow off docshell (switching View->Layout->Wide View)
A sample breakpad report: bp-5e291af5-79ba-11dc-bbe1-001a4bd46e84 (watch out, this may take a while to load)
Attached patch Disable the UI (obsolete) — — Splinter Review
So, I looked at bent's crash report, which is 9MB of HTML, and I triggered the crash myself, which generated a 1+MB dump that translates to an unknown amount of HTML, because I haven't been able to get crash-stats.m.o to deliver it without timing out. We've had better than two months of using this as a stress-test of the crash reporter, I think it's time to stop adding useless load to it.
Attachment #285571 - Flags: review?(mscott)
Shouldn't the patch for bug 389634 be backed out, instead?
What we really need to do is fix this bug...
This isn't ideal, but it should fix this problem (still need to test this here). Boris, do you think this is good enough, or do we need something that'd be safe for all embedders as well? I'm having a hard time thinking of a good way to fix this myself...
Attachment #286042 - Flags: superreview?(bzbarsky)
Attachment #286042 - Flags: review?(bzbarsky)
Comment on attachment 286042 [details] [diff] [review] One possible fix. Yeah, I haven't thought of a better solution either. I'd add an assert in docshell if someone tries to getInterface the window while we're inside EnsureScriptEnvironment, so if embeddors run into this they'll see the assert.
Attachment #286042 - Flags: superreview?(bzbarsky)
Attachment #286042 - Flags: superreview+
Attachment #286042 - Flags: review?(bzbarsky)
Attachment #286042 - Flags: review+
Attachment #285571 - Attachment is obsolete: true
Attachment #285571 - Flags: review?(mscott)
Attachment #286078 - Flags: superreview+
Attachment #286078 - Flags: review+
Attachment #286078 - Flags: approval1.9?
Comment on attachment 286078 [details] [diff] [review] Same fix with assertion in docshell. Requesting approvalM9 for this. If we care at all about Thunderbird for this beta, we need this, if not we can ship w/o this.
Attachment #286078 - Flags: approvalM9?
Comment on attachment 286078 [details] [diff] [review] Same fix with assertion in docshell. a=drivers after M9 freeze
Attachment #286078 - Flags: approvalM9?
Attachment #286078 - Flags: approvalM9-
Attachment #286078 - Flags: approval1.9?
Attachment #286078 - Flags: approval1.9+
Summary: Infinite recursion crash when getting nsPIDOMWindow off docshell (switching View->Layout->Wide View) → [FIX] Infinite recursion crash when getting nsPIDOMWindow off docshell (switching View->Layout->Wide View)
Fix checked in.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Depends on: 403574
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: