Bug 48795

Summary: [Chromium] REGRESSION(r70552): DumpRenderTree never exits.
Product: WebKit Reporter: Dimitri Glazkov (Google) <dglazkov>
Component: WebKit APIAssignee: Nobody <webkit-unassigned>
Status: RESOLVED WONTFIX    
Severity: Normal CC: dpranke, hclam, kbr, scherkus, senorblanco, tkent, vrk
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: PC   
OS: OS X 10.5   

Description Dimitri Glazkov (Google) 2010-11-01 16:02:39 PDT
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.
Comment 1 Kent Tamura 2010-11-02 01:30:00 PDT
I couldn't reproduce this issue on my Windows 7 machine.
Comment 2 Dimitri Glazkov (Google) 2010-11-02 06:56:59 PDT
(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.
Comment 3 Dimitri Glazkov (Google) 2010-11-02 09:30:55 PDT
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.
Comment 4 Dimitri Glazkov (Google) 2010-11-02 10:40:08 PDT
I narrowed it down to http://src.chromium.org/viewvc/chrome?view=rev&revision=63548.
Comment 5 Dimitri Glazkov (Google) 2010-11-02 10:50:24 PDT
(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.
Comment 6 Dimitri Glazkov (Google) 2010-11-02 15:59:56 PDT
How's it going? Any updates?
Comment 7 Victoria Kirst 2010-11-02 19:33:25 PDT
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?
Comment 8 Dimitri Glazkov (Google) 2010-11-02 19:53:08 PDT
(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
Comment 9 Victoria Kirst 2010-11-02 21:36:17 PDT
> 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.
Comment 10 Dirk Pranke 2010-11-02 22:25:26 PDT
(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.
Comment 11 Hin-Chung Lam 2010-11-03 00:40:16 PDT
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.
Comment 12 Hin-Chung Lam 2010-11-04 11:51:52 PDT
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.. :( :(
Comment 13 Dimitri Glazkov (Google) 2010-11-04 11:54:52 PDT
(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!
Comment 14 Andrew Scherkus 2010-11-04 12:19:19 PDT
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!)
Comment 15 Hin-Chung Lam 2010-11-04 14:15:53 PDT
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.
Comment 16 Dimitri Glazkov (Google) 2011-05-05 09:09:27 PDT
Is this fixed now?
Comment 17 Stephen Chenney 2013-04-09 16:10:27 PDT
LayoutTest failures for Chromium are being marked WontFix. The Bug is still accessible and referenced from TestExpectations.