Re: Git hangs on clone

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I should add to the facts that:


- git version: git version 1.7.11.2
- Happens only when using protocols git:// and have seen it with
https:// too, but never with http://
- Saw a similar issue here:
http://code.google.com/p/msysgit/issues/detail?id=361


On 11 August 2012 04:48, Paul Alesius <paul@xxxxxxxxxxxxxx> wrote:
> 80 out of 100 times git will hang indefinitely during a clone operation.
> Here's the state of things during the hangs:
>
>
> ----------------------- scenario 1:
> remote: Counting objects: 306395, done.
> remote: Compressing objects: 100% (47753/47753), done.
> remote: Total 306395 (delta 259044), reused 305469 (delta 258264)
> Receiving objects: 100% (306395/306395), 207.20 MiB | 5.80 MiB/s, done.
> Resolving deltas: 100% (259044/259044), done.
> ----------------------- ps aux | grep git:
> build    28122  0.1  0.0 126032  2092 pts/1    Sl+  04:19   0:00 git clone
> git://git.gnome.org/gtk+
> ---------------------- backtrace for scenario 1:
> (gdb) bt
> #0  0x0000003c9ee08e60 in pthread_join (threadid=47144800229120,
> thread_return=thread_return@entry=0x7fff19edc928) at pthread_join.c:93
> #1  0x00000000004cb6ab in finish_async (async=async@entry=0x7fff19edca00) at
> run-command.c:739
> #2  0x0000000000428318 in get_pack (pack_lockfile=0x121df80, xd=0x121dfc0)
> at builtin/fetch-pack.c:773
> #3  do_fetch_pack (pack_lockfile=0x121df80, match=0x125e0a0, nr_match=544,
> orig_ref=<optimized out>, fd=0x121dfc0) at builtin/fetch-pack.c:835
> #4  fetch_pack (my_args=my_args@entry=0x7fff19edd1b0, fd=fd@entry=0x121dfc0,
> conn=<optimized out>, ref=<optimized out>, dest=dest@entry=0x1217e70
> "git://git.gnome.org/gtk+",
>     nr_heads=nr_heads@entry=544, heads=heads@entry=0x125e0a0,
> pack_lockfile=pack_lockfile@entry=0x121df80) at builtin/fetch-pack.c:1090
> #5  0x00000000004de08e in fetch_refs_via_pack (transport=0x121df20,
> nr_heads=544, to_fetch=0x125c880) at transport.c:549
> #6  0x00000000004e0472 in transport_fetch_refs
> (transport=transport@entry=0x121df20, refs=refs@entry=0x123d3c0) at
> transport.c:1167
> #7  0x000000000041cbce in cmd_clone (argc=<optimized out>, argv=<optimized
> out>, prefix=<optimized out>) at builtin/clone.c:859
> #8  0x00000000004057d8 in run_builtin (argv=0x7fff19edd900, argc=2,
> p=0x74a040) at git.c:308
> #9  handle_internal_command (argc=2, argv=0x7fff19edd900) at git.c:468
> #10 0x0000000000404be2 in run_argv (argv=0x7fff19edd790,
> argcp=0x7fff19edd79c) at git.c:514
> #11 main (argc=2, argv=0x7fff19edd900) at git.c:589
> ----------------------
>
>
>
>
> ---------------------- scenario 2:
> remote: Counting objects: 306395, done.
> remote: Compressing objects: 100% (47753/47753), done.
> Receiving objects:  99% (303332/306395), 205.18 MiB | 452 KiB/s
> ----------------------- ps aux | grep git:
> build    28247  0.5  0.0 126032  2088 pts/1    Sl+  04:30   0:00 git clone
> git://git.gnome.org/gtk+
> build    28249  8.4  0.3 144908 30480 pts/1    S+   04:30   0:12 git
> index-pack --stdin -v --fix-thin --keep=fetch-pack 28247 on mydomain
> ---------------------- backtrace for scenario 1:
> #0  0x0000003c9ee0e0ad in read () at ../sysdeps/unix/syscall-template.S:82
> #1  0x00000000004ea29f in read (__nbytes=46, __buf=0x7fffeb4d8cc0, __fd=7)
> at /usr/include/bits/unistd.h:45
> #2  xread (fd=fd@entry=7, buf=buf@entry=0x7fffeb4d8cc0, len=len@entry=46) at
> wrapper.c:142
> #3  0x00000000004ea38b in read_in_full (fd=7, buf=buf@entry=0x7fffeb4d8cc0,
> count=count@entry=46) at wrapper.c:171
> #4  0x00000000004ad78c in index_pack_lockfile (ip_out=<optimized out>) at
> pack-write.c:298
> #5  0x00000000004285d4 in get_pack (pack_lockfile=0x1928f80, xd=0x1928fc0)
> at builtin/fetch-pack.c:767
> #6  do_fetch_pack (pack_lockfile=0x1928f80, match=0x19690a0, nr_match=544,
> orig_ref=<optimized out>, fd=0x1928fc0) at builtin/fetch-pack.c:835
> #7  fetch_pack (my_args=my_args@entry=0x7fffeb4da580, fd=fd@entry=0x1928fc0,
> conn=<optimized out>, ref=<optimized out>, dest=dest@entry=0x1922e70
> "git://git.gnome.org/gtk+",
>     nr_heads=nr_heads@entry=544, heads=heads@entry=0x19690a0,
> pack_lockfile=pack_lockfile@entry=0x1928f80) at builtin/fetch-pack.c:1090
> #8  0x00000000004de08e in fetch_refs_via_pack (transport=0x1928f20,
> nr_heads=544, to_fetch=0x1967880) at transport.c:549
> #9  0x00000000004e0472 in transport_fetch_refs
> (transport=transport@entry=0x1928f20, refs=refs@entry=0x19483c0) at
> transport.c:1167
> #10 0x000000000041cbce in cmd_clone (argc=<optimized out>, argv=<optimized
> out>, prefix=<optimized out>) at builtin/clone.c:859
> #11 0x00000000004057d8 in run_builtin (argv=0x7fffeb4dacd0, argc=2,
> p=0x74a040) at git.c:308
> #12 handle_internal_command (argc=2, argv=0x7fffeb4dacd0) at git.c:468
> #13 0x0000000000404be2 in run_argv (argv=0x7fffeb4dab60,
> argcp=0x7fffeb4dab6c) at git.c:514
> #14 main (argc=2, argv=0x7fffeb4dacd0) at git.c:589
> ----------------------
>
>
>
> ---------------------- facts:
> - Happens on multiple machines on this LAN, which made me believe it's the
> NAT router.
> - Happens when using any repository.
> - There's nothing filtering egress ports (Other than the NAT)
> - Kernel 3(?) to 3.5 which I run currently
> - I often see it hang at __read_nocancel too in the backtrace, which is part
> of the read()
> - I have to abort the clone operation and retry indefinitely until it works,
> which may be never.
>
>
>
>
> - Paul
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]