[Webkit-unassigned] [Bug 191650] [Curl] Bug fix on Curl Request Scheduler.

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=191650

--- Comment #6 from Takashi Komori <Takashi.Komori at sony.com> ---
(In reply to Fujii Hironori from comment #3)
> (In reply to Takashi Komori from comment #1)
> > 3)CurlRequestScheduler does finalize task for request A using pointer P.
> > 4)When request B is closed, CurlRequestScheduler does finalize task using
> > same pointer P and issue occurs.
> 
> How can this happen? IUUC, the sequence looks:
> 
> 3) CurlRequestScheduler::finalizeTransfer post a task with the handle P
> 4) worker thread finilizes the handle P
> 5) CurlRequest::finalizeTransfer release the handle P by curl_easy_cleanup

Correctly is as follows

1) First CurlRequest(request1) is canceled. request1 has handle CURL* P.
2) cancelTransfer task for request1 is added to task queue. (TASK1)
3) Second CurlRequest(request2) is created and startTransfer task is added. (TASK2)
4) didReceiveHeader or didReceiveData callback function is invoked for request1.
5) request1 was canceled (m_cancelled is true), CurlRequest::didReceiveData/CurlRequest::didReceiveHeader return 0.
6) libcurl treats returned 0 as an error.
7) Worker thread gets CURL_WRITE_ERROR from curl_multi_info_read, and add completeTransfer task for handle P (TASK3)
8) (TASK1) is executed, handle P is released.
9) (TASK2) is executed, new handle is created P' for request2 but the address of P' is same as P released just before. P'==P
10) (TASK3) is executed, handle P is released.
11) Because P'==P request2's CURL handle is released before use.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20190416/1d952b5a/attachment.html>