45737 2010-09-14 02:27:46 -0700 [Chromium] fast/frames/frame-limit.html is slow on debug bots 2013-04-09 16:27:56 -0700 1 1 1 Unclassified WebKit Tools / Tests 528+ (Nightly build) PC OS X 10.5 RESOLVED WONTFIX P2 Normal --- 45365 0 podivilov webkit-unassigned abarth adamk commit-queue dglazkov dpranke eric inferno jchaffraix webkit.review.bot oldest_to_newest 278782 0 podivilov 2010-09-14 02:27:46 -0700 [Chromium] fast/frames/frame-limit.html is crashing on debug bots after r67179:r67353 roll 278820 1 podivilov 2010-09-14 04:55:06 -0700 http://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=fast%2Fframes%2Fframe-limit.html 280051 2 67789 podivilov 2010-09-16 06:28:54 -0700 Created attachment 67789 Proposed patch. Regressed in r67182. In HTMLFrameOwnerElement::willRemove: frame->loader()->frameDetached() causes content frame destruction, then frame->disconnectOwnerElement() crashes. 280145 3 67789 dglazkov 2010-09-16 09:31:03 -0700 Comment on attachment 67789 Proposed patch. View in context: https://bugs.webkit.org/attachment.cgi?id=67789&action=prettypatch > WebCore/html/HTMLFrameOwnerElement.cpp:57 > + RefPtr<Frame> protect(frame); Aw crap, frameDetached calls FrameLoader::detachFromParent(), which in turn may destroy the frame. Good catch. I see that this is necessary, I just don't like that we have to double-protect it (once here and once in detachFromParent). I also don't like that we end up calling disconnectedOwnerElement twice in such cases. 280243 4 67789 commit-queue 2010-09-16 11:53:29 -0700 Comment on attachment 67789 Proposed patch. Rejecting patch 67789 from commit-queue. Failed to run "['WebKitTools/Scripts/run-webkit-tests', '--no-launch-safari', '--exit-after-n-failures=1', '--wait-for-httpd', '--quiet']" exit_code: 1 Last 500 characters of output: sts Testing 21299 test cases. websocket/tests/bad-sub-protocol-empty.html -> timed out Sampling process 27542 for 10 seconds with 10 milliseconds of run time between samples Sampling completed, processing symbols... Sample analysis of process 27542 written to file /Users/eseidel/Library/Logs/DumpRenderTree/HangReport.txt Exiting early after 1 failures. 21254 tests run. 562.20s total testing time 21253 test cases (99%) succeeded 1 test case (<1%) timed out 33 test cases (<1%) had stderr output Full output: http://queues.webkit.org/results/4042030 280259 5 67789 eric 2010-09-16 12:14:17 -0700 Comment on attachment 67789 Proposed patch. I believe this test is just flaky. 280298 6 67789 commit-queue 2010-09-16 13:18:44 -0700 Comment on attachment 67789 Proposed patch. Clearing flags on attachment: 67789 Committed r67659: <http://trac.webkit.org/changeset/67659> 280299 7 commit-queue 2010-09-16 13:18:49 -0700 All reviewed patches have been landed. Closing bug. 280324 8 webkit.review.bot 2010-09-16 13:42:32 -0700 http://trac.webkit.org/changeset/67659 might have broken Qt Linux Release The following changes are on the blame list: http://trac.webkit.org/changeset/67659 http://trac.webkit.org/changeset/67660 280352 9 eric 2010-09-16 14:13:59 -0700 Filed bug 45918. 280482 10 eric 2010-09-16 18:01:27 -0700 I reordered the two calls in this function in an earlier change. I bet that caused this. I'm not sure using a protect ptr is right here. 280985 11 eric 2010-09-17 16:45:13 -0700 *** Bug 45804 has been marked as a duplicate of this bug. *** 280990 12 eric 2010-09-17 16:51:43 -0700 I dont' think it's right to add a Protect ptr w/o a comment as to what it's protecting against. In this case, it's not clear from reading the code why it's needed. Clearly my re-ordering of those calls in bug 45365 caused this bug. However before I reordered them the frame counts were off during frameDetached. (WebCore::HTMLFrameOwnerElement::willRemove): - Disconnecting the owner element removes the frame from the frame tree. frameDetached() calls Page::frameCount which expects that the frame is already gone at this point and asserts when it's not. It's unclear how this worked before, except that the frame removal was likely done in the post-attach callback, so the frameCount was wrong (too high) during frameDetached(), but was fixed up in the post-detach callback. Maybe my re-ordering was wrong. 282167 13 podivilov 2010-09-21 03:11:45 -0700 [Chromium] fast/frames/frame-limit.html is slow on debug bots 282405 14 inferno 2010-09-21 10:30:25 -0700 Pavel, can you please take a look into this. This is a high severity security bug that we dont want to make into v7 (and this is also a regression). 283188 15 inferno 2010-09-22 13:09:42 -0700 I had a chat with Pavel on this. He dont understand this code path and his attempt was a patch to fix the failure on the bots. It did fix things on the bots and also crash didn't reproduce with my testcase. But someone who understands this code, needs to be check if that is ok and functionally the right thing to do. Eric, i dont know how to process with regards to this. Any advise on the owner for this. Or do you think it is ok to merge this fix for the chromium v7 release. 568905 16 adamk 2012-03-01 14:19:14 -0800 Updated as always timing out on debug builds in http://trac.webkit.org/changeset/109420 739050 17 jchaffraix 2012-10-10 10:06:49 -0700 *** Bug 98919 has been marked as a duplicate of this bug. *** 872281 18 schenney 2013-04-09 16:27:56 -0700 Marking test failures as WontFix. Bug is still accessible and recording in TestExpectations. 67789 2010-09-16 06:28:54 -0700 2010-09-16 13:18:44 -0700 Proposed patch. patch text/plain 1221 podivilov ZGlmZiAtLWdpdCBhL1dlYkNvcmUvQ2hhbmdlTG9nIGIvV2ViQ29yZS9DaGFuZ2VMb2cKaW5kZXgg ZDJiNGYwYi4uZjFiOGNlNiAxMDA2NDQKLS0tIGEvV2ViQ29yZS9DaGFuZ2VMb2cKKysrIGIvV2Vi Q29yZS9DaGFuZ2VMb2cKQEAgLTEsMyArMSwxNSBAQAorMjAxMC0wOS0xNiAgUGF2ZWwgUG9kaXZp bG92ICA8cG9kaXZpbG92QGNocm9taXVtLm9yZz4KKworICAgICAgICBSZXZpZXdlZCBieSBOT0JP RFkgKE9PUFMhKS4KKworICAgICAgICBGaXggZGVidWcgY3Jhc2ggaW4gSFRNTEZyYW1lT3duZXJF bGVtZW50IGNhdXNlZCBieSBjb250ZW50IGZyYW1lIGJlaW5nIHVzZWQgYWZ0ZXIgZGVzdHJ1Y3Rp b24uCisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD00NTcz NworCisgICAgICAgIFRlc3Q6IGZhc3QvZnJhbWVzL2ZyYW1lLWxpbWl0Lmh0bWwKKworICAgICAg ICAqIGh0bWwvSFRNTEZyYW1lT3duZXJFbGVtZW50LmNwcDoKKyAgICAgICAgKFdlYkNvcmU6OkhU TUxGcmFtZU93bmVyRWxlbWVudDo6d2lsbFJlbW92ZSk6CisKIDIwMTAtMDktMTUgIFNpbW9uIEZy YXNlciAgPHNpbW9uLmZyYXNlckBhcHBsZS5jb20+CiAKICAgICAgICAgRml4IGNocm9taXVtIGJ1 aWxkLgpkaWZmIC0tZ2l0IGEvV2ViQ29yZS9odG1sL0hUTUxGcmFtZU93bmVyRWxlbWVudC5jcHAg Yi9XZWJDb3JlL2h0bWwvSFRNTEZyYW1lT3duZXJFbGVtZW50LmNwcAppbmRleCBiNDA5YmNjLi4y YTdiNjEwIDEwMDY0NAotLS0gYS9XZWJDb3JlL2h0bWwvSFRNTEZyYW1lT3duZXJFbGVtZW50LmNw cAorKysgYi9XZWJDb3JlL2h0bWwvSFRNTEZyYW1lT3duZXJFbGVtZW50LmNwcApAQCAtNTQsNiAr NTQsNyBAQCB2b2lkIEhUTUxGcmFtZU93bmVyRWxlbWVudDo6d2lsbFJlbW92ZSgpCiAgICAgLy8g RklYTUU6IEl0IGlzIHVuY2xlYXIgd2h5IHRoaXMgY2FuJ3QgYmUgbW92ZWQgdG8gcmVtb3ZlZEZy b21Eb2N1bWVudCgpCiAgICAgLy8gdGhpcyBpcyB0aGUgb25seSBpbXBsZW1lbnRhdGlvbiBvZiB3 aWxsUmVtb3ZlIGluIFdlYkNvcmUhCiAgICAgaWYgKEZyYW1lKiBmcmFtZSA9IGNvbnRlbnRGcmFt ZSgpKSB7CisgICAgICAgIFJlZlB0cjxGcmFtZT4gcHJvdGVjdChmcmFtZSk7CiAgICAgICAgIGZy YW1lLT5sb2FkZXIoKS0+ZnJhbWVEZXRhY2hlZCgpOwogICAgICAgICBmcmFtZS0+ZGlzY29ubmVj dE93bmVyRWxlbWVudCgpOwogICAgIH0K