git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 --]

  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).