Badly-written Android app can ArcContentFileSystemFileStreamReader forever |
||
Issue descriptionArcContentFileSystemFileStreamReader waits to read the provided FD, and the FD can be a read end of a pipe whose write end is owned by an Android app. Android app may fail to provide enough pipe contents, and it can result in Chrome waiting for data forever.
,
Dec 12 2016
Any other types of third-party code can own the write end of a pipe?
,
Dec 12 2016
As per storage::FileStreamReader's contract, blocking read() forever is okay as long as it can be canceled by deleting the object. That said, ArcContentFileSystemFileStreamReader delegates I/O impl to net::FileStream, and it actually says "The file must be opened with FLAG_ASYNC", which we seem not ensuring at this moment. https://cs.chromium.org/chromium/src/net/base/file_stream.h?cl=GROK&gsn=FileStream&l=78
,
Dec 12 2016
Talk with hashimoto@ offline. The point is that a thread in the blocking pool is blocked by read(2). Also he pointed me to https://codereview.chromium.org/2551913004/ where he is moving away from net::FileStream.
,
Aug 31
is there more work to do here? This issue is old and the linked CL landed long ago
,
Sep 3
We can use FileDescriptorWatcher to avoid blocking worker threads. Though it's P3 and no work has been done yet. |
||
►
Sign in to add a comment |
||
Comment 1 by nya@chromium.org
, Dec 12 2016