threads / discuss / 39140

utf-8 filename woes

Subject: utf-8 filename woes

## tl;dr

2 messages between Apr 22, 2015 and Apr 22, 2015.

replies: 1people: 2as markdown or json

Jeremy Harris· Apr 22, 2015, 19:50 UTC · lore
Hi,
  I have a git version 1.7.1 running on Scientific Linux 6.
When a filename with UTF-8 is present in a tree-ish the
"git archive" command crashes:
------------%%----------------
*** buffer overflow detected ***: git terminated
======= Backtrace: =========
/lib64/libc.so.6(__fortify_fail+0x37)[0x32c1502527]
/lib64/libc.so.6[0x32c1500410]
/lib64/libc.so.6[0x32c14ff869]
/lib64/libc.so.6(_IO_default_xsputn+0xc9)[0x32c1474639]
/lib64/libc.so.6(_IO_vfprintf+0x11d8)[0x32c14451a8]
/lib64/libc.so.6(__vsprintf_chk+0x9d)[0x32c14ff90d]
/lib64/libc.so.6(__sprintf_chk+0x7f)[0x32c14ff84f]
git[0x4620bc]
git[0x4616bc]
git[0x4bd832]
git[0x4bda79]
git[0x4bda79]
git[0x4613e1]
git[0x4623ed]
git[0x4612ed]
git[0x40caf3]
git[0x4041a1]
git[0x404382]
/lib64/libc.so.6(__libc_start_main+0xfd)[0x32c141ed5d]
git[0x403ba9]
======= Memory map: ========
00400000-00510000 r-xp 00000000 fd:00 4121
 /usr/bin/git
------------%%----------------

Installing the git-debuginfo package gave no additional information. The symptom does not show on a Fedora 21 system with git 2.1.0 (and I note that gitk properly shows those filenames on f21, and does not on sl6).

Is this a known and fixed issue, or something my sl6 system needs installing?

-- 
Thanks,
  Jeremy
Jeff King· Apr 22, 2015, 20:19 UTC · re: Jeremy Harris · lore

Re: utf-8 filename woes

On Wed, Apr 22, 2015 at 08:50:26PM +0100, Jeremy Harris wrote:
Show 7 quoted lines
> Installing the git-debuginfo package gave no additional
> information.   The symptom does not show on a Fedora 21
> system with git 2.1.0 (and I note that gitk properly
> shows those filenames on f21, and does not on sl6).
> 
> Is this a known and fixed issue, or something my sl6
> system needs installing?

I'm not sure. v1.7.1 is 5 years old, and there have been a lot of fixes since then. I couldn't replicate your problem on v1.7.1 with a trivial test. If you can reproduce it at will and you really want to know where the fix is, you can try "reverse-bisecting":

  git clone git://git.kernel.org/pub/scm/git/git.git
  cd git
  git bisect start
  git checkout v1.7.1
  make
  [confirm that it shows the breakage]
  git bisect good
  git checkout v2.1.0
  make
  [confirm that it does not show the problem]
  git bisect bad
  ... follow the instructions, testing teach ...

Note that "good" and "bad" here are reversed of what you might expect. "bisect" was designed for finding regressions, not fixes, and you have to manually flip the two.

-Peff

← back to recent threads