Re: [BUG] Halt during fetch on MacOS

From: Conley Owens <cco3@android.com>
Date: Mar 6, 2014, 23:12 UTC
Message-ID: <CAFFUb6X7NJfQQKkJsM+KWn5hiE0C_t3-_DKZh7tONBCm3XVfRQ@mail.gmail.com>
In-Reply-To: <20140306211645.GA11926@sigill.intra.peff.net>

On Thu, Mar 6, 2014 at 1:16 PM, Jeff King <peff@peff.net> wrote:

Show 23 quoted lines

> On Thu, Mar 06, 2014 at 10:24:49AM -0800, Junio C Hamano wrote:
>
>> > OK, I've tried using my own build from master, and I still get the same results.
>> >
>> > I've done a little more investigation and discovered it always hangs at:
>> > `atexit(notify_parent);` in `run-command.c:start_command`
>> > when running:
>> > trace: run_command: 'git-remote-https' 'aosp'
>> > 'https://android.googlesource.com/platform/external/tinyxml2'
>> >
>> > Could this have to do with the atexit implementation?  (eg. limit on
>> > the number of functions that can be registered, etc)
>>
>> Thanks.
>>
>> An interesting theory indeed.  I read that an implementation is
>> supposed to take at least ATEXIT_MAX (32) calls to atexit(3); while
>> I do think we register functions with atexit(3) from multiple places
>> in our code, I doubt we would be making that many.
>
> It seems awfully weird that it would _hang_ in such a case, though. That
> sounds more like hitting a mutex that's internal to atexit(), or
> something similar.

You are correct that it's a mutex internal to atexit. The crazy thing is that there is only one thread sitting and waiting for it. ==================== (gdb) thread apply all bt

Thread 1 (process 71053): #0 0x00007fff8cb67122 in __psynch_mutexwait () #1 0x00007fff833d0dcd in pthread_mutex_lock () #2 0x00007fff8d4a77e0 in LockHelper::LockHelper () #3 0x00007fff8d4a8d0a in dladdr () #4 0x00007fff83412260 in atexit () #5 0x000000010597b35e in start_command (cmd=0x7fe1cd801b30) at run-command.c:374 #6 0x0000000105998959 in get_helper (transport=<value temporarily unavailable, due to optimizations>) at transport-helper.c:142 #7 0x00000001059970bd in get_refs_list (transport=0x7fe1cd801370, for_push=0) at transport-helper.c:954 #8 0x000000010599635d in transport_get_remote_refs (transport=0x7fe1cd801370) at transport.c:1227 #9 0x00000001058b7469 in get_ref_map [inlined] () at /Users/android-build/cco3/master/git/builtin/fetch.c:278 #10 0x00000001058b7469 in fetch_one (remote=<value temporarily unavailable, due to optimizations>, argc=<value temporarily unavailable, due to optimizations>, argv=0x7fff00000000) at builtin/fetch.c:862 #11 0x00000001058b6f22 in cmd_fetch (argc=<value temporarily unavailable, due to optimizations>, argv=<value temporarily unavailable, due to optimizations>, prefix=0x0) at builtin/fetch.c:1158 #12 0x0000000105890acc in run_builtin [inlined] () at /Users/android-build/cco3/master/git/git.c:314 #13 0x0000000105890acc in handle_builtin (argc=3, argv=0x7fff5a370648) at git.c:487 #14 0x00000001058906c1 in main (argc=3, av=<value temporarily unavailable, due to optimizations>) at git.c:533 ===================

>
> Conley, can you see if dropping that atexit clears up the problem (you
> should be OK without it; git will just fail to notice the child's
> exec failure with as much detail).

Yes, I'm unable to reproduce the issue after dropping atexit.

>
> -Peff