mirror of
https://github.com/hrydgard/ppsspp.git
synced 2026-10-01 14:58:14 +00:00
Henrik Rydgård
60919a2ba9
The worker reads a queued CURL* out of a pipe eight bytes at a time, tracking how much it has so far - but it always read into the start of the buffer rather than at that offset. A short read would have resumed mid-pointer and eventually handed curl_multi_add_handle a spliced pointer. It never bit because a write that size to a pipe is atomic, so reads are all-or-nothing, but the code is written as though it isn't. The write that queues the request was unchecked. If it ever failed, the request was never run and never completed, and the caller sits in naettComplete forever. It reports the failure now, and retries on EINTR. curl wants an easy handle out of its multi before cleanup; that needs curl_multi_remove_handle, which meant adding it - and curl_multi_cleanup, for the init failure paths that leaked the multi handle and the pipe - to the dlopen table. workerRunning is written by the worker and read by the request path, so it's an atomic rather than a plain int. And the read/write callbacks passed the body callbacks' int return straight back to curl, which takes a size_t: a negative came through as an enormous count rather than the error it was.