git-http-fetch segfault, curl 7.18.0

git-http-fetch segfault, curl 7.18.0

[Gerrit Pape]

Hi, as reported through http://bugs.debian.org/468836, I can reproduce
with current maint branch on Debian/unstable, but I don't know whether
it's a problem in curl, or in git.  Maybe anyone with some experience
in curl can help on this?

 $ make
 [...]
 $ mkdir repo && cd repo && git init
 Initialized empty Git repository in .git/
 $ ../git-http-fetch -v -a -w remotes/origin/master ef227a3da916f53f5a9ef4266c27c283c1ab607b http://git.debian.org/git/users/eddyp-guest/test-segfault.git/
 got ef227a3da916f53f5a9ef4266c27c283c1ab607b
 walk ef227a3da916f53f5a9ef4266c27c283c1ab607b
 got 12d086d13b3e69b26389282fe031b1a15153d84c
 Getting alternates list for
 http://git.debian.org/git/users/eddyp-guest/test-segfault.git
 Getting pack list for
 http://git.debian.org/git/users/eddyp-guest/test-segfault.git
 got e25c7e03ea0c0d4d9bea5552ee629a25196ff43f
 got a8d762c979ac21da092732eafb6ded8751c3f63d
 Getting index for pack 06eec8e3e8f770e471d5f3f19c3b8ffa9159fd97
 got 31cdb53945ddfa3b7bc15e12fdf900024eec1a56
 Getting pack 06eec8e3e8f770e471d5f3f19c3b8ffa9159fd97
  which contains 64580202061d4d8f449e09107ac6e60706142202
 walk 64580202061d4d8f449e09107ac6e60706142202
 error: Unable to find 30e8500073c101f656311906f5a00f0ccc0e8546 under http://git.debian.org/git/users/eddyp-guest/test-segfault.git
 Cannot obtain needed commit 30e8500073c101f656311906f5a00f0ccc0e8546
 while processing commit 64580202061d4d8f449e09107ac6e60706142202.
 $ echo $?
 255
 $ ../git-http-fetch -v -a -w remotes/origin/master ef227a3da916f53f5a9ef4266c27c283c1ab607b http://git.debian.org/git/users/eddyp-guest/test-segfault.git/
 walk ef227a3da916f53f5a9ef4266c27c283c1ab607b
 walk 64580202061d4d8f449e09107ac6e60706142202
 Getting alternates list for
 http://git.debian.org/git/users/eddyp-guest/test-segfault.git
 Getting pack list for
 http://git.debian.org/git/users/eddyp-guest/test-segfault.git
 error: Unable to find 30e8500073c101f656311906f5a00f0ccc0e8546 under
 http://git.debian.org/git/users/eddyp-guest/test-segfault.git
 Cannot obtain needed commit 30e8500073c101f656311906f5a00f0ccc0e8546
 while processing commit 64580202061d4d8f449e09107ac6e60706142202.
 Waiting for
 http://git.debian.org/git/users/eddyp-guest/test-segfault.git/objects/8b/d9d5f451cb08435cdcb773dc8cdddf9f61d553
 Waiting for
 http://git.debian.org/git/users/eddyp-guest/test-segfault.git/objects/ef/b3c1b344b887ffdb5d917eca2a28e5f176613c
 Segmentation fault

