Bug 187790

Summary: FetchResponse should close its stream when loading finishes
Product: WebKit Reporter: youenn fablet <youennf>
Component: Service WorkersAssignee: youenn fablet <youennf>
Status: RESOLVED FIXED    
Severity: Normal CC: achristensen, cdumez, commit-queue, ddkilzer, realdawei, ryanhaddad, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch
none
Patch
none
Patch
none
Patch for landing
none
Fixing ASSERTs none

Description youenn fablet 2018-07-18 15:50:41 PDT
Currently it is not doing so until pulling happens.
Comment 1 youenn fablet 2018-07-18 15:54:39 PDT
Created attachment 345299 [details]
Patch
Comment 2 youenn fablet 2018-07-19 07:32:26 PDT
<rdar://problem/42311832>
Comment 3 Chris Dumez 2018-07-19 08:50:16 PDT
Comment on attachment 345299 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=345299&action=review

> Source/WebCore/Modules/fetch/FetchBodyOwner.cpp:50
> +    if (m_readableStreamSource)

m_readableStreamSource gets nulled out in several methods in this class, in which case, the source may be kept alive (due to refcounting) but will still have a pointer to this owner. I think we want to clear the source's body owner in all cases where m_readableStreamSource gets cleared, not used in the BodyOwner destructor.

> Source/WebCore/Modules/fetch/FetchBodySource.cpp:89
> +void FetchBodySource::cleanBodyOwner()

I do not like "clean", I'd prefer "clear" or "detachFrom"
Comment 4 Chris Dumez 2018-07-19 08:58:23 PDT
Comment on attachment 345299 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=345299&action=review

>> Source/WebCore/Modules/fetch/FetchBodyOwner.cpp:50
>> +    if (m_readableStreamSource)
> 
> m_readableStreamSource gets nulled out in several methods in this class, in which case, the source may be kept alive (due to refcounting) but will still have a pointer to this owner. I think we want to clear the source's body owner in all cases where m_readableStreamSource gets cleared, not used in the BodyOwner destructor.

not *just* in the BodyOwner destructor.
Comment 5 youenn fablet 2018-07-19 09:17:24 PDT
> m_readableStreamSource gets nulled out in several methods in this class, in
> which case, the source may be kept alive (due to refcounting) but will still
> have a pointer to this owner. I think we want to clear the source's body
> owner in all cases where m_readableStreamSource gets cleared, not used in
> the BodyOwner destructor.

I do not think this is actually needed and we will probably want to either ASSERT or do the same thing in BodyOwner destructor.
I agree though that we could ensure that the source is in a closed/errored state whenever FetchBodyOwner nullify its source. Doing all of this at about the same place in code might be more future proof.
I'll update the patch accordingly.

> > Source/WebCore/Modules/fetch/FetchBodySource.cpp:89
> > +void FetchBodySource::cleanBodyOwner()
> 
> I do not like "clean", I'd prefer "clear" or "detachFrom"

OK
Comment 6 youenn fablet 2018-07-19 10:00:00 PDT
Created attachment 345353 [details]
Patch
Comment 7 youenn fablet 2018-07-19 10:01:40 PDT
Created attachment 345354 [details]
Patch
Comment 8 Chris Dumez 2018-07-19 10:04:10 PDT
Comment on attachment 345353 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=345353&action=review

> Source/WebCore/Modules/fetch/FetchResponse.cpp:259
> +            m_response.m_readableStreamSource->error(makeString("Loading failed"_s, error.localizedDescription()));

Don't we need a ": " between "Loading failed" and the description?
Comment 9 youenn fablet 2018-07-19 10:06:23 PDT
Created attachment 345355 [details]
Patch for landing
Comment 10 WebKit Commit Bot 2018-07-19 11:33:00 PDT
Comment on attachment 345355 [details]
Patch for landing

Clearing flags on attachment: 345355

Committed r233994: <https://trac.webkit.org/changeset/233994>
Comment 11 WebKit Commit Bot 2018-07-19 11:33:01 PDT
All reviewed patches have been landed.  Closing bug.
Comment 12 Ryan Haddad 2018-07-19 13:02:32 PDT
mac-wk1 debug EWS bots are failing one of the assertions added in this change:

