Bug 122130

Summary: WebProcess freezes after fast/forms/form-associated-element-crash3.html test
Product: WebKit Reporter: Tim Horton <thorton>
Component: MediaAssignee: Nobody <webkit-unassigned>
Status: RESOLVED WORKSFORME    
Severity: Normal CC: ap, dfarler, dino, eric.carlson, jer.noble, jonlee, lforschler, matthew_hanson, rniwa, roger_fong
Priority: P1 Keywords: InRadar
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   

Description Tim Horton 2013-09-30 15:24:27 PDT
run-webkit-tests -2 --no-retry-failures -v fast/forms/form-associated-element-crash3.html

results in:

> [1/1] fast/forms/form-associated-element-crash3.html passed
> stopping WebKitTestRunner(pid 80889) timed out, killing it

I don’t expect to see the second line about killing WKTR.

Also, when I run all of fast/forms (with 6 child processes against r156559; don’t know if sharding matters), I see:

> Last character read from DRT stdout line was not a newline!

just after this test runs.
Comment 1 Alexey Proskuryakov 2013-10-07 13:18:00 PDT
Started to look into this. WKTR actually fails to quit for some reason, even with a longer delay.
Comment 2 Alexey Proskuryakov 2013-10-07 16:28:32 PDT
Tools work correctly, WebProcess actually hangs when cleaning up between tests. This happens deep inside MediaToolbox when we call CFRelease on an AVURLAsset.

Reproducible freeze -> P1.
Comment 3 Alexey Proskuryakov 2013-10-07 16:31:31 PDT
<rdar://problem/15171108>
Comment 4 Alexey Proskuryakov 2013-10-07 17:43:43 PDT
I guess this is configuration dependent, and may not freeze everywhere.
Comment 5 Alexey Proskuryakov 2014-04-05 01:22:12 PDT
This bug was below WebKit, and it got fixed in OS X 10.9.2.

Removed expectations for this and related tests in <http://trac.webkit.org/r166829>. Let's see how well this works, especially on Mountain Lion.
Comment 6 Alexey Proskuryakov 2014-04-05 01:22:43 PDT
*** Bug 124593 has been marked as a duplicate of this bug. ***