Hi,

On Fri, 18 Jan 2008, Johannes Schindelin wrote:

quoted text
> >   $gmane/70407 <1200250979-19604-2-git-send-email-gb@gbarbier.org>
> 
> 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@127.0.0.1/test.git/objects/56/5e84516c1c6dca168be1715b45aeae70b24d13_36e8...
> 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
>  = (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