gdb gives this

 (gdb) r -v -a -w remotes/origin/master ef227a3da916f53f5a9ef4266c27c283c1ab607b http://git.debian.org/git/users/eddyp-guest/test-segfault.git/
 Starting program: /usr/local/src/Debian/GIT/git/git-http-fetch -v -a -w
 remotes/origin/master  ef227a3da916f53f5a9ef4266c27c283c1ab607b
 http://git.debian.org/git/users/eddyp-guest/test-segfault.git/
 [Thread debugging using libthread_db enabled]
 walk ef227a3da916f53f5a9ef4266c27c283c1ab607b
 [New Thread 0x3002c220 (LWP 19305)]
 walk 64580202061d4d8f449e09107ac6e60706142202
 Getting alternates list for http://git.debian.org/git/users/eddyp-guest/test-segfault.git
 Getting pack list for http://git.debian.org/git/users/eddyp-guest/test-segfault.git
 error: Unable to find 30e8500073c101f656311906f5a00f0ccc0e8546 under http://git.debian.org/git/users/eddyp-guest/test-segfault.git
 Cannot obtain needed commit 30e8500073c101f656311906f5a00f0ccc0e8546
 while processing commit 64580202061d4d8f449e09107ac6e60706142202.
 Waiting for http://git.debian.org/git/users/eddyp-guest/test-segfault.git/objects/8b/d9d5f451cb08435cdcb773dc8cdddf9f61d553
 Waiting for http://git.debian.org/git/users/eddyp-guest/test-segfault.git/objects/3a/36bcfe419fe97021a330516c25e8c8d6a61b23
 Waiting for http://git.debian.org/git/users/eddyp-guest/test-segfault.git/objects/f9/1f9480407a3786f0a66855af7c64da9360c214

 Program received signal SIGSEGV, Segmentation fault.
 [Switching to Thread 0x3002c220 (LWP 19305)]
 0x0ffbaddc in ?? () from /usr/lib/libcurl-gnutls.so.4
 (gdb) bt
 #0  0x0ffbaddc in ?? () from /usr/lib/libcurl-gnutls.so.4
 #1  0x0ffbadc4 in ?? () from /usr/lib/libcurl-gnutls.so.4
 #2  0x0ffc3f0c in curl_easy_cleanup () from /usr/lib/libcurl-gnutls.so.4
 #3  0x100a4e8c in fill_active_slots () at http.c:442
 #4  0x100a5100 in step_active_slots () at http.c:459
 #5  0x100a519c in run_active_slot (slot=0x10169f08) at http.c:479
 #6  0x100a5478 in http_cleanup () at http.c:296
 #7  0x100a6514 in cleanup (walker=<value optimized out>) at http-walker.c:900
 #8  0x100a2550 in walker_free (walker=<value optimized out>) at walker.c:315
 #9  0x1004df68 in cmd_http_fetch (argc=<value optimized out>, argv=0x7fbfe784, 
     prefix=<value optimized out>) at builtin-http-fetch.c:81
 #10 0x100045e8 in handle_internal_command (argc=7, argv=0x7fbfe784) at git.c:259
 #11 0x10004f88 in main (argc=7, argv=0x7fbfe784) at git.c:420
 (gdb) 

