Re: Git Gui: Branch->create currently fails...
- From
Philip Oakley <philipoakley@iee.email>
- Date
- Oct 18, 2019, 21:05 UTC
- 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:
Show 43 quoted lines
> 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.
Show 22 quoted lines
>> ... >> 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.