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.
