Re: http-fetch segfault fix?

[Pavel Roskin <proski@gnu.org>]

On Tue, 2006-06-06 at 22:35 -0700, Junio C Hamano wrote:
> Pavel Roskin <proski@gnu.org> writes:
> 
> > It's a different backtrace this time.  abort_object_request() has this code:
> >
> > if (obj_req->slot) {
> >      release_active_slot(obj_req->slot);
> >      obj_req->slot = NULL;
> > }
> >
> > Apparently just because obj_req->slot is not NULL doesn't mean it's a
> > valid pointer.  I'm going to use Valgrind now.
> 
> Nick's one-liner to explicitly initialize newreq->slot to NULL
> looks obviously correct to me.  Does it fix this problem for
> you?

I'm going to leave the tests running overnight, both with and without
USE_CURL_MULTI.

The Valgrind diagnostics confirms that obj_req->slot is not initialized
(as opposed to being a pointer to a freed area or something else):

==27182== Conditional jump or move depends on uninitialised value(s)
==27182==    at 0x4070EA: abort_object_request (http-fetch.c:1059)
==27182==    by 0x4071CE: fetch_object (http-fetch.c:1078)
==27182==    by 0x4073EC: fetch (http-fetch.c:1126)
==27182==    by 0x403125: loop (fetch.c:180)
==27182==    by 0x403369: pull (fetch.c:248)
==27182==    by 0x407A13: main (http-fetch.c:1271)

Line 1059 is:
if (obj_req->slot) {

-- 
Regards,
Pavel Roskin