would lead to range-diff segfaulting when there are mode-only changes
> in a range.
>
> Move the error handling and completing of the struct into the
> 'parse_git_diff_header' function, so other callers can take advantage
> of it. This fixes the segfault in 'git range
o range-diff segfaulting when there are mode-only changes
> in a range.
>
> Move the error handling and completing of the struct into the
> 'parse_git_diff_header' function, so other callers can take advantage
> of it. This fixes the segfault in 'git range-diff'.
ng and completing of the struct into the
'parse_git_diff_header' function, so other callers can take advantage
of it. This fixes the segfault in 'git range-diff'.
Reported-by: Uwe Kleine-König
Signed-off-by: Thomas Gummerer
---
Thanks Junio and Dscho for your reviews. I decided to l
On Thu, Sep 12, 2019 at 10:41:22AM -0400, Jeff King wrote:
> Here's a re-roll of my "disable commit graph more gently" fix. Versus
> v1:
Thanks for sending a re-roll. I deployed this out to all of our servers
running git at GitHub, and it seems to be working fine.
For what it's worth, I don't hav
On Thu, Sep 12, 2019 at 10:41:22AM -0400, Jeff King wrote:
> Here's a re-roll of my "disable commit graph more gently" fix. Versus
> v1:
>
> - I've included a preparatory patch that speeds up
> prepare_commit_graph(). It's not strictly related, but there's a
> textual dependency. It cou
Here's a re-roll of my "disable commit graph more gently" fix. Versus
v1:
- I've included a preparatory patch that speeds up
prepare_commit_graph(). It's not strictly related, but there's a
textual dependency. It could be easily spun off to its own series.
- a comment points out that
Thanks for letting me know and for the corrections too.
Cheers,
tamas
On 7/29/19 9:50 PM, Jeff King wrote:
On Mon, Jul 29, 2019 at 04:19:47PM +0200, Tamas Papp wrote:
Generate 100k file into a repository:
#!/bin/bash
rm -rf .git test.file
git init
git config user.email a@b
git config use
On Mon, Jul 29, 2019 at 04:19:47PM +0200, Tamas Papp wrote:
> Generate 100k file into a repository:
>
> #!/bin/bash
>
> rm -rf .git test.file
> git init
> git config user.email a@b
> git config user.name c
>
> time for i in {1..10}
> do
> [ $((i % 2)) -eq 1 ] && echo $i>test.file || echo
hi All,
We ran into a segfault with all version of command line git.
We are able to reproduce this issue by this way:
Generate 100k file into a repository:
#!/bin/bash
rm -rf .git test.file
git init
git config user.email a@b
git config user.name c
time for i in {1..10}
do
[ $((i % 2
Jeff King writes:
> Something like:
>
> for (line = buf; *line; line = next) {
> next = strchrnul(line, '\n');
>
> ... do stuff ...
> /* find a space within the line */
> space = memchr(line, ' ', next - line);
> }
I am not sure about the memchr() thing, but "prepare
On Tue, Jul 16, 2019 at 11:20:48AM -0700, Junio C Hamano wrote:
> That is this thing.
>
> static void parse_gpg_output(struct signature_check *sigc)
> {
> const char *buf = sigc->gpg_status;
> const char *line, *next;
> int i, j;
>
Thanks. I hope this works ok for you (see attached).
On Tue, Jul 16, 2019 at 11:20 AM Junio C Hamano wrote:
>
> Steven Roberts writes:
>
> > I believe I have found an off-by-one error in git.
> >
> > Please see https://marc.info/?l=openbsd-ports&m=156326783610123&w=2
>
> That is this thing.
>
>
Steven Roberts writes:
> I believe I have found an off-by-one error in git.
>
> Please see https://marc.info/?l=openbsd-ports&m=156326783610123&w=2
That is this thing.
static void parse_gpg_output(struct signature_check *sigc)
{
const char *buf = sigc->gpg_status
Hi,
I believe I have found an off-by-one error in git.
Please see https://marc.info/?l=openbsd-ports&m=156326783610123&w=2
On Sun, May 12, 2019 at 6:02 AM Jeff King wrote:
>
> On Sat, May 11, 2019 at 06:31:20PM -0400, Jeff King wrote:
>
> > On Sat, May 11, 2019 at 08:57:11PM +, Eric Wong wrote:
> >
> > > This test-tool submodule segfault seems new. Noticed it while
> &g
On Sat, May 11, 2019 at 06:31:20PM -0400, Jeff King wrote:
> On Sat, May 11, 2019 at 08:57:11PM +, Eric Wong wrote:
>
> > This test-tool submodule segfault seems new. Noticed it while
> > checking dmesg for other things.
>
> Yeah, I hadn't seen it befo
On Sat, May 11, 2019 at 08:57:11PM +, Eric Wong wrote:
> This test-tool submodule segfault seems new. Noticed it while
> checking dmesg for other things.
Yeah, I hadn't seen it before. It's almost certainly the expect_failure
added in 2b1257e463 (t/helper: add test-submo
This test-tool submodule segfault seems new. Noticed it while
checking dmesg for other things.
There's also "name-rev HEAD~4000" (bottom), which is old, I think...
Core was generated by `$WT/t/helper/test-tool submodule-nested-repo-config
submodule sub'.
Program terminated
When core.commitGraph=true is set, various common commands now consult
the commit graph. Because the commit-graph code is very trusting of
its input data, it's possibly to construct a graph that'll cause an
immediate segfault on e.g. "status" (and e.g. "log", &quo
(8):
commit-graph tests: split up corrupt_graph_and_verify()
commit-graph tests: test a graph that's too small
commit-graph: fix segfault on e.g. "git status"
commit-graph: don't early exit(1) on e.g. "git status"
commit-graph: don't pass filename to load_commit_graph
On Fri, Mar 15 2019, Eric Sunshine wrote:
> On Thu, Mar 14, 2019 at 5:47 PM Ævar Arnfjörð Bjarmason
> wrote:
>> I fixed a test to avoid the pattern a0a630192d
>> (t/check-non-portable-shell: detect "FOO=bar shell_func", 2018-07-13)
>> tests for. The new pattern is more obvious.
>>
>> As an asid
On Thu, Mar 14, 2019 at 5:47 PM Ævar Arnfjörð Bjarmason
wrote:
> I fixed a test to avoid the pattern a0a630192d
> (t/check-non-portable-shell: detect "FOO=bar shell_func", 2018-07-13)
> tests for. The new pattern is more obvious.
>
> As an aside I don't get how that doesn't work as intended from t
When core.commitGraph=true is set, various common commands now consult
the commit graph. Because the commit-graph code is very trusting of
its input data, it's possibly to construct a graph that'll cause an
immediate segfault on e.g. "status" (and e.g. "log", &quo
8):
commit-graph tests: split up corrupt_graph_and_verify()
commit-graph tests: test a graph that's too small
commit-graph: fix segfault on e.g. "git status"
commit-graph: don't early exit(1) on e.g. "git status"
commit-graph: don't pass filename to
When core.commitGraph=true is set, various common commands now consult
the commit graph. Because the commit-graph code is very trusting of
its input data, it's possibly to construct a graph that'll cause an
immediate segfault on e.g. "status" (and e.g. "log", &quo
required for
testing it (unless you're on NetBSD).
Instrumenting the commit-graph tests reveals that if you have a broken
commit-graph git will either segfault or abort early with cryptic
errors on such basic commands as "status".
Furthemore, if our graph is corrupt and we've s
Matthew DeVore writes:
> When a command is invoked with both --exclude-promisor-objects,
> --objects-edge-aggressive, and a missing object on the command line,
> the rev_info.cmdline array could get a NULL pointer for the value of
> an 'item' field. Prevent dereferencing of a NULL pointer in that
When a command is invoked with both --exclude-promisor-objects,
--objects-edge-aggressive, and a missing object on the command line,
the rev_info.cmdline array could get a NULL pointer for the value of
an 'item' field. Prevent dereferencing of a NULL pointer in that
situation.
Properly handle --ig
Matthew DeVore writes:
> When a command is invoked with both --exclude-promisor-objects,
> --objects-edge-aggressive, and a missing object on the command line,
> the rev_info.cmdline array could get a NULL pointer for the value of
> an 'item' field. Prevent dereferencing of a NULL pointer in that
When a command is invoked with both --exclude-promisor-objects,
--objects-edge-aggressive, and a missing object on the command line,
the rev_info.cmdline array could get a NULL pointer for the value of
an 'item' field. Prevent dereferencing of a NULL pointer in that
situation.
There are a few othe
cc8aca797dbd7d2be3b67458ff880ed45cddf
Published-As:
https://github.com/gitgitgadget/git/releases/tags/pr-47%2Fjamill%2Ffix-gc-segfault-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git
pr-47/jamill/fix-gc-segfault-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/47
--
gitgitgadget
I instructed downstream to update their repository.
On Mon, Oct 1, 2018 at 2:31 PM Raymond Jennings wrote:
>
> Yes, git 2.16.4 to be exact.
>
> I upgraded to 2.19 after ~arch keywording the package on gentoo and
> that fixed it.
> On Mon, Oct 1, 2018 at 12:19 PM Stefan Beller wrote:
> >
> > On Sa
Yes, git 2.16.4 to be exact.
I upgraded to 2.19 after ~arch keywording the package on gentoo and
that fixed it.
On Mon, Oct 1, 2018 at 12:19 PM Stefan Beller wrote:
>
> On Sat, Sep 29, 2018 at 9:43 AM Raymond Jennings wrote:
> >
> > I have a repo, but it appears to be specific to staging area st
On Sat, Sep 29, 2018 at 9:43 AM Raymond Jennings wrote:
>
> I have a repo, but it appears to be specific to staging area state.
> It only segfaults when I have a certain file deleted.
>
> Where do you want me to upload it?
> On Sat, Sep 29, 2018 at 8:34 AM Duy Nguyen wrote:
> >
> > On Sat, Sep 29
I have a repo, but it appears to be specific to staging area state.
It only segfaults when I have a certain file deleted.
Where do you want me to upload it?
On Sat, Sep 29, 2018 at 8:34 AM Duy Nguyen wrote:
>
> On Sat, Sep 29, 2018 at 5:31 PM Ævar Arnfjörð Bjarmason
> wrote:
> > > #1 refs_resol
On Sat, Sep 29, 2018 at 5:31 PM Ævar Arnfjörð Bjarmason
wrote:
> > #1 refs_resolve_ref_unsafe (refs=0x0,
> > refname=refname@entry=0x55e863062253 "HEAD",
> > resolve_flags=resolve_flags@entry=1, oid=oid@entry=0x7ffdc834b1c0,
> > flags=flags@entry=0x7ffdc834b1bc) at refs.c:1493
refs is NULL. It l
On Sat, Sep 29 2018, Raymond Jennings wrote:
> [New LWP 19644]
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib64/libthread_db.so.1".
> Core was generated by `git submodule--helper status'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0
[New LWP 19644]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `git submodule--helper status'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 refs_read_raw_ref (type=, referent=,
oid=, refname=, ref_st
On Fri, Sep 21 2018, Jeff King wrote:
> On Sat, Sep 22, 2018 at 01:37:17AM +0200, Ævar Arnfjörð Bjarmason wrote:
>
>> > Thanks, both of you ;-). I was aware of the issue and proposed fix
>> > but forgot about it when merging things down to 'master'. Sorry
>> > about that.
>>
>> Just a follow-
On Sat, Sep 22, 2018 at 01:37:17AM +0200, Ævar Arnfjörð Bjarmason wrote:
> > Thanks, both of you ;-). I was aware of the issue and proposed fix
> > but forgot about it when merging things down to 'master'. Sorry
> > about that.
>
> Just a follow-up question, in your merge commit you just pushed
0bf9103c-9377-506b-7ad7-e5273d8e9...@gmail.com/T/#u
>>>>
>>>> [2] https://public-inbox.org/git/pull.39.git.gitgitgad...@gmail.com/
>>>>
>>>> [3]
>>>> https://public-inbox.org/git/8d6061de-1654-577c-40c6-211dbd03a...@gmail.com/
>>>
-inbox.org/git/pull.39.git.gitgitgad...@gmail.com/
>>>
>>> [3]
>>> https://public-inbox.org/git/8d6061de-1654-577c-40c6-211dbd03a...@gmail.com/
>> Thanks and sorry for the duplicate report. I can confirm that applying
>> the v2 of that fixes the segfault for the tes
that applying
the v2 of that fixes the segfault for the test case I posted.
Thanks for the report! You are a good dogfooder.
Thanks,
-Stolee
upload-pack: make reachable() more generic
>>> + commit-reach: move commit_contains from ref-filter
>>> + commit-reach: move ref_newer from remote.c
>>> + commit.h: remove method declarations
>>> + commit-reach: move walk methods from commit.c
>>>
>
ained a bunch of new tests to cover them, and then being
improved.
There's a segfault now in master when fetching because of 4fbcca4eff
("commit-reach: make can_all_from_reach... linear", 2018-07-20). I have
not had time to debug this, or found an easy isolated test case, but
this sc
ory reachability has been shuffled,
> obtained a bunch of new tests to cover them, and then being
> improved.
There's a segfault now in master when fetching because of 4fbcca4eff
("commit-reach: make can_all_from_reach... linear", 2018-07-20). I have
not had time to debug
This series documents and fixes a rerere segfault (dating back to
git-2.7.0) when a merge strategy makes the last entry in the index be
at stage 1.
Changes since last version:
- In my last submission I only had the code fix and no testcase; I
even commented in the commit message that the
Signed-off-by: Elijah Newren
---
t/t4200-rerere.sh | 29 +
1 file changed, 29 insertions(+)
diff --git a/t/t4200-rerere.sh b/t/t4200-rerere.sh
index 65da74c766..f9294b7677 100755
--- a/t/t4200-rerere.sh
+++ b/t/t4200-rerere.sh
@@ -577,4 +577,33 @@ test_expect_success
On Wed, Aug 29, 2018 at 05:46:21PM -0400, Jeff King wrote:
> > I think even with ASAN, you'd still need read_in_full() or an mmap()
> > wrapper that fiddles with the ASAN shadow, because mmap() always maps
> > whole pages:
> >
> > $ cat mmap-read-asan-blah.c
> > #include
> > #include
> > int ma
On Wed, Aug 29, 2018 at 11:40:41PM +0200, Jann Horn wrote:
> > If we want to detect this kind of thing in tests, we should probably be
> > relying on tools like ASan, which would cover all mmaps.
> >
> > It would be nice if there was a low-cost way to detect this in
> > production use, but it look
On Wed, Aug 29, 2018 at 11:34 PM Jeff King wrote:
>
> On Wed, Aug 29, 2018 at 10:58:56PM +0200, Jann Horn wrote:
>
> > This ensures that any attempts to access memory directly after the input
> > buffer or delta buffer in a delta test will cause a segmentation fault.
> >
> > Inspired by vsftpd.
>
On Wed, Aug 29, 2018 at 10:58:56PM +0200, Jann Horn wrote:
> This ensures that any attempts to access memory directly after the input
> buffer or delta buffer in a delta test will cause a segmentation fault.
>
> Inspired by vsftpd.
Neat trick, but it seems funny to protect this one buffer in
non
This ensures that any attempts to access memory directly after the input
buffer or delta buffer in a delta test will cause a segmentation fault.
Inspired by vsftpd.
Signed-off-by: Jann Horn
---
t/helper/test-delta.c | 78 +--
1 file changed, 53 insertions
On Mon, Aug 06, 2018 at 06:07:06PM +0200, SZEDER Gábor wrote:
> 'git ls-files' has the options '--exclude', '--exclude-from',
> '--exclude-per-directory', and '--exclude-standard', which all work
> fine. However, it also allows the negated version of all these four
> options, and they definitely
'git ls-files' has the options '--exclude', '--exclude-from',
'--exclude-per-directory', and '--exclude-standard', which all work
fine. However, it also allows the negated version of all these four
options, and they definitely don't work very well:
$ git ls-files --no-exclude
Segmentation fau
Jeff King writes:
> So I feel like the right answer here is probably this:
>
> diff --git a/wt-status.c b/wt-status.c
> index d1c05145a4..5fcaa3d0f8 100644
> --- a/wt-status.c
> +++ b/wt-status.c
> @@ -2340,7 +2340,16 @@ int has_uncommitted_changes(int ignore_submodules)
> if (ignore_submod
.8.0 (didn't test back
> further). I'm not familiar with the status / diff code, so I'm not sure
> where the assertion should be added.
>
> This came up in the wild due to a user with a corrupt repo (don't know
> how it got corrupt) trying "git pull" and seeing git segfault.
--
Duy
On Wed, Jul 11, 2018 at 01:00:57PM +0200, Ævar Arnfjörð Bjarmason wrote:
> This segfaults, but should print an error instead, have a repo with a
> corrupt HEAD:
>
> (
> rm -rf /tmp/git &&
> git clone --single-branch --branch todo g...@github.com:git/git.git
> /tmp/git &&
>
lloc = 0, objects = 0x0}
(gdb)
This has been an issue since at least v2.8.0 (didn't test back
further). I'm not familiar with the status / diff code, so I'm not sure
where the assertion should be added.
This came up in the wild due to a user with a corrupt repo (don't know
how it got corrupt) trying "git pull" and seeing git segfault.
Hi,
Elijah Newren wrote:
> Thanks for the detailed report. This apparently goes back to
> git-1.6.0 with commit 2122f8b963d4 ("rev-parse: Add support for the ^!
> and ^@ syntax", 2008-07-26). We aren't checking that the commit from
> lookup_commit_reference() is non-NULL before proceeding. Look
On Wed, May 23, 2018 at 12:52 PM, Todd Zullinger wrote:
> Hi,
>
> Certain invalid input causes git rev-parse to crash rather
> than return a 'fatal: ambiguous argument ...' error.
>
> This was reported against the Fedora git package:
>
> https://bugzilla.redhat.com/1581678
>
> Simple reproduct
Hi,
Certain invalid input causes git rev-parse to crash rather
than return a 'fatal: ambiguous argument ...' error.
This was reported against the Fedora git package:
https://bugzilla.redhat.com/1581678
Simple reproduction recipe and analysis, from the bug:
$ git init
Initialized em
Hi Peff,
On Fri, 18 May 2018, Jeff King wrote:
> I stumbled across a BUG() today. But interestingly, in the current tip
> of master it actually segfaults instead! This fixes the segfault (back
> into a BUG(), and then fixes the caller to avoid the BUG() in the first
> place).
I stumbled across a BUG() today. But interestingly, in the current tip
of master it actually segfaults instead! This fixes the segfault (back
into a BUG(), and then fixes the caller to avoid the BUG() in the first
place).
[1/2]: get_main_ref_store: BUG() when outside a repository
[2/2
romising.
>
> Thanks for confirming it works on other systems.
> Pull request and patch below:
>
> The following changes since commit 5be1f00a9a701532232f57958efab4be8c959a29:
>
> First batch after 2.16 (2018-01-23 13:21:10 -0800)
>
> are available in the Git repository a
other systems.
Pull request and patch below:
The following changes since commit 5be1f00a9a701532232f57958efab4be8c959a29:
First batch after 2.16 (2018-01-23 13:21:10 -0800)
are available in the Git repository at:
git://bogomips.org/git-svn.git svn-branch-segfault
On Wed, Jan 24, 2018 at 01:51:31PM -0300, Juan F. Codagnone wrote:
> > As for the patch itself, it looks correct but I saw two style nits:
>
> Thanks for the detailed review! I'm sorry about the style nits. I
> focused on the tabs and braces. Next time I will take additional
> attention.
No prob
If or files can't be opened, then mailinfo() returns an
error before it even initializes mi->p_hdr_data or mi->s_hdr_data.
When cmd_mailinfo() then calls clear_mailinfo(), we dereference the
NULL pointers trying to free their contents.
Signed-off-by: Juan F. Codagnone
Reviewed-by: Jeff King
--
On Wed, Jan 24, 2018 at 1:02 AM, Jeff King wrote:
>
> On Tue, Jan 23, 2018 at 11:54:17PM -0300, Juan F. Codagnone wrote:
...
>
>
> But given the lack of callers, it may not be worth the effort. So I'm OK
> with this solution. It may be worth giving an abbreviated version of the
> above explanation
On Tue, Jan 23, 2018 at 11:54:17PM -0300, Juan F. Codagnone wrote:
> If or files can't be opened, clear_mailinfo crash as
> it follows NULL pointers.
>
> Can be reproduced using `git mailinfo . .`
Thanks for finding this.
Looking at the offending code and your solution, it looks like:
1. m
If or files can't be opened, clear_mailinfo crash as
it follows NULL pointers.
Can be reproduced using `git mailinfo . .`
Signed-off-by: Juan F. Codagnone
---
mailinfo.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/mailinfo.c b/mailinfo.c
index a89db22ab..035
In 7c117184d7 ("bisect: fix off-by-one error in
`best_bisection_sorted()`", 2017-11-05) the more careful logic dealing
with freeing p->next in 50e62a8e70 ("rev-list: implement
--bisect-all", 2007-10-22) was removed.
Restore the more careful check to avoid segfaulting. Ideally this
would come with
I made:
$git stash
$git checkout
$git stash pop - crash here. changes were applied, but index.lock was
not removed.
The issue appeared only once, I haven't seen it before and cannot
reproduce it now.
Thanks, updated git to 2.15.1.
2017-12-31 10:59 GMT+02:00 Eric Sunshine :
> On Fri, Dec 29, 201
On Fri, Dec 29, 2017 at 4:04 AM, Andrew Tsykhonya
wrote:
> git stash pop resulted in crash:
> /usr/local/Cellar/git/2.10.2/libexec/git-core/git-stash: line 470:
> 14946 Segmentation fault: 11 git merge-recursive $b_tree -- $c_tree
> $w_tree
> although, the changes have been applied successfully.
git stash pop resulted in crash:
/usr/local/Cellar/git/2.10.2/libexec/git-core/git-stash: line 470:
14946 Segmentation fault: 11 git merge-recursive $b_tree -- $c_tree
$w_tree
although, the changes have been applied successfully.
Fix a bug in the compilation of PCRE2 patterns under JIT (the most
common runtime configuration). Any pattern with a (*NO_JIT) verb would
segfault in any currently released PCRE2 version:
$ git grep -P '(*NO_JIT)hi.*there'
Segmentation fault
That this segfaulted was a bug in PC
On Wed, Nov 22 2017, Eric Sunshine jotted:
> On Wed, Nov 22, 2017 at 8:36 AM, Ævar Arnfjörð Bjarmason
> wrote:
>> Fix a bug in the compilation of PCRE2 patterns under JIT (the most
>> common runtime configuration), any pattern with a (*NO_JIT) verb would
>> segfault. T
ith 0. If we
> + * then proceed to call pcre2_jit_match() further down
> + * the line instead of pcre2_match() we'll segfault.
> + */
> + patinforet = pcre2_pattern_info(p->pcre2_pattern,
> PCRE2_INFO_JITSIZE, &jits
On Wed, Nov 22, 2017 at 8:36 AM, Ævar Arnfjörð Bjarmason
wrote:
> Fix a bug in the compilation of PCRE2 patterns under JIT (the most
> common runtime configuration), any pattern with a (*NO_JIT) verb would
> segfault. This bug dates back to my 94da9193a6 ("grep: add support for
&g
Fix a bug in the compilation of PCRE2 patterns under JIT (the most
common runtime configuration), any pattern with a (*NO_JIT) verb would
segfault. This bug dates back to my 94da9193a6 ("grep: add support for
PCRE v2", 2017-06-01):
$ git grep -P '(*NO_JIT)hi.*there'
Se
setup_git_env() must be called before this function to initialize
git_common_dir so that it returns a non NULL string. And it must return
a non NULL string or segfault can happen because all callers expect so.
It does not do so explicitly though and depends on get_git_dir() being
called first
On Sat, Apr 8, 2017 at 2:29 AM, Brandon Williams wrote:
> In 'clear_pathspec()' the incorrect index parameter is used to bound an
> inner-loop which is used to free a 'struct attr_match' value field.
> Using the incorrect index parameter (in addition to being incorrect)
> occasionally causes segme
On Fri, Apr 7, 2017 at 12:29 PM, Brandon Williams wrote:
> In 'clear_pathspec()' the incorrect index parameter is used to bound an
> inner-loop which is used to free a 'struct attr_match' value field.
> Using the incorrect index parameter (in addition to being incorrect)
> occasionally causes segm
In 'clear_pathspec()' the incorrect index parameter is used to bound an
inner-loop which is used to free a 'struct attr_match' value field.
Using the incorrect index parameter (in addition to being incorrect)
occasionally causes segmentation faults when attempting to free an
invalid pointer. Fix t
8676
> > This command worked (return status is 0 and no error message).
> >
> > However following `git add **.hpp` and `git status` segfault with no
> > additional message:
> > $ git status
> > Segmentation fault
>
> I think this is the
cpp
> Which is quite a big amount of files (partly because of external
> dependencies which would have been smart to exclude, but it's done).
> $ find -type f -name "**.cpp" | wc -l
> 8676
> This command worked (return status is 0 and no error message).
>
> How
.cpp
Which is quite a big amount of files (partly because of external
dependencies which would have been smart to exclude, but it's
done).
$ find -type f -name "**.cpp" | wc -l
8676
This command worked (return status is 0 and no error message).
However following `git add **.hpp` and
setup_git_env() must be called before this function to initialize
git_common_dir so that it returns a non NULL string. And it must return
a non NULL string or segfault can happen because all callers expect so.
It does not do so explicitly though and depends on get_git_dir() being
called first
Hi Gábor,
On Sat, 18 Mar 2017, SZEDER Gábor wrote:
> 'git {log,diff,...} -S<...> --pickaxe-regex' can segfault as a result of
> out-of-bounds memory reads.
>
> diffcore-pickaxe.c:contains() looks for all matches of the given regex
> in a buffer in a loop, advancin
On Sun, Mar 19, 2017 at 12:54 AM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> setup_git_env() must be called before this function to initialize
>> git_common_dir so that it returns a non NULL string. And it must return
>> a non NULL string or segfaul
Junio C Hamano writes:
> Interestingly, the new test fails (with the patch) under prove but
> not when run from the shell (i.e. "cd t && sh t4062-diff-pickaxe.sh").
Sorry, false alarm.
Interestingly, the new test fails (with the patch) under prove but
not when run from the shell (i.e. "cd t && sh t4062-diff-pickaxe.sh").
'git {log,diff,...} -S<...> --pickaxe-regex' can segfault as a result
of out-of-bounds memory reads.
diffcore-pickaxe.c:contains() looks for all matches of the given regex
in a buffer in a loop, advancing the buffer pointer to the end of the
last match in each iteration. Whe
Nguyễn Thái Ngọc Duy writes:
> setup_git_env() must be called before this function to initialize
> git_common_dir so that it returns a non NULL string. And it must return
> a non NULL string or segfault can happen because all callers expect so.
>
> Normally if somebody has cal
xpect_success '-G matches' '
> test 4096-zeroes.txt = "$(cat out)"
> '
>
> +test_expect_success '-S --pickaxe-regex' '
> + git diff --name-only -S0 --pickaxe-regex HEAD^ >out &&
> + verbose test 4096-zeroes.txt = "$(cat out)"
> +'
> +
> test_done
Hang on, this new test does fail because of a segfault _with_ the fix
on Travis 64bit Linux and OSX builds.
Oh, well.
'git {log,diff,...} -S<...> --pickaxe-regex' can segfault as a result
of out-of-bounds memory reads.
diffcore-pickaxe.c:contains() looks for all matches of the given regex
in a buffer in a loop, advancing the buffer pointer to the end of the
last match in each iteration. Whe
setup_git_env() must be called before this function to initialize
git_common_dir so that it returns a non NULL string. And it must return
a non NULL string or segfault can happen because all callers expect so.
Normally if somebody has called get_git_dir(), or set_git_dir() then
setup_git_env() is
On 03/17, Jeff King wrote:
> Callers of the run-command API may mark a child as
> "clean_on_exit"; it gets added to a list and killed when the
> main process dies. Since commit 46df6906f
> (execv_dashed_external: wait for child on signal death,
> 2017-01-06), we respect an extra "wait_after_clean"
Jeff King wrote:
> Reported-by: Brandon Williams
> Signed-off-by: Jeff King
Reviewed-by: Jonathan Nieder
Thanks.
Callers of the run-command API may mark a child as
"clean_on_exit"; it gets added to a list and killed when the
main process dies. Since commit 46df6906f
(execv_dashed_external: wait for child on signal death,
2017-01-06), we respect an extra "wait_after_clean" flag,
which we expect to find in the
1 - 100 of 350 matches
Mail list logo
