Re: [PATCH v9 00/19] index-helper/watchman

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

 




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 <gitster@xxxxxxxxx> writes:
>>
>>> David Turner <dturner@xxxxxxxxxxxxxxxx> 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 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]