From: Christian Couder <christian.couder@gmail.com>
To: Bruce Korb <bruce.korb@gmail.com>
Cc: GIT Development <git@vger.kernel.org>
Subject: Re: seg fault in "git format-patch"
Date: Mon, 1 Jun 2015 15:44:02 +0200 [thread overview]
Message-ID: <CAP8UFD2KYSCMG7p22J78U8yVy49380PCxiXuvartXZdTGm1JFQ@mail.gmail.com> (raw)
In-Reply-To: <CAP8UFD1phg8E0JCgkz88CMUo9H-W=s5JDuKeCMOkf1=UYBJt+g@mail.gmail.com>
On Mon, Jun 1, 2015 at 2:01 AM, Christian Couder
<christian.couder@gmail.com> wrote:
> On Mon, Jun 1, 2015 at 1:53 AM, Christian Couder
> <christian.couder@gmail.com> wrote:
>> On Mon, Jun 1, 2015 at 1:14 AM, Christian Couder
>> <christian.couder@gmail.com> wrote:
>>> On Sun, May 31, 2015 at 10:45 PM, Bruce Korb <bruce.korb@gmail.com> wrote:
>>>> Oh, you can also clone the gnu-pw-mgr and likely get the same result:
>>>
>>> Yeah, after cloning from http://git.savannah.gnu.org/r/gnu-pw-mgr.git
>>> I get the following backtrace:
>>>
>>> Program received signal SIGSEGV, Segmentation fault.
>>> 0x00000000004b26b1 in clear_commit_marks_1 (plist=0x7fffffffbf78,
>>> commit=0x84e8d0, mark=139) at commit.c:528
>>> 528 while ((parents = parents->next))
>>> (gdb) bt
>>> #0 0x00000000004b26b1 in clear_commit_marks_1 (plist=0x7fffffffbf78,
>>> commit=0x84e8d0, mark=139) at commit.c:528
>>> #1 0x00000000004b2743 in clear_commit_marks_many (nr=-1,
>>> commit=0x7fffffffbfa0, mark=139) at commit.c:544
>>> #2 0x00000000004b2771 in clear_commit_marks (commit=0x84e8d0,
>>> mark=139) at commit.c:549
>>> #3 0x00000000004537cc in get_patch_ids (rev=0x7fffffffd190,
>>> ids=0x7fffffffc910) at builtin/log.c:832
>>> #4 0x0000000000455580 in cmd_format_patch (argc=1,
>>> argv=0x7fffffffdc20, prefix=0x0) at builtin/log.c:1425
>>> #5 0x0000000000405807 in run_builtin (p=0x80cac8 <commands+840>,
>>> argc=5, argv=0x7fffffffdc20) at git.c:350
>>> #6 0x0000000000405a15 in handle_builtin (argc=5, argv=0x7fffffffdc20)
>>> at git.c:532
>>> #7 0x0000000000405b31 in run_argv (argcp=0x7fffffffdafc,
>>> argv=0x7fffffffdb10) at git.c:578
>>> #8 0x0000000000405d29 in main (argc=5, av=0x7fffffffdc18) at git.c:686
>>>
>>> (Please don't top post if you reply to this email as it is frown upon
>>> on this list.)
>>
>> When running the command that gives the above segfault:
>>
>> $ git format-patch -o patches --ignore-if-in-upstream
>> 14949fa8f39d29e44b43f4332ffaf35f11546502..2de9eef391259dfc8748dbaf76a5d55427f37b0d
>>
>> It is interesting to note that the last sha1 refers to a tag:
>>
>> $ git cat-file tag 2de9eef391259dfc8748dbaf76a5d55427f37b0d
>> object 524ccbdbe319068ab18a3950119b9e9a5d135783
>> type commit
>> tag v1.4
>> tagger Bruce Korb <bkorb@gnu.org> 1428847577 -0700
>>
>> Release 1.4
>>
>> * sort-pw-cfg: a sort/merge program for combining and organizing
>> configurations.
>>
>> * --delete: a new option to remove any entries for a password id
>>
>> It works when the tag is replaced by the commit it points to, and the
>> segfault happens because the we try to access the "parents" field of
>> the tag object as if it was a commit.
>
> Yeah, in builtin/log.c we are doing:
>
> o2 = rev->pending.objects[1].item;
>
> and then we are casting the object into a commit when passing it to
> clear_commit_marks():
>
> clear_commit_marks((struct commit *)o2,
> SEEN | UNINTERESTING | SHOWN | ADDED);
>
> but I don't know where we should have peeled the tag to get a commit,
> and it's late here so I will leave it someone else to find a fix.
The following seems to fix it, but I am not sure it is the right fix:
diff --git a/builtin/log.c b/builtin/log.c
index dd8f3fc..0ab9360 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -792,6 +792,16 @@ static int reopen_stdout(struct commit *commit,
const char *subject,
return 0;
}
+static void clear_object_marks(struct object *obj)
+{
+ struct commit *c = (struct commit *)peel_to_type(NULL, 0, obj,
+ OBJ_COMMIT);
+ if (!c)
+ die(_("could not convert %s into a commit"),
+ sha1_to_hex(obj->sha1));
+ clear_commit_marks(c, SEEN | UNINTERESTING | SHOWN | ADDED);
+}
+
static void get_patch_ids(struct rev_info *rev, struct patch_ids *ids)
{
struct rev_info check_rev;
@@ -827,10 +837,8 @@ static void get_patch_ids(struct rev_info *rev,
struct patch_ids *ids)
}
/* reset for next revision walk */
- clear_commit_marks((struct commit *)o1,
- SEEN | UNINTERESTING | SHOWN | ADDED);
- clear_commit_marks((struct commit *)o2,
- SEEN | UNINTERESTING | SHOWN | ADDED);
+ clear_object_marks(o1);
+ clear_object_marks(o2);
o1->flags = flags1;
o2->flags = flags2;
}
next prev parent reply other threads:[~2015-06-01 13:44 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-31 19:13 seg fault in "git format-patch" Bruce Korb
2015-05-31 20:26 ` Christian Couder
2015-05-31 20:41 ` Bruce Korb
2015-05-31 20:45 ` Bruce Korb
2015-05-31 23:14 ` Christian Couder
2015-05-31 23:53 ` Christian Couder
2015-06-01 0:01 ` Christian Couder
2015-06-01 1:03 ` [PATCH] format-patch: dereference tags with --ignore-if-in-upstream brian m. carlson
2015-06-01 10:20 ` Jeff King
2015-06-01 11:22 ` brian m. carlson
2015-06-01 11:47 ` Jeff King
2015-06-01 14:56 ` Junio C Hamano
2015-06-01 17:44 ` Junio C Hamano
2015-06-01 17:47 ` Jeff King
2015-06-01 20:35 ` Junio C Hamano
2015-06-01 22:34 ` brian m. carlson
2015-06-01 22:46 ` Junio C Hamano
2015-06-01 17:58 ` Junio C Hamano
2015-06-01 13:44 ` Christian Couder [this message]
2015-06-01 14:17 ` seg fault in "git format-patch" Christian Couder
2015-06-01 14:47 ` Bruce Korb
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=CAP8UFD2KYSCMG7p22J78U8yVy49380PCxiXuvartXZdTGm1JFQ@mail.gmail.com \
--to=christian.couder@gmail.com \
--cc=bruce.korb@gmail.com \
--cc=git@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).