Re: http-fetch segfault fix?

From: Pavel Roskin <proski@gnu.org>
Date: Jun 7, 2006, 05:41 UTC
Message-ID: <1149658914.5648.5.camel@dv>
In-Reply-To: <7vlks9le8b.fsf_-_@assigned-by-dhcp.cox.net>

On Tue, 2006-06-06 at 22:35 -0700, Junio C Hamano wrote:

Show 15 quoted lines

> 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