and sometimes

 (gdb) r -v -a -w remotes/origin/master ef227a3da916f53f5a9ef4266c27c283c1ab607b http://git.debian.org/git/users/eddyp-guest/test-segfault.git/
 Starting program: /usr/local/src/Debian/GIT/git/git-http-fetch -v -a -w remotes/origin/master  ef227a3da916f53f5a9ef4266c27c283c1ab607b http://git.debian.org/git/users/eddyp-guest/test-segfault.git/
 [Thread debugging using libthread_db enabled]
 walk ef227a3da916f53f5a9ef4266c27c283c1ab607b
 [New Thread 0x3002c220 (LWP 20097)]
 walk 64580202061d4d8f449e09107ac6e60706142202
 Getting alternates list for http://git.debian.org/git/users/eddyp-guest/test-segfault.git
 Getting pack list for http://git.debian.org/git/users/eddyp-guest/test-segfault.git
 error: Unable to find 30e8500073c101f656311906f5a00f0ccc0e8546 under http://git.debian.org/git/users/eddyp-guest/test-segfault.git
 Cannot obtain needed commit 30e8500073c101f656311906f5a00f0ccc0e8546
 while processing commit 64580202061d4d8f449e09107ac6e60706142202.
 Waiting for http://git.debian.org/git/users/eddyp-guest/test-segfault.git/objects/61/6e4145cf75c474bafa94f1dd917ed0a6f421fc
 Waiting for http://git.debian.org/git/users/eddyp-guest/test-segfault.git/objects/ef/b3c1b344b887ffdb5d917eca2a28e5f176613c

 Program received signal SIGSEGV, Segmentation fault.
 [Switching to Thread 0x3002c220 (LWP 20097)]
 fill_active_slots () at http.c:441
 441                     if (!slot->in_use && slot->curl != NULL) {
 (gdb) 

Thanks, Gerrit.

Re: git-http-fetch segfault, curl 7.18.0

[Mike Hommey]

On Sun, Mar 02, 2008 at 07:08:57PM +0000, Gerrit Pape wrote:
> Hi, as reported through http://bugs.debian.org/468836, I can reproduce
> with current maint branch on Debian/unstable, but I don't know whether
> it's a problem in curl, or in git.  Maybe anyone with some experience
> in curl can help on this?
> 
> gdb gives this
(...)

valgrind gives better insight:
==862== Invalid read of size 4
==862==    at 0x493B32: fill_active_slots (http.c:441)
==862==    by 0x493CF9: step_active_slots (http.c:459)
==862==    by 0x493D6E: run_active_slot (http.c:479)
==862==    by 0x493F8B: http_cleanup (http.c:296)
==862==    by 0x494CA8: cleanup (http-walker.c:900)
==862==    by 0x4911D6: walker_free (walker.c:315)
==862==    by 0x44A149: cmd_http_fetch (builtin-http-fetch.c:81)
==862==    by 0x404247: handle_internal_command (git.c:248)
==862==    by 0x4049D4: main (git.c:412)
==862==  Address 0x7c7c558 is 16 bytes inside a block of size 72 free'd
==862==    at 0x4C20B2E: free (vg_replace_malloc.c:323)
==862==    by 0x493F47: http_cleanup (http.c:301)
==862==    by 0x494CA8: cleanup (http-walker.c:900)
==862==    by 0x4911D6: walker_free (walker.c:315)
==862==    by 0x44A149: cmd_http_fetch (builtin-http-fetch.c:81)
==862==    by 0x404247: handle_internal_command (git.c:248)
==862==    by 0x4049D4: main (git.c:412)
==862== 
==862== Invalid read of size 8
==862==    at 0x493B50: fill_active_slots (http.c:445)
==862==    by 0x493CF9: step_active_slots (http.c:459)
==862==    by 0x493D6E: run_active_slot (http.c:479)
==862==    by 0x493F8B: http_cleanup (http.c:296)
==862==    by 0x494CA8: cleanup (http-walker.c:900)
==862==    by 0x4911D6: walker_free (walker.c:315)
==862==    by 0x44A149: cmd_http_fetch (builtin-http-fetch.c:81)
==862==    by 0x404247: handle_internal_command (git.c:248)
==862==    by 0x4049D4: main (git.c:412)
==862==  Address 0x7c7c588 is 64 bytes inside a block of size 72 free'd
==862==    at 0x4C20B2E: free (vg_replace_malloc.c:323)
==862==    by 0x493F47: http_cleanup (http.c:301)
==862==    by 0x494CA8: cleanup (http-walker.c:900)
==862==    by 0x4911D6: walker_free (walker.c:315)
==862==    by 0x44A149: cmd_http_fetch (builtin-http-fetch.c:81)
==862==    by 0x404247: handle_internal_command (git.c:248)
==862==    by 0x4049D4: main (git.c:412)
==862== 
==862== Invalid read of size 8
==862==    at 0x493BFD: process_curl_messages (http.c:74)
==862==    by 0x493CF4: step_active_slots (http.c:458)
==862==    by 0x493D6E: run_active_slot (http.c:479)
==862==    by 0x493F8B: http_cleanup (http.c:296)
==862==    by 0x494CA8: cleanup (http-walker.c:900)
==862==    by 0x4911D6: walker_free (walker.c:315)
==862==    by 0x44A149: cmd_http_fetch (builtin-http-fetch.c:81)
==862==    by 0x404247: handle_internal_command (git.c:248)
==862==    by 0x4049D4: main (git.c:412)
==862==  Address 0x7c7c548 is 0 bytes inside a block of size 72 free'd
==862==    at 0x4C20B2E: free (vg_replace_malloc.c:323)
==862==    by 0x493F47: http_cleanup (http.c:301)
==862==    by 0x494CA8: cleanup (http-walker.c:900)
==862==    by 0x4911D6: walker_free (walker.c:315)
==862==    by 0x44A149: cmd_http_fetch (builtin-http-fetch.c:81)
==862==    by 0x404247: handle_internal_command (git.c:248)
==862==    by 0x4049D4: main (git.c:412)
==862== 
==862== Invalid read of size 8
==862==    at 0x493BF0: process_curl_messages (http.c:76)
==862==    by 0x493CF4: step_active_slots (http.c:458)
==862==    by 0x493D6E: run_active_slot (http.c:479)
==862==    by 0x493F8B: http_cleanup (http.c:296)
==862==    by 0x494CA8: cleanup (http-walker.c:900)
==862==    by 0x4911D6: walker_free (walker.c:315)
==862==    by 0x44A149: cmd_http_fetch (builtin-http-fetch.c:81)
==862==    by 0x404247: handle_internal_command (git.c:248)
==862==    by 0x4049D4: main (git.c:412)
==862==  Address 0x7c7c588 is 64 bytes inside a block of size 72 free'd
==862==    at 0x4C20B2E: free (vg_replace_malloc.c:323)
==862==    by 0x493F47: http_cleanup (http.c:301)
==862==    by 0x494CA8: cleanup (http-walker.c:900)
==862==    by 0x4911D6: walker_free (walker.c:315)
==862==    by 0x44A149: cmd_http_fetch (builtin-http-fetch.c:81)
==862==    by 0x404247: handle_internal_command (git.c:248)
==862==    by 0x4049D4: main (git.c:412)
==862== 
==862== Invalid read of size 4
==862==    at 0x494372: get_active_slot (http.c:336)
==862==    by 0x49504A: start_object_request (http-walker.c:195)
==862==    by 0x495413: fill_active_slot (http-walker.c:321)
==862==    by 0x493B1C: fill_active_slots (http.c:433)
==862==    by 0x493CF9: step_active_slots (http.c:459)
==862==    by 0x493D6E: run_active_slot (http.c:479)
==862==    by 0x493F8B: http_cleanup (http.c:296)
==862==    by 0x494CA8: cleanup (http-walker.c:900)
==862==    by 0x4911D6: walker_free (walker.c:315)
==862==    by 0x44A149: cmd_http_fetch (builtin-http-fetch.c:81)
==862==    by 0x404247: handle_internal_command (git.c:248)
==862==    by 0x4049D4: main (git.c:412)
==862==  Address 0x7c7c558 is 16 bytes inside a block of size 72 free'd
==862==    at 0x4C20B2E: free (vg_replace_malloc.c:323)
==862==    by 0x493F47: http_cleanup (http.c:301)
==862==    by 0x494CA8: cleanup (http-walker.c:900)
==862==    by 0x4911D6: walker_free (walker.c:315)
==862==    by 0x44A149: cmd_http_fetch (builtin-http-fetch.c:81)
==862==    by 0x404247: handle_internal_command (git.c:248)
==862==    by 0x4049D4: main (git.c:412)
==862== 
==862== Invalid read of size 8
==862==    at 0x494379: get_active_slot (http.c:337)
==862==    by 0x49504A: start_object_request (http-walker.c:195)
==862==    by 0x495413: fill_active_slot (http-walker.c:321)
==862==    by 0x493B1C: fill_active_slots (http.c:433)
==862==    by 0x493CF9: step_active_slots (http.c:459)
==862==    by 0x493D6E: run_active_slot (http.c:479)
==862==    by 0x493F8B: http_cleanup (http.c:296)
==862==    by 0x494CA8: cleanup (http-walker.c:900)
==862==    by 0x4911D6: walker_free (walker.c:315)
==862==    by 0x44A149: cmd_http_fetch (builtin-http-fetch.c:81)
==862==    by 0x404247: handle_internal_command (git.c:248)
==862==    by 0x4049D4: main (git.c:412)
==862==  Address 0x7c7c588 is 64 bytes inside a block of size 72 free'd
==862==    at 0x4C20B2E: free (vg_replace_malloc.c:323)
==862==    by 0x493F47: http_cleanup (http.c:301)
==862==    by 0x494CA8: cleanup (http-walker.c:900)
==862==    by 0x4911D6: walker_free (walker.c:315)
==862==    by 0x44A149: cmd_http_fetch (builtin-http-fetch.c:81)
==862==    by 0x404247: handle_internal_command (git.c:248)
==862==    by 0x4049D4: main (git.c:412)

It seems there is something wrong going on with slots...

Mike

Re: git-http-fetch segfault, curl 7.18.0

[Mike Hommey]

On Sun, Mar 02, 2008 at 08:23:55PM +0100, Mike Hommey wrote:
> On Sun, Mar 02, 2008 at 07:08:57PM +0000, Gerrit Pape wrote:
> > Hi, as reported through http://bugs.debian.org/468836, I can reproduce
> > with current maint branch on Debian/unstable, but I don't know whether
> > it's a problem in curl, or in git.  Maybe anyone with some experience
> > in curl can help on this?
> > 
> > gdb gives this
> (...)
> 
> valgrind gives better insight:
> ==862== Invalid read of size 4
> ==862==    at 0x493B32: fill_active_slots (http.c:441)
> ==862==    by 0x493CF9: step_active_slots (http.c:459)
> ==862==    by 0x493D6E: run_active_slot (http.c:479)
> ==862==    by 0x493F8B: http_cleanup (http.c:296)
> ==862==    by 0x494CA8: cleanup (http-walker.c:900)
> ==862==    by 0x4911D6: walker_free (walker.c:315)
> ==862==    by 0x44A149: cmd_http_fetch (builtin-http-fetch.c:81)
> ==862==    by 0x404247: handle_internal_command (git.c:248)
> ==862==    by 0x4049D4: main (git.c:412)
> ==862==  Address 0x7c7c558 is 16 bytes inside a block of size 72 free'd
> ==862==    at 0x4C20B2E: free (vg_replace_malloc.c:323)
> ==862==    by 0x493F47: http_cleanup (http.c:301)
> ==862==    by 0x494CA8: cleanup (http-walker.c:900)
> ==862==    by 0x4911D6: walker_free (walker.c:315)
> ==862==    by 0x44A149: cmd_http_fetch (builtin-http-fetch.c:81)
> ==862==    by 0x404247: handle_internal_command (git.c:248)
> ==862==    by 0x4049D4: main (git.c:412)
(...)
> 
> It seems there is something wrong going on with slots...

And the problem lies in the fact we run_active_slot() during cleanup,
which can end up going through all the slots starting at
active_queue_head, while we have freed the first slots...

Now, why do we need to run slots when cleaning up ?

Mike

Re: git-http-fetch segfault, curl 7.18.0

[Daniel Barkalow]

On Sun, 2 Mar 2008, Mike Hommey wrote:

> On Sun, Mar 02, 2008 at 08:23:55PM +0100, Mike Hommey wrote:
> > On Sun, Mar 02, 2008 at 07:08:57PM +0000, Gerrit Pape wrote:
> > > Hi, as reported through http://bugs.debian.org/468836, I can reproduce
> > > with current maint branch on Debian/unstable, but I don't know whether
> > > it's a problem in curl, or in git.  Maybe anyone with some experience
> > > in curl can help on this?
> > > 
> > > gdb gives this
> > (...)
> > 
> > valgrind gives better insight:
> > ==862== Invalid read of size 4
> > ==862==    at 0x493B32: fill_active_slots (http.c:441)
> > ==862==    by 0x493CF9: step_active_slots (http.c:459)
> > ==862==    by 0x493D6E: run_active_slot (http.c:479)
> > ==862==    by 0x493F8B: http_cleanup (http.c:296)
> > ==862==    by 0x494CA8: cleanup (http-walker.c:900)
> > ==862==    by 0x4911D6: walker_free (walker.c:315)
> > ==862==    by 0x44A149: cmd_http_fetch (builtin-http-fetch.c:81)
> > ==862==    by 0x404247: handle_internal_command (git.c:248)
> > ==862==    by 0x4049D4: main (git.c:412)
> > ==862==  Address 0x7c7c558 is 16 bytes inside a block of size 72 free'd
> > ==862==    at 0x4C20B2E: free (vg_replace_malloc.c:323)
> > ==862==    by 0x493F47: http_cleanup (http.c:301)
> > ==862==    by 0x494CA8: cleanup (http-walker.c:900)
> > ==862==    by 0x4911D6: walker_free (walker.c:315)
> > ==862==    by 0x44A149: cmd_http_fetch (builtin-http-fetch.c:81)
> > ==862==    by 0x404247: handle_internal_command (git.c:248)
> > ==862==    by 0x4049D4: main (git.c:412)
> (...)
> > 
> > It seems there is something wrong going on with slots...
> 
> And the problem lies in the fact we run_active_slot() during cleanup,
> which can end up going through all the slots starting at
> active_queue_head, while we have freed the first slots...
> 
> Now, why do we need to run slots when cleaning up ?

AFAICT, it's always been that way. I assume there was code that set up all 
of the remaining transfers and then just called http_cleanup, relying on 
the callbacks to handle the receipt of the remaining data, but I'm not 
sure if that's still the case. On the other hand, I think that code is 
supposed to remove slots from the active queue as they get processed, so 
that run_active_slot() is always safe to call and just won't do anything 
if it's not needed in cleanup.

So I'm guessing that we have list corruption due to code getting careless 
in error cases, in addition to cleanup code that possibly cares too much 
about finishing everything it can.

(I don't really know the http.c code all that well, BTW; I've only 
interacted with it peripherally in reorganizing http-fetch into 
http-walker last summer)

	-Daniel
*This .sig left intentionally blank*

[PATCH] Fix random crashes in http_cleanup()

[Mike Hommey]

For some reason, http_cleanup was running all active slots, which could
lead in situations where a freed slot would be accessed in
fill_active_slots. OTOH, we are cleaning up, which means the caller
doesn't care about pending requests. Just forget about them instead
or running them.

Signed-off-by: Mike Hommey <mh@glandium.org>
---
 > Now, why do we need to run slots when cleaning up ?

 I just think we don't care, so this fix should be okay.

 http.c |   11 +++--------
 1 files changed, 3 insertions(+), 8 deletions(-)

diff --git a/http.c b/http.c
index 5925d07..9683e46 100644
--- a/http.c
+++ b/http.c
@@ -287,17 +287,12 @@ void http_cleanup(void)
 
 	while (slot != NULL) {
 		struct active_request_slot *next = slot->next;
+		if (slot->curl != NULL) {
 #ifdef USE_CURL_MULTI
-		if (slot->in_use) {
-			curl_easy_getinfo(slot->curl,
-					  CURLINFO_EFFECTIVE_URL,
-					  &wait_url);
-			fprintf(stderr, "Waiting for %s\n", wait_url);
-			run_active_slot(slot);
-		}
+			curl_multi_remove_handle(curlm, slot->curl);
 #endif
-		if (slot->curl != NULL)
 			curl_easy_cleanup(slot->curl);
+		}
 		free(slot);
 		slot = next;
 	}
-- 
1.5.4.3.368.g272aa.dirty

Re: git-http-fetch segfault, curl 7.18.0

[Mike Hommey]

On Sun, Mar 02, 2008 at 03:20:17PM -0500, Daniel Barkalow wrote:
> > And the problem lies in the fact we run_active_slot() during cleanup,
> > which can end up going through all the slots starting at
> > active_queue_head, while we have freed the first slots...
> > 
> > Now, why do we need to run slots when cleaning up ?
> 
> AFAICT, it's always been that way. I assume there was code that set up all 
> of the remaining transfers and then just called http_cleanup, relying on 
> the callbacks to handle the receipt of the remaining data, but I'm not 
> sure if that's still the case.

It doesn't look like it is stil the case.

> On the other hand, I think that code is 
> supposed to remove slots from the active queue as they get processed, so 
> that run_active_slot() is always safe to call and just won't do anything 
> if it's not needed in cleanup.
> 
> So I'm guessing that we have list corruption due to code getting careless 
> in error cases, in addition to cleanup code that possibly cares too much 
> about finishing everything it can.

That's in fill_active_slots that it's trying to go through all slots
starting at active_queue_head, which is likely to be freed at this
point. The fix I sent earlier just throws all active slots, which should
just be fine now.

Mike

Re: [PATCH] Fix random crashes in http_cleanup()

[Gerrit Pape]

On Sun, Mar 02, 2008 at 09:28:33PM +0100, Mike Hommey wrote:
> For some reason, http_cleanup was running all active slots, which could
> lead in situations where a freed slot would be accessed in
> fill_active_slots. OTOH, we are cleaning up, which means the caller
> doesn't care about pending requests. Just forget about them instead
> or running them.

Hi, I can confirm that this fixes the segfault we managed to reproduce,
but didn't look deeper into the changes.

There's a warning when compiling http.c, trivial to fix:

      CC http.o
  http.c: In function ‘http_cleanup’:
  http.c:288: warning: unused variable ‘wait_url’

Thanks!, Gerrit.

[PATCH v2] Fix random crashes in http_cleanup()

[Mike Hommey]

For some reason, http_cleanup was running all active slots, which could
lead in situations where a freed slot would be accessed in
fill_active_slots. OTOH, we are cleaning up, which means the caller
doesn't care about pending requests. Just forget about them instead
or running them.

Signed-off-by: Mike Hommey <mh@glandium.org>
---
 http.c |   14 +++-----------
 1 files changed, 3 insertions(+), 11 deletions(-)

diff --git a/http.c b/http.c
index 8e554c0..256a5f1 100644
--- a/http.c
+++ b/http.c
@@ -284,23 +284,15 @@ void http_init(struct remote *remote)
 void http_cleanup(void)
 {
 	struct active_request_slot *slot = active_queue_head;
-#ifdef USE_CURL_MULTI
-	char *wait_url;
-#endif
 
 	while (slot != NULL) {
 		struct active_request_slot *next = slot->next;
+		if (slot->curl != NULL) {
 #ifdef USE_CURL_MULTI
-		if (slot->in_use) {
-			curl_easy_getinfo(slot->curl,
-					  CURLINFO_EFFECTIVE_URL,
-					  &wait_url);
-			fprintf(stderr, "Waiting for %s\n", wait_url);
-			run_active_slot(slot);
-		}
+			curl_multi_remove_handle(curlm, slot->curl);
 #endif
-		if (slot->curl != NULL)
 			curl_easy_cleanup(slot->curl);
+		}
 		free(slot);
 		slot = next;
 	}
-- 
1.5.4.3.368.g272aa.dirty