From: Philip Oakley <philipoakley@iee.email>
Date: Fri, 18 Oct 2019 21:05:03 GMT
Subject: Re: Git Gui: Branch->create currently fails...
Message-ID: <6648dd51-ab60-c462-b800-c6e68fe325a3@iee.email>
In-Reply-To: <20191016185221.hufjb4uavacumbmc@yadavpratyush.com>

Hi Pratyush

On 16/10/2019 19:52, Pratyush Yadav wrote:
> On 14/10/19 11:11PM, Philip Oakley wrote:
>> On 14/10/2019 18:57, Pratyush Yadav wrote:
>>>> list "refs/heads/MSVC-README" [list "commit"
>>>> "056fb95c8e983ec07e9f5f8baa0b119bf3d13fed" [concat "" "Philip Oakley"]
>>>> [reformat_date [concat "" "Sun May 19 22:33:37 2019 +0100"]]
>>>> "compat/vcSegmentation fault
>>>>
>>>>
>>>> Not exactly the same, but almost. Ends the same place, with as similar short
>>>> line.
>>>> This is run inside the bash that is started directly by the git-for-windows
>>>> sdk start icon. (Target: C:\git-sdk-64\git-bash.exe   Stat in:
>>>> C:/git-sdk-64/)
>>>>
>>>> so looks to be MSYS2/bash related.
>>> Ah, so it is an upstream issue. I guess we can just report it and wait
>>> for them to fix it.
>> I'd missed the final 'Segmentation fault' on the last line in the bash
>> output that wasn't there for the captured file.
>>
>> That was repeatable in re-testing.
>> But failed if I changed the $fmt string to a plain text 500 char string
>> ("1234567890123...").
>>
>> I've still to trim down the complicated $fmt string to see if I can see
>> where that seg fault starts (i.e. some form of MVCE), so that it can be
>> investigated.
>> Possibly should check if the --tcl flag actually invokes any tcl! Otherwise
>> it's fully in the Git/G-f-W zone.
> A quick look tells me '--tcl' does not invoke any Tcl. It is just used
> to output properly formatted strings for Tcl. The option sets the value
> of 'format.quote_style' in for-each-ref (builtin/for-each-ref.c:33).
> That value is later indirectly ends up being used in the function
> ref_filter.c::quote_formatting.
>
> The Tcl code we execute comes from the long $fmt string, which is built
> in git-gui/choose_rev.tcl:133-147. `for-each-ref` just fills in the
> placeholder values, properly formatting them for use in Tcl.
>
> As an experiment, you can try removing '--tcl' from the `for-each-ref`
> command that segfaults, just to be sure. It would probably output
> invalid Tcl, but since we don't do anything with that output, it doesn't
> really matter, and would let us know if '--tcl' is really the culprit.
Command reminder:
fmt='list %(refname) [list %(objecttype) %(objectname) [concat 
%(taggername) %(authorname)] [reformat_date [concat %(taggerdate) 
%(authordate)]] %(subject)] [list %(*objecttype) %(*objectname) 
%(*authorname) [reformat_date %(*authordate)] %(*subject)]'

git for-each-ref --format="$fmt" --sort=-taggerdate refs/heads 
refs/remotes refs/tags
-
Removing the '--tcl' still seg faults.

Removing the  --sort=-taggerdate  *stops* the segfault.

Removing instead the final 'refs/tags' (i.e. a shorter list) also 
*stops* the seg fault (still with the --sort=..)

If instead I drop the initial refs/heads (a limited number of branch 
heads!) it segfaults (still with --sort) so looks like it's a size issue.

Alternative approach - trim the fmt string, dropping all the '*' types.
$ fmt='list %(refname) [list %(objecttype) %(objectname) [concat 
%(taggername) %(authorname)] [reformat_date [concat %(taggerdate) 
%(authordate)]] %(subject)]'

The full for-each-ref command now works, BUT the last line of output is 
short, rather than being a seg fault. (with or without the --sortdate)

so all in all rather weird. Sometimes it seg faults and sometimes it 
simply terminates early.
>> ...
>> Just rebuilt (I hope) the Windows Subsystem for Linux (WSL) with git v2.23.0
>> installed and got:
>>
>> list "refs/heads/MSVC-README" [list "commit"
>> "056fb95c8e983ec07e9f5f8baa0b119bf3d13fed" [concat "" "Philip Oakley"]
>> [reformat_date [concat "" "Sun May 19 22:33:37 2019 +0100"]]
>> "compat/vcbuild/README: clean/update 'vcpkg' env for Visual Studio updates"]
>> [list "" "" "" [reformat_date ""] ""]
>> munmap_chunk(): invalid pointer
> A quick Google search tells me munmap_chunk() is probably related to an
> invalid pointer being freed. Either a double free or a free on a pointer
> not allocated by malloc or something similar.
>
>> Aborted (core dumped)
>> root@Philip-Win10:/mnt/c/git-sdk-64/usr/src/git#
>>
>>
>> That said, haven't got the gitk and git gui to work yet on the WSL because
>> it doesn't like the tcl/tk.
>>
>> It's a bit of a hole digging exercise.
The hole that keeps digging...
P.