From: Tim Olsen <tim@brooklynpenguin.com>
To: git@vger.kernel.org
Cc: Junio C Hamano <gitster@pobox.com>,
git@vger.kernel.org,
Johannes Schindelin <johannes.schindelin@gmx.de>
Subject: Re: git-merge segfault in 1.6.6 and master
Date: Thu, 21 Jan 2010 16:56:33 -0500 [thread overview]
Message-ID: <4B58CD91.5000903@brooklynpenguin.com> (raw)
In-Reply-To: <20100121140057.GP12429@genesis.frugalware.org>
Miklos Vajna wrote:
> Two ideas to help debugging:
>
> - Can you try if this happens in a new repo as well? (If not, is the
> repo public?) If yes, can you write a script that shows your problem?
The problem still happens in any clone of the repository, but I have not
attempted to reproduce the problem in a fresh repository. I've put our
repository up at git://les.limebits.net/site (warning: the repo is about
364MB). The following 3 commands will reproduce the problem:
git clone git://les.limebits.net/site
cd site
git merge origin/deployed
The problem starts with commit 9079b71b6f. I can merge its ancestors
with no problem into the default branch (build-dav-sync-05). But commit
9079b71b6f and its descendents cause a segfault when merging into
build-dav-sync-05.
> - Can you see if this happens with v1.6.0? If yes, can you bisect it?
With 1.6.0, the merge still fails but it doesn't outright segfault.
$ git merge origin/deployed
Merge with strategy recursive failed.
$
The output appears to be from line 1098 of builtin-merge.c. Bisecting
finds that the outright segfaulting starts with commit 18668f53:
tolsen@neurofunk:~/git/git [git:NO BRANCH*]$ git bisect good
18668f5319b079cce29e19817bc352b1413e0908 is first bad commit
commit 18668f5319b079cce29e19817bc352b1413e0908
Author: Miklos Vajna <vmiklos@frugalware.org>
Date: Thu Aug 28 15:43:00 2008 +0200
builtin-merge: avoid run_command_v_opt() for recursive and subtree
The try_merge_strategy() function always ran the strategy in a separate
process, though this is not always necessary. The recursive and subtree
strategy can be called without a fork(). This patch adds a check, and
calls recursive in the same process without wasting resources.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
:100644 100644 9ad9791068c9330f28413ac67315246989c8d96d
b857cf6246978846e0c19895fd6f66266cf6a6f4 M builtin-merge.c
tolsen@neurofunk:~/git/git [git:NO BRANCH*]$
This leads me to believe the segfault may still be occurring in v1.6.0,
but in a separate process.
Tim
>
> Thanks.
prev parent reply other threads:[~2010-01-21 21:57 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-20 16:17 git-merge segfault in 1.6.6 and master Tim Olsen
2010-01-20 19:13 ` Junio C Hamano
2010-01-20 21:57 ` Tim Olsen
2010-01-20 22:21 ` Junio C Hamano
2010-01-21 16:37 ` Tim Olsen
2010-01-21 18:12 ` Junio C Hamano
2010-01-22 0:21 ` Junio C Hamano
2010-01-22 0:38 ` Junio C Hamano
2010-01-21 14:00 ` Miklos Vajna
2010-01-21 21:56 ` Tim Olsen [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4B58CD91.5000903@brooklynpenguin.com \
--to=tim@brooklynpenguin.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=johannes.schindelin@gmx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.