48795 2010-11-01 16:02:39 -0700 [Chromium] REGRESSION(r70552): DumpRenderTree never exits. 2013-04-09 16:10:27 -0700 1 1 1 Unclassified WebKit WebKit API 528+ (Nightly build) PC OS X 10.5 RESOLVED WONTFIX P2 Normal --- 1 dglazkov webkit-unassigned dpranke hclam kbr scherkus senorblanco tkent vrk oldest_to_newest 303017 0 dglazkov 2010-11-01 16:02:39 -0700 It seems there was some regression somewhere that made DumpRenderTree process never exit. It just hangs there. In non-Windows, server_process.py actually kills DRT after a timeout, but on Windows we become screwed. As of right now, the Chromium Win Release (Tests) builder has to be manually aided (taskkill) after each cycle. I have no idea when it began. Looking at the waterfall, potential offender is http://trac.webkit.org/changeset/70552/. I am trying to revert locally and see what happens. 303263 1 tkent 2010-11-02 01:30:00 -0700 I couldn't reproduce this issue on my Windows 7 machine. 303340 2 dglazkov 2010-11-02 06:56:59 -0700 (In reply to comment #1) > I couldn't reproduce this issue on my Windows 7 machine. Odd. I can reproduce it consistently. The tests finish, but three or so DumpRenderTree.exe processes remain. 303407 3 dglazkov 2010-11-02 09:30:55 -0700 I've confirmed that rolling out http://trac.webkit.org/changeset/70552/ fixes the issue. The trouble is, I am pretty sure it's the DEPS roll that caused it, not the actual change. 303462 4 dglazkov 2010-11-02 10:40:08 -0700 I narrowed it down to http://src.chromium.org/viewvc/chrome?view=rev&revision=63548. 303473 5 dglazkov 2010-11-02 10:50:24 -0700 (In reply to comment #4) > I narrowed it down to http://src.chromium.org/viewvc/chrome?view=rev&revision=63548. I suspect this problem also exists in test_shell, but because we kill test_shell by force when it's no longer necessary, the problem is not clearly visible. 303748 6 dglazkov 2010-11-02 15:59:56 -0700 How's it going? Any updates? 303862 7 vrk 2010-11-02 19:33:25 -0700 Hmm, I can't reproduce the issue on my Windows 7 machine, either. I am running "python new-run-webkit-tests --chromium --use-drt --platform chromium-win-vista media" and the test can complete fine and I don't have any stranded DumpRenderTree.exe instances afterward. Am I doing something wrong? Also, do you have an idea of what tests are causing DRT to hang? 303867 8 dglazkov 2010-11-02 19:53:08 -0700 (In reply to comment #7) > Hmm, I can't reproduce the issue on my Windows 7 machine, either. I am running "python new-run-webkit-tests --chromium --use-drt --platform chromium-win-vista media" and the test can complete fine and I don't have any stranded DumpRenderTree.exe instances afterward. Am I doing something wrong? Also, do you have an idea of what tests are causing DRT to hang? I ran the entire test set: new-run-webkit-tests --chromium --use-drt 303888 9 vrk 2010-11-02 21:36:17 -0700 > I ran the entire test set: new-run-webkit-tests --chromium --use-drt OK, that did it! Thanks! Here's what I've seen so far: It looks like the tests that fail are video-play-stall.html, video-play-stall-seek.html, and video-seekable-stall.html. But the bug is not 100% consistently reproduced (probably more like 75%?) and DumpRenderTree.exe occasionally exits cleanly, which explains why there are 2-3 processes orphaned at the end of running the entire test suite instead of an exact number. I'll try to run it with the Debug build tomorrow to get a stack trace and pinpoint exactly what's causing the problem. 303898 10 dpranke 2010-11-02 22:25:26 -0700 (In reply to comment #7) > Hmm, I can't reproduce the issue on my Windows 7 machine, either. I am running "python new-run-webkit-tests --chromium --use-drt --platform chromium-win-vista media" and the test can complete fine and I don't have any stranded DumpRenderTree.exe instances afterward. Am I doing something wrong? Also, do you have an idea of what tests are causing DRT to hang? This is a side note, but if you're on win 7, you should be using --platform chromium-win , not --platform chromium-win-vista . The win 7 baselines are in the regular "win" directory. Also, you don't need to specify both --chromium and --platform ; specifying just --chromium will cause the appropriate chromium windows version to be selected. Not that that should cause anything to hang, of course. 303910 11 hclam 2010-11-03 00:40:16 -0700 I traced down the code and fond the cause of the hang . vrk's change was supposed to fix a hang case, however it uncovered another hanging case (in fact two potentially) which causes DRT to hang. I'll bring up the discussion and will work on a fix tomorrow. 304782 12 hclam 2010-11-04 11:51:52 -0700 Landed a patch to skip those offending layout tests: http://trac.webkit.org/changeset/71349. Still working on the proper fix. Unfortunately this involves a bigger problem in the media code.. :( I'm working on an ad hoc fix to the code, but we'll need to fix this again properly.. :( :( 304783 13 dglazkov 2010-11-04 11:54:52 -0700 (In reply to comment #12) > Landed a patch to skip those offending layout tests: http://trac.webkit.org/changeset/71349. > > Still working on the proper fix. Unfortunately this involves a bigger problem in the media code.. :( I'm working on an ad hoc fix to the code, but we'll need to fix this again properly.. :( :( Thanks, Alpha! 304794 14 scherkus 2010-11-04 12:19:19 -0700 No ad-hoc fixes please! We have the time and bandwidth to do the proper fix. I'm fine leaving us with skipped tests for the time being (we can also discuss offline!) 304862 15 hclam 2010-11-04 14:15:53 -0700 OK, I'll wait until we have a discussion about what the fix should look like. It's likely someone else will be doing the proper fix. 398764 16 dglazkov 2011-05-05 09:09:27 -0700 Is this fixed now? 872198 17 schenney 2013-04-09 16:10:27 -0700 LayoutTest failures for Chromium are being marked WontFix. The Bug is still accessible and referenced from TestExpectations.