summaryrefslogtreecommitdiff
path: root/contrib/gitview
diff options
context:
space:
mode:
authorLibravatar Jeff King <peff@peff.net>2012-10-12 02:22:49 -0400
committerLibravatar Junio C Hamano <gitster@pobox.com>2012-10-12 09:42:31 -0700
commit188923f0d1c8148415b3173986cd1e21871c947e (patch)
treef62cb81f35c64e98c71caa596a0cd0eebccb8f2d /contrib/gitview
parenthttp: prompt for credentials on failed POST (diff)
downloadtgif-188923f0d1c8148415b3173986cd1e21871c947e.tar.xz
http: fix segfault in handle_curl_result
When we create an http active_request_slot, we can set its "results" pointer back to local storage. The http code will fill in the details of how the request went, and we can access those details even after the slot has been cleaned up. Commit 8809703 (http: factor out http error code handling) switched us from accessing our local results struct directly to accessing it via the "results" pointer of the slot. That means we're accessing the slot after it has been marked as finished, defeating the whole purpose of keeping the results storage separate. Most of the time this doesn't matter, as finishing the slot does not actually clean up the pointer. However, when using curl's multi interface with the dumb-http revision walker, we might actually start a new request before handing control back to the original caller. In that case, we may reuse the slot, zeroing its results pointer, and leading the original caller to segfault while looking for its results inside the slot. Instead, we need to pass a pointer to our local results storage to the handle_curl_result function, rather than relying on the pointer in the slot struct. This matches what the original code did before the refactoring (which did not use a separate function, and therefore just accessed the results struct directly). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'contrib/gitview')
0 files changed, 0 insertions, 0 deletions