On 10/05/16 00:12, David Turner wrote:
> On Mon, 2016-05-09 at 15:32 -0700, Junio C Hamano wrote:
>> Junio C Hamano <gits...@pobox.com> writes:
>>
>>> David Turner <dtur...@twopensource.com> writes:
>>>
>>>> On Mon, 2016-05-09 at 14:40 -0700, Junio C Hamano wrote:
>>>>> Hmmm, I seem to be getting
>>>>>
>>>>> $ cat t/trash*7900*/err
>>>>> fatal: Already running
>>>>>
>>>>> after running t7900 and it fails at #5, after applying
>>>>> "index-helper: optionally automatically run"
>>
>> The symptom looks pretty similar to $gmane/293461 reported earlier.
>> Here is how "t7900-index-helper.sh -i -v -x -d" ends.
>>
>>
>> expecting success:
>> test_when_finished "git index-helper --kill" &&
>> rm -f .git/index-helper.sock &&
>> git status &&
>> test_path_is_missing .git/index-helper.sock &&
>> test_config indexhelper.autorun true &&
>> git status &&
>> test -S .git/index-helper.sock &&
>> git status 2>err &&
>> test -S .git/index-helper.sock &&
>> test_must_be_empty err &&
>> git index-helper --kill &&
>> test_config indexhelper.autorun false &&
>> git status &&
>> test_path_is_missing .git/index-helper.sock
>>
>> + test_when_finished git index-helper --kill
>> + test 0 = 0
>> + test_cleanup={ git index-helper --kill
>> } && (exit "$eval_ret"); eval_ret=$?; :
>> + rm -f .git/index-helper.sock
>> + git status
>> On branch master
>> Untracked files:
>> (use "git add <file>..." to include in what will be committed)
>>
>> err
>>
>> nothing added to commit but untracked files present (use "git add" to
>> track)
>> + test_path_is_missing .git/index-helper.sock
>> + test -e .git/index-helper.sock
>> + test_config indexhelper.autorun true
>> + config_dir=
>> + test indexhelper.autorun = -C
>> + test_when_finished test_unconfig 'indexhelper.autorun'
>> + test 0 = 0
>> + test_cleanup={ test_unconfig 'indexhelper.autorun'
>> } && (exit "$eval_ret"); eval_ret=$?; { git index
>> -helper --kill
>> } && (exit "$eval_ret"); eval_ret=$?; :
>> + git config indexhelper.autorun true
>> + git status
>> error: last command exited with $?=141
>
> I think that's a SIGPIPE on the first git status. Weird, since I just
> added sigpipe-avoidance code (in v8). Does anyone have any idea why
> the sigchain stuff isn't doing what I think it is?
Sorry for a late report (I've been a bit busy last couple of days), but
I've been seeing exactly the same on v8 of this series.
Note that the above 'git status' is actually the second git-status in the
test.
I haven't been able to debug it too much, but I can tell you that it is
not failing at exactly the same place every time (so it may be time
sensitive). However, it often fails in poke_and_wait_for_reply() at the
first packet_flush() (which in turn calls write_or_die() which calls
check_pipe() with an EPIPE(32)). At other times it fails when issuing
a flush after a refresh packet. For example, on one run with packet
tracing enabled, I got this for the trace:
trace: built-in: git 'status'
packet: git> poke 3221
packet: git> 0000
packet: git< OK
packet: git> refresh
packet: git> 0000
So, its getting the EPIPE for the refresh in this case, even though
the index-helper is still running, the unix socket is in .git/
(and so is a shm-* file BTW).
I didn't get any further than that I'm afraid.
ATB,
Ramsay Jones
--
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
