Closed
Bug 441561
Opened 17 years ago
Closed 16 years ago
DOM modification using JavaScript causes Access Violation [@ nsIsIndexFrame::CreateAnonymousContent] (appears to be NULL pointer)
Categories
(Core :: Layout, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: u315569, Unassigned)
References
()
Details
(Keywords: crash, testcase, Whiteboard: [sg:dos] 1.8 branch only)
Crash Data
Attachments
(1 file)
|
243 bytes,
text/html
|
Details |
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; WOW64; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.0.04506; .NET CLR 1.1.4322)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.14)
This sample code crashes FireFox:
<BODY onload="go()"><SCRIPT>
function go() {
o=document.createElement('samp');
document.body.appendChild(o);
o.innerHTML='<center></center><optGroup><input><style><isIndex>';
}
</SCRIPT></BODY>
Another example, appears to trigger the same bug:
<BODY onload="go()"><SCRIPT>
function go() {
o = document.createElement("custom");
document.body.appendChild(o);
o.innerHTML = "<blockQuote></blockQuote><optGroup></optGroup><input type=text><style></style><isIndex></isIndex>";
}
</SCRIPT></BODY>
Reproducible: Always
Steps to Reproduce:
Load one of these two URLs:
* http://skypher.com/SkyLined/Repro/FireFox/AccessViolation%2017e359d1%20(1).html
* http://skypher.com/SkyLined/Repro/FireFox/AccessViolation%2017e359d1%20(2).html
Actual Results:
FireFox crashes because of an Access Violation
Marked as security problem because I'm not sure if it is a NULL pointer or not.
|
||
Updated•17 years ago
|
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
Any reason why you think it is a duplicate? I hope it's not because I filed them with the same title - the crashes for the two different bugs are at two different addresses, which suggest they are two separate bugs. But then I haven't looked at the root cause, so you could well be right...
|
|
||
Comment 3•17 years ago
|
||
Ah, sorry. No, you may be right. Two very similar bugs filed in quick succession, I assumed it was a bit of clicking-mayhem. Sorry about that. You may, indeed, want to modify the title a bit for searchiness, at least.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
I would if I had something useful to put there - unfortunately I don't have the time to investigate. Feel free to change it to whatever you feel is more appropriate. I will be filing more similar bugs, I'm grouping them based on the code the crashes happen in, I'm assuming that's a good enough metric for determining if something is a duplicate quickly.
|
|
||
Comment 5•17 years ago
|
||
Can you also provide crash reporter ids for these bugs? Thanks.
This may be very well known to anybody who regularly uses FireFox, but what are these "crash reporter ids" you're talking about?
|
|
||
Comment 7•17 years ago
|
||
When you crash, the browser tries to submit a report and summary of the crash to a database, from there, we're able to generate a backtrace of the stack(s) involved in your crash, which can be very helpful in categorizing and understanding (and often fixing) bugs.
This should give you a good idea of how/where to find your crash-reports:
http://kb.mozillazine.org/Breakpad#Viewing_reports
It seems to me that if you have working repro files, you can generate your own crash reports. Unfortunately, I do not have a lot of spare time in which to investigate these issues, as I have quite a few to file and a lot of more pressing things to do. Should you fail to repro let me know and I will see what I can do.
|
||
Comment 9•17 years ago
|
||
You can just go to about:crashes and grab the links. They're a huge help, especially for developers who may not be able to reproduce it easily (on a different OS, etc.) -- thanks for the reports!
|
||
Comment 10•17 years ago
|
||
Berend-Jan filed it against branch, there we still use Talkback: http://kb.mozillazine.org/Talkback
Afaik, the bugs he filed, don't crash on trunk. Berend-Jan, if it crashes on trunk, please let us know.
|
Reporter | |
Comment 11•17 years ago
|
||
I only test on the default install. I do not use any crash reporters as they interfere with my own automation. If you really cannot repro this, let me know and I see if I can find some time at some point to investigate.
|
|
||
Comment 12•17 years ago
|
||
In this case, I do crash on branch, but not on trunk.
|
||
Updated•17 years ago
|
Product: Firefox → Core
QA Contact: general → general
|
|
||
Comment 13•17 years ago
|
||
From http://talkback-public.mozilla.org/search/start.jsp?search=2&type=iid&id=TB46895780Y :
nsIsIndexFrame::CreateAnonymousContent [mozilla/layout/forms/nsIsIndexFrame.cpp, line 215]
nsCSSFrameConstructor::CreateAnonymousFrames [mozilla/layout/base/nsCSSFrameConstructor.cpp, line 5885]
nsCSSFrameConstructor::CreateAnonymousFrames [mozilla/layout/base/nsCSSFrameConstructor.cpp, line 5772]
nsCSSFrameConstructor::ConstructHTMLFrame [mozilla/layout/base/nsCSSFrameConstructor.cpp, line 5706]
nsCSSFrameConstructor::ConstructFrameInternal [mozilla/layout/base/nsCSSFrameConstructor.cpp, line 7910]
nsCSSFrameConstructor::ConstructFrame [mozilla/layout/base/nsCSSFrameConstructor.cpp, line 7786]
nsCSSFrameConstructor::ProcessChildren [mozilla/layout/base/nsCSSFrameConstructor.cpp, line 12218]
nsCSSFrameConstructor::ConstructBlock [mozilla/layout/base/nsCSSFrameConstructor.cpp, line 13302]
nsCSSFrameConstructor::ConstructFrameByDisplayType [mozilla/layout/base/nsCSSFrameConstructor.cpp, line 6921]
nsCSSFrameConstructor::ConstructFrameInternal [mozilla/layout/base/nsCSSFrameConstructor.cpp, line 7974]
nsCSSFrameConstructor::ConstructFrame [mozilla/layout/base/nsCSSFrameConstructor.cpp, line 7786]
nsCSSFrameConstructor::ProcessInlineChildren [mozilla/layout/base/nsCSSFrameConstructor.cpp, line 13548]
nsCSSFrameConstructor::ConstructInline [mozilla/layout/base/nsCSSFrameConstructor.cpp, line 13356]
nsCSSFrameConstructor::ConstructFrameByDisplayType [mozilla/layout/base/nsCSSFrameConstructor.cpp, line 6813]
nsCSSFrameConstructor::ConstructFrameInternal [mozilla/layout/base/nsCSSFrameConstructor.cpp, line 7974]
nsCSSFrameConstructor::ConstructFrame [mozilla/layout/base/nsCSSFrameConstructor.cpp, line 7786]
nsCSSFrameConstructor::ProcessChildren [mozilla/layout/base/nsCSSFrameConstructor.cpp, line 12218]
nsCSSFrameConstructor::ConstructBlock [mozilla/layout/base/nsCSSFrameConstructor.cpp, line 13302]
nsCSSFrameConstructor::ConstructFrameByDisplayType [mozilla/layout/base/nsCSSFrameConstructor.cpp, line 6921]
etc..
I get a fix range between 2006-01-29 and 2006-02-02:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-01-29+06&maxdate=2006-02-02+09&cvsroot=%2Fcvsroot
Component: General → Layout
QA Contact: general → layout
Summary: DOM modification using JavaScript causes Access Violation (appears to be NULL pointer) → DOM modification using JavaScript causes Access Violation [@ nsIsIndexFrame::CreateAnonymousContent] (appears to be NULL pointer)
Version: unspecified → 1.8 Branch
|
|
||
Updated•17 years ago
|
|
||
Comment 14•17 years ago
|
||
I get this fix range on Linux: 2006-01-31-04 -- 2006-02-01-04
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-01-31+03%3A00&maxdate=2006-02-01+05%3A00&cvsroot=%2Fcvsroot
(I get the same range for bug 441559)
|
||
Comment 15•17 years ago
|
||
From checkin comments, the bugs fixed in that range: https://bugzilla.mozilla.org/buglist.cgi?bug_id=325404,317633,317633,325350,325169,324194,316177,324688,325348,305873,239136,239136,239136,325297,241774,303018,321757,325248,314700,324194,324946,303018,305096,263042,317633,320085,224503,325294,324058,320504
If you subtract the bugs that claim to have been fixed in 1.8.1 (Firefox 2) it's not a very interesting set:
https://bugzilla.mozilla.org/buglist.cgi?bug_id=224503,263042,303018,305873,314700,320085,324058,325248,325294,325404
|
|
||
Updated•16 years ago
|
Whiteboard: [sg:critical?] 1.8 branch only
|
|
||
Comment 16•16 years ago
|
||
|
|
||
Comment 17•16 years ago
|
||
In an opt build this looks like a null deref (stack like comment 13). In a debug build it's a JS_Assert with a completely different stack
###!!! ASSERTION: you can't dereference a NULL nsCOMPtr with opertor->().: ...
Assertion failure: !fp->dormantNext, at c:/dev/ff2/mozilla/js/src/jsapi.c:4447
JS_SaveFrameChain
XPCJSContextStack::Push
nsXPCThreadJSContextStackImpl::Push
nsXPConnect::WillProcessEvents
ListenerCaller::ListenerCaller
nsEventQueueImpl::ProcessPendingEvents
nsWindow::DispatchPendingEvents
nsWindow::ProcessMessage
nsWindow::WindowProc
If I slightly change the testcase to create a simple document
<html><body><samp id='o'></samp></body></html>
and then load
javascript:document.getElementById('o').innerHTML="<center></center><optGroup><input><style><isIndex>";void(0);
I reproduce the stack from comment 13 in a debug build. definitely a null dereference, in nsIsIndexFrame::CreateAnonymousContent mContent->GetDocument() returns a null document which is then dereferenced.
Whiteboard: [sg:critical?] 1.8 branch only → [sg:dos] 1.8 branch only
|
|
||
Comment 18•16 years ago
|
||
"WFM" sometime after the Firefox 2 branch
Status: NEW → RESOLVED
Closed: 17 years ago → 16 years ago
Flags: wanted1.9.0.x-
Flags: wanted1.8.1.x+
Resolution: --- → WORKSFORME
|
|
||
Updated•16 years ago
|
Group: core-security
|
Assignee | |
Updated•14 years ago
|
Crash Signature: [@ nsIsIndexFrame::CreateAnonymousContent]
You need to log in
before you can comment on or make changes to this bug.
Description
•