Thread 29 Crashed:: WebCore: Worker
0   com.apple.JavaScriptCore            0x0000000107d20ff0 WTFCrash + 16 (Assertions.cpp:267)
1   com.apple.WebCore                   0x000000011491d157 WebCore::FetchBodySource::setInactive() + 71 (FetchBodySource.cpp:50)
2   com.apple.WebCore                   0x00000001142c230e WebCore::ReadableStreamSource::clean() + 78 (ReadableStreamSource.h:117)
3   com.apple.WebCore                   0x0000000114918c4b WebCore::FetchBodySource::close() + 59 (FetchBodySource.cpp:85)
4   com.apple.WebCore                   0x0000000114918354 WebCore::FetchBody::consumeAsStream(WebCore::FetchBodyOwner&, WebCore::FetchBodySource&) + 1300 (FetchBody.cpp:197)
5   com.apple.WebCore                   0x000000011491ce84 WebCore::FetchBodyOwner::consumeBodyAsStream() + 340 (FetchBodyOwner.cpp:328)
6   com.apple.WebCore                   0x00000001149343f9 WebCore::FetchResponse::consumeBodyAsStream() + 121 (FetchResponse.cpp:422)
7   com.apple.WebCore                   0x000000011491d1fc WebCore::FetchBodySource::doStart() + 108 (FetchBodySource.cpp:60)

https://webkit-queues.webkit.org/results/8589680
Comment 14 Dawei Fenton (:realdawei) 2018-07-19 13:51:54 PDT
Reverted r233994 for reason:

Caused EWS and bot failures due to assertions added

Committed r234003: <https://trac.webkit.org/changeset/234003>
Comment 15 youenn fablet 2018-07-19 14:17:12 PDT
Thanks David!
Comment 16 Chris Dumez 2018-07-19 14:36:14 PDT
Comment on attachment 345355 [details]
Patch for landing

View in context: https://bugs.webkit.org/attachment.cgi?id=345355&action=review

> Source/WebCore/Modules/fetch/FetchBodySource.cpp:82
> +    m_bodyOwner = nullptr;

Maybe we should clear this at the *end* of the method?

> Source/WebCore/Modules/fetch/FetchBodySource.cpp:89
> +    m_bodyOwner = nullptr;

ditto.
Comment 17 youenn fablet 2018-07-20 08:43:38 PDT
Created attachment 345446 [details]
Fixing ASSERTs
Comment 18 Chris Dumez 2018-07-20 08:52:33 PDT
Comment on attachment 345446 [details]
Fixing ASSERTs

LGTM, no crashes here in stress gc or debug.
Comment 19 youenn fablet 2018-07-20 08:53:10 PDT
Did two changes to fix ASSERTS:
- clear m_bodyOwner at the end of the method
- handle the specific case of cancelling a stream that is closing but not closed. In that case, even though controller.close() is called, the stream is not called until all chunks are read. Cancel can be used in between. I added a m_isClosed debug boolean to ensure this.
Comment 20 youenn fablet 2018-07-20 08:53:36 PDT
s/end of the method/end of the methods/
Comment 21 WebKit Commit Bot 2018-07-20 09:59:00 PDT
Comment on attachment 345446 [details]
Fixing ASSERTs

Clearing flags on attachment: 345446

Committed r234045: <https://trac.webkit.org/changeset/234045>
Comment 22 WebKit Commit Bot 2018-07-20 09:59:02 PDT
All reviewed patches have been landed.  Closing bug.
Comment 23 David Kilzer (:ddkilzer) 2018-07-21 09:05:10 PDT
Comment on attachment 345446 [details]
Fixing ASSERTs

View in context: https://bugs.webkit.org/attachment.cgi?id=345446&action=review

> Source/WebCore/Modules/fetch/FetchBodySource.cpp:82
> +#ifndef NDEBUG

This should be:

#if !ASSERT_DISABLED

Because it is possible to compile a Release build with all asserts enabled.

> Source/WebCore/Modules/fetch/FetchBodySource.h:63
> +#ifndef NDEBUG

This should be:

#if !ASSERT_DISABLED

Because it is possible to compile a Release build with all asserts enabled.