RESOLVED FIXED 103966
REGRESSION(r136467): This patch made several tests(e.g. acid3) crash. (Requested by tasak on #webkit). 
https://bugs.webkit.org/show_bug.cgi?id=103966
Summary REGRESSION(r136467): This patch made several tests(e.g. acid3) crash. (Reques...
WebKit Review Bot
Reported 2012-12-03 20:37:31 PST
http://trac.webkit.org/changeset/136467 broke the build: This patch made several tests(e.g. acid3) crash. (Requested by tasak on #webkit). This is an automatic bug report generated by the sheriff-bot. If this bug report was created because of a flaky test, please file a bug for the flaky test (if we don't already have one on file) and dup this bug against that bug so that we can track how often these flaky tests case pain. "Only you can prevent forest fires." -- Smokey the Bear
Attachments
ROLLOUT of r136467 (95.17 KB, patch)
2012-12-03 20:38 PST, WebKit Review Bot 		no flags
DetailsFormatted DiffDiff
Patch (2.37 KB, patch)
2012-12-03 20:49 PST, Rafael Weinstein 		no flags
DetailsFormatted DiffDiff
Patch (2.21 KB, patch)
2012-12-03 20:59 PST, Rafael Weinstein 		no flags
DetailsFormatted DiffDiff
Patch (1.70 KB, patch)
2012-12-03 21:08 PST, Rafael Weinstein 		no flags
DetailsFormatted DiffDiff
Show Obsolete (3) View All Add attachment proposed patch, testcase, etc.
WebKit Review Bot
Comment 1 2012-12-03 20:38:29 PST
Created attachment 177402 [details] ROLLOUT of r136467 Any committer can land this patch automatically by marking it commit-queue+. The commit-queue will build and test the patch before landing to ensure that the rollout will be successful. This process takes approximately 15 minutes. If you would like to land the rollout faster, you can use the following command: webkit-patch land-attachment ATTACHMENT_ID where ATTACHMENT_ID is the ID of this attachment.
Takashi Sakamoto
Comment 2 2012-12-03 20:44:33 PST
These crashes will be fixed by another (valid) patch. We don't need this rollout. Best regards, Takashi Sakamoto
Rafael Weinstein
Comment 3 2012-12-03 20:49:53 PST
Reopening to attach new patch.
Rafael Weinstein
Comment 4 2012-12-03 20:49:59 PST
Created attachment 177403 [details] Patch
Elliott Sprehn
Comment 5 2012-12-03 20:52:00 PST
Comment on attachment 177403 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=177403&action=review > Source/WebCore/dom/ContainerNode.cpp:315 > + // ASSERT(document() == newChild->document()); This assert was fine, can you leave it?
Rafael Weinstein
Comment 6 2012-12-03 20:59:22 PST
Created attachment 177405 [details] Patch
Rafael Weinstein
Comment 7 2012-12-03 21:08:22 PST
Created attachment 177409 [details] Patch
Rafael Weinstein
Comment 8 2012-12-03 21:16:58 PST
Comment on attachment 177403 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=177403&action=review >> Source/WebCore/dom/ContainerNode.cpp:315 >> + // ASSERT(document() == newChild->document()); > > This assert was fine, can you leave it? Good catch. Done.
Csaba Osztrogonác
Comment 9 2012-12-03 23:49:37 PST
Comment on attachment 177409 [details] Patch Clearing flags on attachment: 177409 Committed r136480: <http://trac.webkit.org/changeset/136480>
Csaba Osztrogonác
Comment 10 2012-12-03 23:49:43 PST
All reviewed patches have been landed. Closing bug.
Jussi Kukkonen (jku)
Comment 11 2012-12-03 23:50:58 PST
Comment on attachment 177409 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=177409&action=review > Source/WebCore/dom/ContainerNode.cpp:700 > + // blindly calls paserAppendChild on the docType its passed. parserAppendChild
Darin Adler
Comment 12 2012-12-04 09:54:54 PST
Comment on attachment 177409 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=177409&action=review >> Source/WebCore/dom/ContainerNode.cpp:700 >> + // FIXME: This assert should be valid, but DOMImplementation::createDocument() >> + // blindly calls paserAppendChild on the docType its passed. > > parserAppendChild The comment here is confusing and seems to be introducing FUD. This function has a contract with it’s callers, and no "higher purpose". So we must decide whether it’s OK to call parserAppendChild on a DocumentType in this way or not. If it’s OK, then the assertion is *not* correct and should to be rewritten and not left in commented-out. If it’s not OK, then there’s a bug in DOMImplementation::createDocument that needs to be fixed. The term “blindly" here anthropomorphizes the code but doesn’t make it clear what our design is.
Rafael Weinstein
Comment 13 2012-12-04 10:20:32 PST
Apologies for the editorial. I'll refrain from that from now on. I'm going to attempt to land a fix which allows the assert to be replaced. I'll cc you on that.
Note You need to log in before you can comment on or make changes to this bug.