Hi, On Fri, 18 Jan 2008, Johannes Schindelin wrote: > > $gmane/70407 <1200250979-19604-2-git-send-email-gb@xxxxxxxxxxxx> > > I first could not reproduce the breakage described in the commit message > (bad or no ref given on command line). > > After playing around for a while, all of a sudden, I got a segmentation > fault: > > Waiting for > http://dscho@xxxxxxxxx/test.git/objects/56/5e84516c1c6dca168be1715b45aeae70b24d13_36e8d912-4841-455a-bbd9-69e54d00db99 > Segmentation fault (core dumped) > > Unfortunately, this is with _and_ without this patch. > > > In gdb, it looks like this: > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread -1213430096 (LWP 31418)] > check_locks () at http-push.c:637 > 637 if (!lock->refreshing && time_remaining < > LOCK_REFRESH) { > (gdb) p lock > $1 = (struct remote_lock *) 0x20 > (gdb) bt > #0 check_locks () at http-push.c:637 > #1 0x08053f8a in process_response (callback_data=0x80c4550) > at http-push.c:683 > #2 0x0804dbf4 in process_curl_messages () at http.c:539 > #3 0x0804dc46 in step_active_slots () at http.c:453 > #4 0x0804dccb in run_active_slot (slot=0x80c2388) at http.c:474 > #5 0x0804deaa in http_cleanup () at http.c:291 > #6 0x0805268f in main (argc=3, argv=Cannot access memory at address 0x4 > ) at http-push.c:2428 > > So it seems that there is more to fix. The segmentation fault occurs due to check_locks() accessing the remote that was just free()d, due to the new change. But now I cannot even reproduce the segmentation fault, it seems. Strange. Very strange. Grégoire, it would help tremendously if you could come up with a test case. The description you gave did not lead to something reproducible here. Ciao, Dscho
