Bug 3653 - Safari crash on call to DOMImplementation.createDocumentType
Summary: Safari crash on call to DOMImplementation.createDocumentType
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: 412
Hardware: Mac OS X 10.4
: P2 Major
Assignee: Anders Carlsson
Depends on:
Reported: 2005-06-22 14:26 PDT by Curt Arnold
Modified: 2005-07-16 00:00 PDT (History)
0 users

See Also:

Test case [CRASH] (565 bytes, text/html)
2005-06-22 20:18 PDT, David Kilzer (:ddkilzer)
no flags Details
Don't assume that nodes always have a document pointer. (3.08 KB, patch)
2005-06-24 07:23 PDT, Anders Carlsson
darin: review-
Details | Formatted Diff | Diff
Add always-0 documentptr (3.40 KB, patch)
2005-07-08 18:26 PDT, Anders Carlsson
hyatt: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Curt Arnold 2005-06-22 14:26:36 PDT
The following document will crash Safari (2.0/412) and a recent CVS build of WebKit:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" 
    "http://www.w3.org/TR/html4/strict.dtd" >
		<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
		<script type='text/javascript'>function loadComplete() { 
      var docType = document.implementation.createDocumentType("", 
         "http://www.example.com/", "myDoc.dtd");
	<body onload="loadComplete()">

The expected behavior is the raising of an exception of some type, either a NOT_IMPLEMENTED_ERR 
exception since HTML-only implementations are not required to implement createDocumentType or a 
INVALID_CHARACTER_ERR since "" is not a valid tag name (INVALID_CHARACTER_ERR was stretched a 
bit to cover any failure to match the name production).

Crash report:

Date/Time:      2005-06-22 16:24:02.142 -0500
OS Version:     10.4.1 (Build 8B15)
Report Version: 3

Command: Safari
Path:    /Applications/Safari.app/Contents/MacOS/Safari
Parent:  tcsh [373]

Version:        2.0 (412)
Build Version:  1
Project Name:   WebBrowser
Source Version: 4120000

PID:    4354
Thread: 0

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x00000004

Thread 0 Crashed:
0   com.apple.WebCore              	0x018f5d48 DOM::DocumentPtr::document() const + 20 
1   com.apple.WebCore              	0x018f5e28 DOM::NodeImpl::getDocument() const + 40 
2   com.apple.WebCore              	0x0169b7f8 KJS::getDOMNode(KJS::ExecState*, DOM::NodeImpl*) + 
116 (kjs_dom.cpp:1654)
3   com.apple.WebCore              	0x0169c880 KJS::DOMDOMImplementationProtoFunc::tryCall
(KJS::ExecState*, KJS::Object&, KJS::List const&) + 972 (kjs_dom.cpp:1334)
4   com.apple.WebCore              	0x0168f42c KJS::DOMFunction::call(KJS::ExecState*, KJS::Object&, 
KJS::List const&) + 88 (kjs_binding.cpp:76)
5   com.apple.JavaScriptCore       	0x0102bd0c KJS::FunctionCallNode::evaluate(KJS::ExecState*) + 932 
Comment 1 David Kilzer (:ddkilzer) 2005-06-22 20:18:03 PDT
Confirmed crash on build 412 and TOT (CVS TIP) as of 6/22/2005 8:00 PM CDT.
Comment 2 David Kilzer (:ddkilzer) 2005-06-22 20:18:51 PDT
Created attachment 2563 [details]
Test case [CRASH]
Comment 3 Anders Carlsson 2005-06-24 07:23:38 PDT
Created attachment 2627 [details]
Don't assume that nodes always have a document pointer.

The crash is due to the assumption that dom nodes always have a document
pointer. This isn't true for nodes created with createElementType, as they
haven't been associated with any document.

(I'm not sure if DOMNode::Mark() needs to be fixed aswell)
Comment 4 Darin Adler 2005-06-24 08:14:21 PDT
Comment on attachment 2627 [details]
Don't assume that nodes always have a document pointer.

I'm not sure about the patch -- if these document type nodes aren't attached to
any document, perhaps there will be a lifetime issue for the wrappers? Maybe
you'll get two different wrappers for the same document type node, so that if
you attached a property to it early on and later got it once it was attached to
a document the property would be gone.
Comment 5 Darin Adler 2005-06-24 08:21:17 PDT
Comment on attachment 2627 [details]
Don't assume that nodes always have a document pointer.

Yes, DOMNode::mark() also needs to be updated to handle this case. If there's
no document, it should just take the early return that calls DOMObject::mark().

And DOMNode::getValueProperty needs an update too.

I'm thinking that patching each and every place that calls getDocument could be
a losing battle -- we might need to change the way document type nodes are
created to at least point them at a DocumentPtr that is 0 rather than having
the DocumentPtr itself be 0. There could be a single "always-0" DocumentPtr for
use in cases like that.

Once we do that we could revisit the things patched here -- we wouldn't have to
patch anything that checks the result of getDocument() for 0, only the things
that assume it's non-0.
Comment 6 Anders Carlsson 2005-07-08 18:26:20 PDT
Created attachment 2872 [details]
Add always-0 documentptr

Here's a new patch which adds a nullDocumentPtr().
Comment 7 Dave Hyatt 2005-07-09 14:05:01 PDT
Comment on attachment 2872 [details]
Add always-0 documentptr