AU: HttpFetcher: Fix segfault with multi fetcher and small transfers
When a proxy resolver resolves proxies, it calls into HttpFetcher w/
the results, which then kicks off a transfer (by executing a member
variable callback of HttpFetcher). After HttpFetcher calls that
callback, it sets the callback to NULL.
When using MultiHttpFetcher, the same HttpFetcher is used multiple
times. If we have a very small transfer, what can happen is this.
Time goes down, callstack grows to the right:
First transfer proxies resolved
++ HttpFetcher called, calls a callback
+++ Transfer begins
++++ Transfer ends
+++++ MultiFetcher told transfer ends
++++++ MultiFetcher starts new transfer
+++++++ HttpFetcher installs a new callback member var
++ HttpFetcher zeros out callback member var
Second transfer proxies resolved
++ HttpFetcher member var is NULL - CRASH
To fix this issue, HttpFetcher makes a local copy of the callback
pointer, then sets the member variable to NULL, then calls the
callback.
(On a side note, it is CLs and bugs like these that make me wonder if
maybe we should have used Chrome's threading model rather than going
single threaded and async.)
Also, fix a comment in MultiHttpFetcher
Change-Id: Ib87c1e75211bc56cecea7f7298576371184d586c
BUG=chromium-os:13388
TEST=unittests
Review URL: http://codereview.chromium.org/6693047
diff --git a/multi_range_http_fetcher.cc b/multi_range_http_fetcher.cc
index 16d2c09..8b3d8d7 100644
--- a/multi_range_http_fetcher.cc
+++ b/multi_range_http_fetcher.cc
@@ -123,7 +123,7 @@
successful = true;
}
- // If we have another fetcher, use that.
+ // If we have another transfer, do that.
if (current_index_ + 1 < ranges_.size()) {
current_index_++;
LOG(INFO) << "Starting next transfer (" << current_index_ << ").";