Closed
Bug 434035
Opened 17 years ago
Closed 16 years ago
Crash [@ nsGlobalWindow::FindInternal] when doing find on a deleted window
Categories
(Core :: DOM: Core & HTML, defect)
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)
359 bytes,
text/html
|
Details | |
1.05 KB,
patch
|
samuel.sidler+old
:
approval1.9.0.12+
|
Details | Diff | Splinter Review |
1.41 KB,
patch
|
martijn.martijn
:
review+
|
Details | Diff | Splinter Review |
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
Assignee | ||
Comment 1•17 years ago
|
||
This patch adds a null check for this bug and bug 434037.
Attachment #321270 -
Flags: review?(jst)
Comment 2•17 years ago
|
||
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+
Assignee | ||
Comment 3•17 years ago
|
||
With review comments addressed.
Attachment #321270 -
Attachment is obsolete: true
Attachment #321335 -
Flags: superreview+
Attachment #321335 -
Flags: review+
Assignee | ||
Comment 4•17 years ago
|
||
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?
Assignee | ||
Updated•17 years ago
|
Whiteboard: [RC2?]
Updated•17 years ago
|
Flags: blocking1.9.0.1?
Whiteboard: [RC2?] → [RC2-]
Updated•17 years ago
|
Flags: wanted1.9.0.x+
Flags: blocking1.9.0.1?
Flags: blocking1.9.0.1-
Assignee | ||
Updated•16 years ago
|
Assignee: nobody → martijn.martijn
Keywords: checkin-needed
Comment 5•16 years ago
|
||
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?
Updated•16 years ago
|
Attachment #321335 -
Flags: approval1.9? → approval1.9.1+
Comment 6•16 years ago
|
||
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
Comment 8•16 years ago
|
||
The patch in dupe (434037) has another null check in it that we might as well incorporate here when landing this.
Updated•16 years ago
|
Flags: blocking1.9.1? → blocking1.9.1-
Updated•16 years ago
|
Whiteboard: [RC2-] → [c-n: wait for comment 8, or not ?]
Comment 9•16 years ago
|
||
Unbitrotted patch that includes the other null-check from bug 434037.
Attachment #321335 -
Attachment is obsolete: true
Comment 10•16 years ago
|
||
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
Updated•16 years ago
|
Keywords: checkin-needed
Comment 11•16 years ago
|
||
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]
Updated•16 years ago
|
Keywords: checkin-needed → fixed1.9.1
Target Milestone: mozilla1.9.2a1 → mozilla1.9.1b3
Comment 12•16 years ago
|
||
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.
Keywords: fixed1.9.1 → verified1.9.1
Comment 13•16 years ago
|
||
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
Updated•16 years ago
|
Whiteboard: [sg:dos] null deref
Comment 15•16 years ago
|
||
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?
Comment 16•16 years ago
|
||
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...
Updated•16 years ago
|
Flags: blocking1.9.0.12? → blocking1.9.0.12+
Comment 17•16 years ago
|
||
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?
Updated•16 years ago
|
Attachment #352983 -
Flags: approval1.9.0.12? → approval1.9.0.12+
Comment 18•16 years ago
|
||
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
Comment 19•16 years ago
|
||
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.
Keywords: fixed1.9.0.12 → verified1.9.0.12
Comment 21•16 years ago
|
||
Adding patch for 1.8.0 version. Thanks for your review in advance.
Attachment #387409 -
Flags: review?(martijn.martijn)
Assignee | ||
Comment 22•16 years ago
|
||
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+
Comment 23•16 years ago
|
||
(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.
Assignee | ||
Comment 24•16 years ago
|
||
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.
Updated•14 years ago
|
Crash Signature: [@ nsGlobalWindow::FindInternal]
Updated•6 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•