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 <p...@unnservice.com> 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
