From: Alexandre Julliard <julliard@winehq.org>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Shawn Pearce <spearce@spearce.org>,
Junio C Hamano <junkio@cox.net>,
git@vger.kernel.org
Subject: Re: Segfault in xdl_merge is back
Date: Wed, 27 Dec 2006 13:53:57 +0100 [thread overview]
Message-ID: <87fyb11ouy.fsf@wine.dyndns.org> (raw)
In-Reply-To: <Pine.LNX.4.63.0612271214120.19693@wbgn013.biozentrum.uni-wuerzburg.de> (Johannes Schindelin's message of "Wed\, 27 Dec 2006 12\:22\:01 +0100 \(CET\)")
[-- Attachment #1: Type: text/plain, Size: 5127 bytes --]
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> As you said in another mail, Junio suggested using git-merge-file on the
> blobs themselves. This is a little tricky, since git-merge-file does not
> read blobs; only files. I'd do this:
>
> - in merge-recursive.c just before line 658 I'd add an
> fprintf(stderr, "xdl_merge: %s %s %s\n", sha1_to_hex(a->sha1),
> sha1_to_hex(o->sha1), sha1_to_hex(b->sha1));
> - run the merge until it segfaults
> - get the blobs by using the last three SHA1's in the output by
> $ git-show <sha1> > a # or "o" or "b"
> - $ git merge-file -p a o b >/dev/null
>
> This command line ensures that "a" is not edited, and you can repeat the
> merge as often as needed.
I'm seeing the problem here on Linux, I have attached a tarball with
a set of files from Wine that trigger the bug.
The gdb backtrace looks like this:
Core was generated by `git-merge-file -p a o b'.
Program terminated with signal 11, Segmentation fault.
#0 0x080b60be in xdl_refine_conflicts (xe1=0xbfcaf22c, xe2=0xbfcaf1a4, m=0x8106668, xpp=0xbfcaf348) at xdiff/xmerge.c:197
197 t1.ptr = (char *)xe1->xdf2.recs[m->i1]->ptr;
(gdb) bt
#0 0x080b60be in xdl_refine_conflicts (xe1=0xbfcaf22c, xe2=0xbfcaf1a4, m=0x8106668, xpp=0xbfcaf348) at xdiff/xmerge.c:197
#1 0x080b6843 in xdl_do_merge (xe1=0xbfcaf22c, xscr1=0x0, name1=0xbfcafbcf "a", xe2=0xbfcaf1a4, xscr2=0x0, name2=0xbfcafbd3 "b", level=2, xpp=0xbfcaf348, result=0xbfcaf34c) at xdiff/xmerge.c:351
#2 0x080b6b8c in xdl_merge (orig=0xbfcaf35c, mf1=0xbfcaf354, name1=0xbfcafbcf "a", mf2=0xbfcaf364, name2=0xbfcafbd3 "b", xpp=0xbfcaf348, level=2, result=0xbfcaf34c) at xdiff/xmerge.c:408
#3 0x08067887 in cmd_merge_file (argc=4, argv=0xbfcaf4b8, envp=0x0) at builtin-merge-file.c:43
#4 0x0804b0e5 in handle_internal_command (argc=5, argv=0xbfcaf4b4, envp=0xbfcaf4cc) at git.c:294
#5 0x0804b1e7 in main (argc=5, argv=0xbfcaf4b4, envp=0xbfcaf4cc) at git.c:331
(gdb) p *xe1
$1 = {xdf1 = {rcha = {head = 0x8105ca8, tail = 0x8107558, isize = 16, nsize = 1056, ancur = 0x8107558, sncur = 0x0, scurr = 0}, nrec = 259, hbits = 9, rhash = 0x81054a0, dstart = 36, dend = 257,
recs = 0x8105080, rchg = 0x80ff009 "", rindex = 0x8107988, nreff = 18, ha = 0x8107da0}, xdf2 = {rcha = {head = 0x8108370, tail = 0x81085b0, isize = 16, nsize = 176, ancur = 0x81085b0, sncur = 0x0,
scurr = 0}, nrec = 41, hbits = 6, rhash = 0x8108268, dstart = 36, dend = 39, recs = 0x81081b8, rchg = 0x80ff119 "", rindex = 0x8108670, nreff = 3, ha = 0x8108720}}
(gdb) p *xe2
$2 = {xdf1 = {rcha = {head = 0x81060d8, tail = 0x810aad0, isize = 16, nsize = 1056, ancur = 0x810aad0, sncur = 0x0, scurr = 0}, nrec = 259, hbits = 9, rhash = 0x8104878, dstart = 44, dend = 43,
recs = 0x8106b18, rchg = 0x8106509 "", rindex = 0x810b998, nreff = 0, ha = 0x810bdb0}, xdf2 = {rcha = {head = 0x810ce20, tail = 0x810db40, isize = 16, nsize = 1104, ancur = 0x810db40, sncur = 0x0,
scurr = 0}, nrec = 270, hbits = 9, rhash = 0x810c618, dstart = 44, dend = 54, recs = 0x810c1c8, rchg = 0x8106f39 "", rindex = 0x810dfa0, nreff = 8, ha = 0x810e3e0}}
(gdb) p *m
$3 = {next = 0x0, mode = 0, i1 = 41, i2 = 41, chg1 = 0, chg2 = 229}
And here's the Valgrind output:
==32758== Memcheck, a memory error detector.
==32758== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
==32758== Using LibVEX rev 1658, a library for dynamic binary translation.
==32758== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==32758== Using valgrind-3.2.1-Debian, a dynamic binary instrumentation framework.
==32758== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
==32758== For more details, rerun with: -v
==32758==
==32758== Use of uninitialised value of size 4
==32758== at 0x80B60BE: xdl_refine_conflicts (xmerge.c:197)
==32758== by 0x80B6842: xdl_do_merge (xmerge.c:351)
==32758== by 0x80B6B8B: xdl_merge (xmerge.c:408)
==32758== by 0x8067886: cmd_merge_file (builtin-merge-file.c:43)
==32758== by 0x804B0E4: handle_internal_command (git.c:294)
==32758== by 0x804B1E6: main (git.c:331)
==32758==
==32758== Invalid read of size 4
==32758== at 0x80B60BE: xdl_refine_conflicts (xmerge.c:197)
==32758== by 0x80B6842: xdl_do_merge (xmerge.c:351)
==32758== by 0x80B6B8B: xdl_merge (xmerge.c:408)
==32758== by 0x8067886: cmd_merge_file (builtin-merge-file.c:43)
==32758== by 0x804B0E4: handle_internal_command (git.c:294)
==32758== by 0x804B1E6: main (git.c:331)
==32758== Address 0x4 is not stack'd, malloc'd or (recently) free'd
==32758==
==32758== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==32758== Access not within mapped region at address 0x4
==32758== at 0x80B60BE: xdl_refine_conflicts (xmerge.c:197)
==32758== by 0x80B6842: xdl_do_merge (xmerge.c:351)
==32758== by 0x80B6B8B: xdl_merge (xmerge.c:408)
==32758== by 0x8067886: cmd_merge_file (builtin-merge-file.c:43)
==32758== by 0x804B0E4: handle_internal_command (git.c:294)
==32758== by 0x804B1E6: main (git.c:331)
Hope this helps,
--
Alexandre Julliard
julliard@winehq.org
[-- Attachment #2: merge-file-segfault.tar.gz --]
[-- Type: application/octet-stream, Size: 2785 bytes --]
next prev parent reply other threads:[~2006-12-27 12:55 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-27 4:16 Segfault in xdl_merge is back Shawn Pearce
2006-12-27 6:49 ` Linus Torvalds
2006-12-27 8:24 ` Shawn Pearce
2006-12-27 11:22 ` Johannes Schindelin
2006-12-27 12:53 ` Alexandre Julliard [this message]
2006-12-28 16:13 ` [PATCH] xdl_merge(): fix a segmentation fault when refining conflicts Johannes Schindelin
2006-12-28 22:09 ` Junio C Hamano
2006-12-29 4:16 ` Shawn Pearce
2006-12-30 18:53 ` Johannes Schindelin
2006-12-30 19:47 ` Jakub Narebski
2006-12-31 1:09 ` Johannes Schindelin
2007-01-02 13:18 ` Jakub Narebski
2007-01-02 20:58 ` Johannes Schindelin
2007-01-02 21:11 ` Junio C Hamano
2007-01-02 21:17 ` Johannes Schindelin
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=87fyb11ouy.fsf@wine.dyndns.org \
--to=julliard@winehq.org \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=junkio@cox.net \
--cc=spearce@spearce.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).