Bug 152436 – imported/w3c/web-platform-tests/streams-api/readable-streams/garbage-collection.html asserts frequently

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKit Misc.

[Alexey Proskuryakov]

imported/w3c/web-platform-tests/streams-api/readable-streams/garbage-collection.html frequently crashes on debug WebKit1 bots: https://build.webkit.org/results/Apple%20Yosemite%20Debug%20WK1%20(Tests)/r194278%20(9621)/imported/w3c/web-platform-tests/streams-api/readable-streams/garbage-collection-crash-log.txt

<rdar://23926702>

Thread 35 Crashed:: WebCore: Worker
0   com.apple.JavaScriptCore      	0x000000010f6008f7 WTFCrash + 39
1   com.apple.WebCore             	0x0000000114f7a68f WebCore::JSGlobalObjectCallback::call() + 351 (JSDOMGlobalObjectTask.cpp:67)
2   com.apple.WebCore             	0x0000000114f79f91 WebCore::JSGlobalObjectTask::JSGlobalObjectTask(WebCore::JSDOMGlobalObject*, WTF::PassRefPtr<JSC::Microtask>)::$_0::operator()(WebCore::ScriptExecutionContext&) const + 33 (JSDOMGlobalObjectTask.cpp:88)
3   com.apple.WebCore             	0x0000000114f79f5c std::__1::__function::__func<WebCore::JSGlobalObjectTask::JSGlobalObjectTask(WebCore::JSDOMGlobalObject*, WTF::PassRefPtr<JSC::Microtask>)::$_0, std::__1::allocator<WebCore::JSGlobalObjectTask::JSGlobalObjectTask(WebCore::JSDOMGlobalObject*, WTF::PassRefPtr<JSC::Microtask>)::$_0>, void (WebCore::ScriptExecutionContext&)>::operator()(WebCore::ScriptExecutionContext&) + 92 (functional:1370)
4   com.apple.WebCore             	0x0000000114570f8b std::__1::function<void (WebCore::ScriptExecutionContext&)>::operator()(WebCore::ScriptExecutionContext&) const + 59 (functional:1756)
5   com.apple.WebCore             	0x000000011453681d WebCore::ScriptExecutionContext::Task::performTask(WebCore::ScriptExecutionContext&) + 29 (ScriptExecutionContext.h:151)
6   com.apple.WebCore             	0x00000001163e8569 WebCore::WorkerRunLoop::Task::performTask(WebCore::WorkerRunLoop const&, WebCore::WorkerGlobalScope*) + 105 (WorkerRunLoop.cpp:224)
7   com.apple.WebCore             	0x00000001163e8015 WebCore::WorkerRunLoop::runInMode(WebCore::WorkerGlobalScope*, WebCore::ModePredicate const&, WebCore::WorkerRunLoop::WaitMode) + 1029 (WorkerRunLoop.cpp:171)
8   com.apple.WebCore             	0x00000001163e7bd6 WebCore::WorkerRunLoop::run(WebCore::WorkerGlobalScope*) + 86 (WorkerRunLoop.cpp:127)
9   com.apple.WebCore             	0x00000001163efec5 WebCore::WorkerThread::runEventLoop() + 53 (WorkerThread.cpp:176)
10  com.apple.WebCore             	0x00000001144c4259 WebCore::DedicatedWorkerThread::runEventLoop() + 89 (DedicatedWorkerThread.cpp:66)

This started on December 14th, but it's not frequent enough to pinpoint the exact culprit. It seems to happen a lot more on EWS, significantly affecting its performance.

Could you please take a look soon?

[youenn fablet]

The crash may come from enabling ReadableStream in worker mode. We also have some problems in GTK when running promise-based code in worker (see bug 152340).

If this degrades the EWS bots performances seriously, the best temp fix might be to edit imported/w3c/web-platform-tests/streams-api/readable-streams/garbage-collection.html to disable running the tests in a worker but still running the tests in window.

Like for bug 152340, a first good step would be to simplify this test and make it always crashing. It might be that the issue lies in promise/task handling code.

[Alexey Proskuryakov]

