On Thu, Mar 6, 2014 at 1:16 PM, Jeff King <p...@peff.net> wrote:
> 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)
>> 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
#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
#10 0x00000001058b7469 in fetch_one (remote=<value temporarily
unavailable, due to optimizations>, argc=<value temporarily
unavailable, due to optimizations>, argv=0x7fff00000000) at
#11 0x00000001058b6f22 in cmd_fetch (argc=<value temporarily
unavailable, due to optimizations>, argv=<value temporarily
unavailable, due to optimizations>, prefix=0x0) at
#12 0x0000000105890acc in run_builtin [inlined] () at
#13 0x0000000105890acc in handle_builtin (argc=3, argv=0x7fff5a370648)
#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.
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