threads / discuss / 43629
Subject: Re: git-merge-recursive segmentation error
Junio C HamanoLuben Tuikov <ltuikov@yahoo.com> writes:
> I also ran git-bisect twice over two well known but overlapping > good-bad regions and I get the same commit as being the culprit. > It seems to be commit 1510fea781cb0517eeba8c378964f7bc4f9577ab. > > Luben
Ooooooops.
Junio C HamanoJunio C Hamano <junkio@cox.net> writes:
> Luben Tuikov <ltuikov@yahoo.com> writes: > >> I also ran git-bisect twice over two well known but overlapping >> good-bad regions and I get the same commit as being the culprit. >> It seems to be commit 1510fea781cb0517eeba8c378964f7bc4f9577ab. >> >> Luben > > Ooooooops.
1510fe is buggy and it is my fault.
For now, this _should_ get you keep going.
However, if this fixes it for you, that means we would still have the problem on Cygwin X-<.
-- >8 -- [PATCH] fix populate-filespec
I hand munged the original patch when committing 1510fea78.
Signed-off-by: Junio C Hamano <junkio@cox.net> --- diff.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/diff.c b/diff.c index 9974435..6e6f2a7 100644 --- a/diff.c +++ b/diff.c @@ -1223,7 +1223,7 @@ static int reuse_worktree_file(const char *name, const unsigned char *sha1, int * objects however would tend to be slower as they need * to be individually opened and inflated. */ - if (FAST_WORKING_DIRECTORY && !want_file && has_sha1_pack(sha1, NULL)) + if (!FAST_WORKING_DIRECTORY && !want_file && has_sha1_pack(sha1, NULL)) return 0; len = strlen(name);
-- 1.4.4.2.g205bf
Johannes SchindelinHi,
On Tue, 19 Dec 2006, Junio C Hamano wrote:
> Junio C Hamano <junkio@cox.net> writes: > > > Luben Tuikov <ltuikov@yahoo.com> writes: > > > >> I also ran git-bisect twice over two well known but overlapping > >> good-bad regions and I get the same commit as being the culprit. > >> It seems to be commit 1510fea781cb0517eeba8c378964f7bc4f9577ab. > >> > >> Luben > > > > Ooooooops. > > 1510fe is buggy and it is my fault.
You hand munging should not have led to any segmentation fault. It would be sooo nice to have the test case.
Ciao,
--- Junio C Hamano <junkio@cox.net> wrote:
> Junio C Hamano <junkio@cox.net> writes: > > > Luben Tuikov <ltuikov@yahoo.com> writes: > > > >> I also ran git-bisect twice over two well known but overlapping > >> good-bad regions and I get the same commit as being the culprit. > >> It seems to be commit 1510fea781cb0517eeba8c378964f7bc4f9577ab. > >> > >> Luben > > > > Ooooooops. > > 1510fe is buggy and it is my fault. > > For now, this _should_ get you keep going. > > However, if this fixes it for you, that means we would still > have the problem on Cygwin X-<.
Yep -- that fixed it.
Thanks,
Luben> > -- >8 -- > [PATCH] fix populate-filespec > > I hand munged the original patch when committing 1510fea78. > > Signed-off-by: Junio C Hamano <junkio@cox.net> > --- > diff.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/diff.c b/diff.c > index 9974435..6e6f2a7 100644 > --- a/diff.c > +++ b/diff.c > @@ -1223,7 +1223,7 @@ static int reuse_worktree_file(const char *name, const unsigned char > *sha1, int > * objects however would tend to be slower as they need > * to be individually opened and inflated. > */ > - if (FAST_WORKING_DIRECTORY && !want_file && has_sha1_pack(sha1, NULL)) > + if (!FAST_WORKING_DIRECTORY && !want_file && has_sha1_pack(sha1, NULL)) > return 0; > > len = strlen(name); > -- > 1.4.4.2.g205bf > > >
Shawn PearceLuben Tuikov <ltuikov@yahoo.com> wrote:
> > Junio C Hamano <junkio@cox.net> writes: > > 1510fe is buggy and it is my fault. > > > > For now, this _should_ get you keep going. > > > > However, if this fixes it for you, that means we would still > > have the problem on Cygwin X-<. > > Yep -- that fixed it.
It might be a problem on Cygwin. :-)
I completely fail to see how this patch would cause a segfault downstream in xdl_merge. All this controls is do we mmap data from the working directory or decompress it from the ODB. Either way we should have loaded the file size or content into the diff_filespec.
My other related change (7da41f48c) in this area has a better chance of causing a problem as it may be bypassing loading the file content into the diff_filespec where before we were always loading it. However none of my testing ever showed that would cause a problem.
Junio C HamanoShawn Pearce <spearce@spearce.org> writes:
> I completely fail to see how this patch would cause a segfault > downstream in xdl_merge. All this controls is do we mmap data from > the working directory or decompress it from the ODB. Either way we > should have loaded the file size or content into the diff_filespec.
Me neither. Quite puzzled...