Pavel Roskin [off-list ref] 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?
On Tue, 2006-06-06 at 22:35 -0700, Junio C Hamano wrote:
Pavel Roskin [off-list ref] writes:
quoted
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