Re: seg fault in "git format-patch"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Jun 1, 2015 at 1:53 AM, Christian Couder
<christian.couder@xxxxxxxxx> wrote:
> On Mon, Jun 1, 2015 at 1:14 AM, Christian Couder
> <christian.couder@xxxxxxxxx> wrote:
>> On Sun, May 31, 2015 at 10:45 PM, Bruce Korb <bruce.korb@xxxxxxxxx> 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@xxxxxxx> 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.

Best,
Christian.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]