fix: proxy-upload semaphore_wait timeout#111
Conversation
One attempt to answer this is that a significant change in the GCD previously allowed the task to be completed (and updated refs) even though semaphore waiting led to exiting the surrounding function (and autorelease pool), whereas now it stops the task. It must have always been racy, but since it could complete the effect of essentially not waiting, it must have been negligible. I wrote this in May 2023, so I still tested it on macOS 13. We could run a proxy integration test on one of the macOS 13 GHA runner images. |
A more sensible explanation would be the timing until the process exits. If the However, if that exit path takes longer to execute, the task will continue to run in the background. Since the completion handler closes over the function's scope in the autorelease pool, nothing will be freed because only the local references of the surrounding function will be dropped, and the task still has live references via its completion handler. In that case, the upload could be finished successfully. If the timing is correct, the completion handler could even write |
While testing the
crashpad_handlerHTTP-proxy-based report upload on macOS without a registeredmitmproxycertificate, I saw that we don't get any error logs from thecrashpad_handlerand never get into the completion handler.This was a bug: I incorrectly specified the
dispatch_semaphore_wait()timeout. The timeout it accepts is not a relative offset but an absolute timeout! So, by passing a 10-second offset, the timeout expects 10 seconds after an arbitrary absolute start point (which almost assuredly already passed).I am still trying to understand why this wasn't an issue when testing the initial implementation, which I had to do so many times due to the finicky proxy config of
NSURLSession.