> the best temp fix might be to edit imported/w3c/web-platform-tests/streams-api/readable-streams/garbage-collection.html to disable running the tests

Would you be willing to do this?

[youenn fablet]

Created attachment 267710 [details]
Patch

[youenn fablet]

(In reply to comment #3)
> Created attachment 267710 [details]
> Patch

Patch only disables the test in worker mode.

[youenn fablet]

(In reply to comment #4)
> (In reply to comment #3)
> > Created attachment 267710 [details]
> > Patch
> 
> Patch only disables the test in worker mode.

It seems I was wrong.
Another possibility may be due to garbage collection.
Let's rollout http://trac.webkit.org/changeset/194033 then.

[youenn fablet]

https://trac.webkit.org/r194319 should fix the crashes

[Build Bot]

Comment on attachment 267710 [details]
Patch

Attachment 267710 [details] did not pass mac-debug-ews (mac):
Output: http://webkit-queues.webkit.org/results/583666

New failing tests:
imported/w3c/web-platform-tests/streams-api/readable-streams/garbage-collection.html

[Build Bot]

Created attachment 267713 [details]
Archive of layout-test-results from ews115 for mac-yosemite

The attached test failures were seen while running run-webkit-tests on the mac-debug-ews.
Bot: ews115  Port: mac-yosemite  Platform: Mac OS X 10.10.5

[Alexey Proskuryakov]

This test is still causing trouble, see bug 137759 comment 39. Youenn, can you take a look?

[youenn fablet]

(In reply to comment #9)
> This test is still causing trouble, see bug 137759 comment 39. Youenn, can
> you take a look?

I tried running the streams-api tests on my mac setup (repeat 10, iterations 10) but was not able to reproduce any crash in debug WK1/debug WK2 :(

It is unclear whether the issue is related to Worker or not since it is running the tests in window and worker modes.

One approach may be to add a Crashing expectation for that test and add two new test files to run the tests in worker mode and window independently.

[youenn fablet]

Created attachment 269779 [details]
Splitting flaky test

[WebKit Commit Bot]

Comment on attachment 269779 [details]
Splitting flaky test

Clearing flags on attachment: 269779

Committed r195583: <http://trac.webkit.org/changeset/195583>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Ryan Haddad]

The test imported/w3c/web-platform-tests/streams-api/readable-streams/garbage-collection-1.html seems to be crashing frequently too:

<https://webkit-test-results.webkit.org/dashboards/flakiness_dashboard.html#tests=imported%2Fw3c%2Fweb-platform-tests%2Fstreams-api%2Freadable-streams%2Fgarbage-collection-1.html>

[youenn fablet]

Reopening to attach new patch.

[youenn fablet]

Created attachment 270191 [details]
Making garbage-collection-2.html run two tests in window env

[youenn fablet]

(In reply to comment #14)
> The test
> imported/w3c/web-platform-tests/streams-api/readable-streams/garbage-
> collection-1.html seems to be crashing frequently too:
> 
> <https://webkit-test-results.webkit.org/dashboards/flakiness_dashboard.
> html#tests=imported%2Fw3c%2Fweb-platform-tests%2Fstreams-api%2Freadable-
> streams%2Fgarbage-collection-1.html>

Yes, this is a way to try reducing the crashing test complexity.
garbage-collection-2.html is not crashing since GCCollect is not available in Worker environments.
I modified garbage-collection-2.html to run half of garbage-collection-1.html tests in window environment.

If that is a burden for others, I can rename these test files to make it clear that these are temp test files that are ok to crash.

[WebKit Commit Bot]

Comment on attachment 270191 [details]
Making garbage-collection-2.html run two tests in window env

Clearing flags on attachment: 270191

Committed r195924: <http://trac.webkit.org/changeset/195924>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[youenn fablet]

I spent some time checking the issue.
It seems related to promises and running them in workers, in particular when chaining several of them, something like:
promise.then(function() {
...
return promise1;
}).then(function() {
...
return promise2;
}).then(function() {
...
return promise3;
}).then(function() {
...
return promise4;
})
...

I will try to flesh out a test for it.