Closed Bug 434035 Opened 16 years ago Closed 16 years ago

Crash [@ nsGlobalWindow::FindInternal] when doing find on a deleted window

Categories

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

x86
Windows XP
defect
Not set
critical

Tracking

()

VERIFIED FIXED
mozilla1.9.1b3

People

(Reporter: martijn.martijn, Assigned: martijn.martijn)

References

Details

(4 keywords, Whiteboard: [sg:dos] null deref)

Crash Data

Attachments

(3 files, 2 obsolete files)

Attached file testcase
See testcase, which crashes trunk and branch builds after 300ms.

http://crash-stats.mozilla.com/report/index/c897db66-232e-11dd-8adc-001cc45a2ce4?p=1
0  	xul.dll  	nsGlobalWindow::FindInternal  	 mozilla/dom/src/base/nsGlobalWindow.cpp:6305
1 	xul.dll 	nsGlobalWindow::Find 	mozilla/dom/src/base/nsGlobalWindow.cpp:6285
2 	xul.dll 	NS_InvokeByIndex_P 	mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp:101
3 	xul.dll 	XPCWrappedNative::CallMethod 	mozilla/js/src/xpconnect/src/xpcwrappednative.cpp:2388
Attached patch patch (obsolete) — Splinter Review
This patch adds a null check for this bug and bug 434037.
Attachment #321270 - Flags: review?(jst)
Comment on attachment 321270 [details] [diff] [review]
patch

- In nsGlobalWindow::ShowModalDialog():

+  if (!mDocShell)
+    return NS_ERROR_FAILURE;

You could do this earlier than this, i.e. right after setting *aRetVal to null, and use NS_ENSURE_TRUE here as you do in the find code.

r+sr=jst
Attachment #321270 - Flags: superreview+
Attachment #321270 - Flags: review?(jst)
Attachment #321270 - Flags: review+
Attached patch patchv2 (obsolete) — Splinter Review
With review comments addressed.
Attachment #321270 - Attachment is obsolete: true
Attachment #321335 - Flags: superreview+
Attachment #321335 - Flags: review+
Comment on attachment 321335 [details] [diff] [review]
patchv2

I have no idea what to do with the patch. Tinderbox says I need to land it in trunk/Hg (?).
Attachment #321335 - Flags: approval1.9?
Whiteboard: [RC2?]
Flags: blocking1.9.0.1?
Whiteboard: [RC2?] → [RC2-]
Flags: wanted1.9.0.x+
Flags: blocking1.9.0.1?
Flags: blocking1.9.0.1-
Assignee: nobody → martijn.martijn
Keywords: checkin-needed
this should have landed a while ago.  It would have also fixed 434037.  martijn, can you land this if it get approved?
Flags: blocking1.9.1?
Attachment #321335 - Flags: approval1.9? → approval1.9.1+
This is not a 1.9.1 blocker, but it's a trivial null check so there's no reason not to take it. I approved the patch, please land asap. Also opening this bug up to the public as this is simply a null dereference crash, so not an exploitable crash.
Group: core-security
The patch in dupe (434037) has another null check in it that we might as well incorporate here when landing this.
Flags: blocking1.9.1? → blocking1.9.1-
Whiteboard: [RC2-] → [c-n: wait for comment 8, or not ?]
Unbitrotted patch that includes the other null-check from bug 434037.
Attachment #321335 - Attachment is obsolete: true
http://hg.mozilla.org/mozilla-central/rev/032320654a33
Status: NEW → RESOLVED
Closed: 16 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Whiteboard: [c-n: wait for comment 8, or not ?]
Target Milestone: --- → mozilla1.9.2a1
Keywords: checkin-needed
Comment on attachment 352983 [details] [diff] [review]
What I am landing
[Checkin: Comment 10 & 11]

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/b1c1991e4af0
Attachment #352983 - Attachment description: What I am landing → What I am landing [Checkin: Comment 10 & 11]
Target Milestone: mozilla1.9.2a1 → mozilla1.9.1b3
verified fixed on the 1.9.1 branch using  Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20081222 Shiretoko/3.1b3pre. Adding verified keyword.
Verified fixed on the trunk using  Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20081222 Minefield/3.2a1pre. No crash using testcase.
Status: RESOLVED → VERIFIED
Whiteboard: [sg:dos] null deref
Per bug 492980, this happens on Firefox 3.0.x as well. Is this something we should fix in a 1.9.0.x release?
Flags: blocking1.9.0.12?
It's a perfectly safe patch, so I wouldn't be worried about taking it, but it's also a non-exploitable crash, and a pretty rare one at that. So it's not strictly necessary for 1.9.0, but again, I'd be fine with taking it...
Flags: blocking1.9.0.12? → blocking1.9.0.12+
Comment on attachment 352983 [details] [diff] [review]
What I am landing
[Checkin: Comment 10 & 11]

Approved for 1.9.0.12, a=dveditz for release-drivers
Attachment #352983 - Flags: approval1.9.0.12?
Attachment #352983 - Flags: approval1.9.0.12? → approval1.9.0.12+
Checking in dom/src/base/nsGlobalWindow.cpp;
/cvsroot/mozilla/dom/src/base/nsGlobalWindow.cpp,v  <--  nsGlobalWindow.cpp
new revision: 1.1020; previous revision: 1.1019
Keywords: fixed1.9.0.12
Verified for 1.9.0.12 with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.12pre) Gecko/2009070105 GranParadiso/3.0.12pre (.NET CLR 3.5.30729). Testcase no longer crashes as it does in 1.9.0.11.
Reproducible even on 1.8.0.
Flags: wanted1.8.1.x+
Adding patch for 1.8.0 version. Thanks for your review in advance.
Attachment #387409 - Flags: review?(martijn.martijn)
Comment on attachment 387409 [details] [diff] [review]
Patch for 1.8.0 version

I haven't test the patch in a 1.8.1 build, but it seems fine to me.
Don't you also need to use this part?
+  NS_ENSURE_TRUE(mDocShell, NS_ERROR_FAILURE);
..which the original patch has?
Attachment #387409 - Flags: review?(martijn.martijn) → review+
(In reply to comment #22)
> (From update of attachment 387409 [details] [diff] [review])
> I haven't test the patch in a 1.8.1 build, but it seems fine to me.
> Don't you also need to use this part?
> +  NS_ENSURE_TRUE(mDocShell, NS_ERROR_FAILURE);
> ..which the original patch has?

Thanks. There's no nsGlobalWindow::ShowModalDialog method in 1.8.0 version so I skipped this code. I tried the test case and with the patch it's working well.
Ah, yeah, of course, that part of the patch was for bug 434037, which uses a feature that isn't on 1.8.1 branch, afaik.
Crash Signature: [@ nsGlobalWindow::FindInternal]
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: