Reproducible, corrupt packfile after fresh

I'm a heavy user of git-svn and experience an issue with one specific (git-svn) repository: 'git fsck' reports a corrupt packfile after every checkout.

Now I'm totally puzzled about the cause and what do about it. This is what I do:

    git svn init -s http://svn.foo.com/myproject myproject.git
    cd myproject.git
    git svn fetch         # Much more reliable than 'git-svn clone'

This checks out ~2100 commits and executes 2 git-gc during checkout. The final .git repo size is about 940MB. Then I run

    git fsck

➜ myproject.git git:(master) git fsck
Checking object directories: 100% (256/256), done.
error: packed 0f5f33639bfc1a781fe080c31a1f076d9a25c1d3 from
.git/objects/pack/pack-6a6f5355584a5d71215d5fc867ce09602ceab533.pack is
corrupt
*** glibc detected *** git: free(): invalid pointer: 0x00007f46a09e9010 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x7eb96)[0x7f46d9ebab96]
git[0x4ddf46]
git[0x4b4123]
git[0x431524]
git[0x405ce8]
git[0x4050e2]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)[0x7f46d9e5d76d]
git[0x405529]
======= Memory map: ========
00400000-0055f000 r-xp 00000000 fc:01 12452043
 /usr/bin/git
0075e000-0075f000 r--p 0015e000 fc:01 12452043
 /usr/bin/git

....

This only affects this very particular git-svn repo (and I have dozens of them). The error happens reproducible on every fresh checkout as described above. The backtrace does not appear always. The object is a very large blob

    git show 0f5f33639bfc1a781fe080c31a1f076d9a25c1d3 | wc -c
    39524691

Any hints what to do?

Thanks
- Ben

gitml.jexpert@recursor.net writes:

[...]

Regardless of any possible fault in git-svn, there's an obvious bug here with git-fsck. Can you share the pack (if the project is public) or compile a git-fsck without optimization and with debugging, and run it under valgrind, to hopefully get us a backtrace of where the memory management goes off the rails?

Unfortunately I'm unable to share the pack.

As Java Developer I'm note very savy, but I'd try. Do you have me any pointers on ".. without optimization and with debugging" and "run it under valgrind"?

Currently I used
   deb http://ppa.launchpad.net/git-core/ppa/ubuntu quantal main
as source.

gitml.jexpert@recursor.net writes:

Try something like

  # The package names might be wrong and/or you may need additional -dev
  # packages, I don't know the specifics for ubuntu
  apt-get install gcc make valgrind libcurl-dev zlib-dev
  cd
  git clone git://git.kernel.org/pub/scm/git/git.git
  cd git
  echo 'CFLAGS = -O0 -g' >>config.mak
  make
  cd /path/to/repo
  valgrind --track-origins=yes ~/git/git-fsck

It'll be very slow, at least 20x the normal runtime, so don't be surprised if it doesn't seem to get anywhere at first.

Great! Thank you all guys for your extensive instructions!

@Thomas: I only had to add libexpat1-dev to the list.

I checked out Git v1.8.3.4 as this was my used verion and built as instructed. The error is still reproducible using the "CFLAGS = -O0 -g" build.

So - now the puzzling thing: With valgrind it seems to work! If I run it plain, it doesn't:

/tmp/project.git $ valgrind --track-origins=yes ~/projects/git.git/git-fsck ==3431== Memcheck, a memory error detector ==3431== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==3431== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==3431== Command: /home/ben/projects/git.git/git-fsck ==3431== ==3431== Warning: set address range perms: large range [0x70b5000, 0x2b0ff000) (defined) Checking object directories: 100% (256/256), done. ==3431== Warning: set address range perms: large range [0x3959d000, 0x49d53000) (defined) Checking objects: 100% (63588/63588), done. Checking connectivity: 68696, done. ==3431== ==3431== HEAP SUMMARY: ==3431== in use at exit: 7,574,911 bytes in 15,428 blocks ==3431== total heap usage: 422,498 allocs, 407,070 frees, 4,396,939,465 bytes allocated ==3431== ==3431== LEAK SUMMARY: ==3431== definitely lost: 0 bytes in 0 blocks ==3431== indirectly lost: 0 bytes in 0 blocks ==3431== possibly lost: 0 bytes in 0 blocks ==3431== still reachable: 7,574,911 bytes in 15,428 blocks ==3431== suppressed: 0 bytes in 0 blocks ==3431== Rerun with --leak-check=full to see details of leaked memory ==3431== ==3431== For counts of detected and suppressed errors, rerun with: -v ==3431== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2) /tmp/project.git $ ~/projects/git.git/git-fsck Checking object directories: 100% (256/256), done. error: packed 49cdd0b21a351f3366008615d2cf8d03ca943978 from .git/objects/pack/pack-6a6f5355584a5d71215d5fc867ce09602ceab533.pack is corrupt *** glibc detected *** <unknown>: free(): invalid pointer: 0x00007f8576682010 *** ======= Backtrace: ========= /lib/x86_64-linux-gnu/libc.so.6(+0x7eb96)[0x7f85ad765b96] [0x4e727c]

I'm using a i5-3340M on Linux Mint 14 with a offical Linux 3.9.9 gcc (Ubuntu/Linaro 4.7.2-2ubuntu1) 4.7.2

Any further hints?

gitml.jexpert@recursor.net writes:

Weird, indeed. What about GDB ?

Am 08.08.2013 15:18, schrieb Matthieu Moy - Matthieu.Moy@grenoble-inp.fr:> gitml.jexpert@recursor.net writes:

Ah - come on. Is this another Heisenberg bug ? Still trying to reproduce it using gdb and/or valgrind...

ben@n179 /tmp/project.git $ gdb --args ~/projects/git.git/git-fsck GNU gdb (GDB) 7.5-ubuntu Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /home/ben/projects/git.git/git-fsck...done. (gdb) run Starting program: /home/ben/projects/git.git/git-fsck warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7ffff7ffa000 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Checking object directories: 100% (256/256), done. Checking objects: 100% (63588/63588), done. [Inferior 1 (process 3795) exited normally] (gdb) quit

ben@n179 /tmp/project.git $ ~/projects/git.git/git-fsck Checking object directories: 100% (256/256), done. error: packed 49cdd0b21a351f3366008615d2cf8d03ca943978 from .git/objects/pack/pack-6a6f5355584a5d71215d5fc867ce09602ceab533.pack is corrupt Checking objects: 100% (63588/63588), done.

ben@n179 /tmp/project.git $ ~/projects/git.git/git-fsck Checking object directories: 100% (256/256), done. error: packed 49cdd0b21a351f3366008615d2cf8d03ca943978 from .git/objects/pack/pack-6a6f5355584a5d71215d5fc867ce09602ceab533.pack is corrupt Checking objects: 100% (63588/63588), done.

ben@n179 /tmp/project.git $ ~/projects/git.git/git-fsck Checking object directories: 100% (256/256), done. Checking objects: 100% (63588/63588), done.

ben@n179 /tmp/project.git $ ~/projects/git.git/git-fsck Checking object directories: 100% (256/256), done. error: packed 0f5f33639bfc1a781fe080c31a1f076d9a25c1d3 from .git/objects/pack/pack-6a6f5355584a5d71215d5fc867ce09602ceab533.pack is corrupt *** glibc detected *** <unknown>: free(): invalid pointer: 0x00007fe129669010 *** ======= Backtrace: ========= /lib/x86_64-linux-gnu/libc.so.6(+0x7eb96)[0x7fe162d3eb96] [0x51e401] [0x51e53c] [0x51ecc3] [0x4e707b] [0x4e7485] [0x43d433] [0x405158] [0x4052ee] [0x4054ba] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)[0x7fe162ce176d] [0x404429] ======= Memory map: ======== 00400000-005bb000 r-xp 00000000 fc:01 3939047 /home/ben/projects/git.git/git-fsck 007ba000-007bb000 r--p 001ba000 fc:01 3939047 /home/ben/projects/git.git/git-fsck 007bb000-007c2000 rw-p 001bb000 fc:01 3939047 /home/ben/projects/git.git/git-fsck 007c2000-00822000 rw-p 00000000 00:00 0 02770000-05809000 rw-p 00000000 00:00 0 [heap] 7fe129669000-7fe12bc38000 rw-p 00000000 00:00 0 7fe12dff5000-7fe12e00a000 r-xp 00000000 fc:01 7081526 /lib/x86_64-linux-gnu/libgcc_s.so.1 7fe12e00a000-7fe12e209000 ---p 00015000 fc:01 7081526 /lib/x86_64-linux-gnu/libgcc_s.so.1 7fe12e209000-7fe12e20a000 r--p 00014000 fc:01 7081526 /lib/x86_64-linux-gnu/libgcc_s.so.1 7fe12e20a000-7fe12e20b000 rw-p 00015000 fc:01 7081526 /lib/x86_64-linux-gnu/libgcc_s.so.1 7fe12e20b000-7fe13e9c1000 r--p 00000000 fc:01 10879034 /tmp/project.git/.git/objects/pack/pack-6a6f5355584a5d71215d5fc867ce09602ceab533.pack 7fe13e9c1000-7fe162a0b000 r--p 00000000 fc:01 10881032 /tmp/project.git/.git/objects/pack/pack-5b132454d5acb542969a939fe55186a65d9dd697.pack 7fe162a0b000-7fe162abc000 r--p 00000000 fc:01 10902665 /tmp/project.git/.git/objects/pack/pack-6a6f5355584a5d71215d5fc867ce09602ceab533.idx 7fe162abc000-7fe162abe000 r-xp 00000000 fc:01 7085848 /lib/x86_64-linux-gnu/libdl-2.15.so 7fe162abe000-7fe162cbe000 ---p 00002000 fc:01 7085848 /lib/x86_64-linux-gnu/libdl-2.15.so 7fe162cbe000-7fe162cbf000 r--p 00002000 fc:01 7085848 /lib/x86_64-linux-gnu/libdl-2.15.so 7fe162cbf000-7fe162cc0000 rw-p 00003000 fc:01 7085848 /lib/x86_64-linux-gnu/libdl-2.15.so 7fe162cc0000-7fe162e75000 r-xp 00000000 fc:01 7085850 /lib/x86_64-linux-gnu/libc-2.15.so 7fe162e75000-7fe163074000 ---p 001b5000 fc:01 7085850 /lib/x86_64-linux-gnu/libc-2.15.so 7fe163074000-7fe163078000 r--p 001b4000 fc:01 7085850 /lib/x86_64-linux-gnu/libc-2.15.so 7fe163078000-7fe16307a000 rw-p 001b8000 fc:01 7085850 /lib/x86_64-linux-gnu/libc-2.15.so 7fe16307a000-7fe16307f000 rw-p 00000000 00:00 0 7fe16307f000-7fe163097000 r-xp 00000000 fc:01 7085833 /lib/x86_64-linux-gnu/libpthread-2.15.so 7fe163097000-7fe163296000 ---p 00018000 fc:01 7085833 /lib/x86_64-linux-gnu/libpthread-2.15.so 7fe163296000-7fe163297000 r--p 00017000 fc:01 7085833 /lib/x86_64-linux-gnu/libpthread-2.15.so 7fe163297000-7fe163298000 rw-p 00018000 fc:01 7085833 /lib/x86_64-linux-gnu/libpthread-2.15.so 7fe163298000-7fe16329c000 rw-p 00000000 00:00 0 7fe16329c000-7fe16344d000 r-xp 00000000 fc:01 7078062 /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 7fe16344d000-7fe16364d000 ---p 001b1000 fc:01 7078062 /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 7fe16364d000-7fe163668000 r--p 001b1000 fc:01 7078062 /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 7fe163668000-7fe163673000 rw-p 001cc000 fc:01 7078062 /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 7fe163673000-7fe163677000 rw-p 00000000 00:00 0 7fe163677000-7fe16368d000 r-xp 00000000 fc:01 7081635 /lib/x86_64-linux-gnu/libz.so.1.2.7 7fe16368d000-7fe16388c000 ---p 00016000 fc:01 7081635 /lib/x86_64-linux-gnu/libz.so.1.2.7 7fe16388c000-7fe16388d000 r--p 00015000 fc:01 7081635 /lib/x86_64-linux-gnu/libz.so.1.2.7 7fe16388d000-7fe16388e000 rw-p 00016000 fc:01 7081635 /lib/x86_64-linux-gnu/libz.so.1.2.7 7fe16388e000-7fe1638b0000 r-xp 00000000 fc:01 7085838 /lib/x86_64-linux-gnu/ld-2.15.so 7fe16394a000-7fe163a4d000 r--p 00000000 fc:01 10888685 /tmp/project.git/.git/objects/pack/pack-5b132454d5acb542969a939fe55186a65d9dd697.idx 7fe163a4d000-7fe163a8c000 r--p 00000000 fc:01 1048722 /usr/lib/locale/de_DE.utf8/LC_CTYPE 7fe163a8c000-7fe163a90000 rw-p 00000000 00:00 0 7fe163aa5000-7fe163aa6000 rw-p 00000000 00:00 0 7fe163aa6000-7fe163aad000 r--s 00000000 fc:01 12987862 /usr/lib/x86_64-linux-gnu/gconv/gconv-modules.cache 7fe163aad000-7fe163aae000 r--p 00000000 fc:01 1050508 /usr/lib/locale/de_DE.utf8/LC_MESSAGES/SYS_LC_MESSAGES 7fe163aae000-7fe163ab0000 rw-p 00000000 00:00 0 7fe163ab0000-7fe163ab1000 r--p 00022000 fc:01 7085838 /lib/x86_64-linux-gnu/ld-2.15.so 7fe163ab1000-7fe163ab3000 rw-p 00023000 fc:01 7085838 /lib/x86_64-linux-gnu/ld-2.15.so 7fff8299b000-7fff829bc000 rw-p 00000000 00:00 0 [stack] 7fff829fe000-7fff82a00000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] Abgebrochen

gitml.jexpert@recursor.net writes:

Using

  addr2line -e ~/projects/git.git/git-fsck

on these addresses may help a little, but not sure it's going to be sufficient :-(.

I'm still trying to reproduce this issue using gdb. Also I'm trying to reproduce this issue with my git repo on another machine.

ben@n179 /tmp $ addr2line -e ~/projects/git.git/git-fsck 0x51e401 0x51e53c 0x51ecc3 0x4e707b 0x4e7485 0x43d433 0x405158 0x4052ee 0x4054ba /home/ben/projects/git.git/sha1_file.c:1901 /home/ben/projects/git.git/sha1_file.c:1928 /home/ben/projects/git.git/sha1_file.c:2096 /home/ben/projects/git.git/pack-check.c:119 /home/ben/projects/git.git/pack-check.c:177 /home/ben/projects/git.git/builtin/fsck.c:678 /home/ben/projects/git.git/git.c:291 /home/ben/projects/git.git/git.c:453 /home/ben/projects/git.git/git.c:543

gitml.jexpert@recursor.net writes:

Can you try to reproduce with a version older than v1.8.3? E.g. v1.8.2.3.

I'm asking because the above points at packed_object_info(), which I recently rewrote to be nonrecursive.

Also, can you please stop losing the Cc list? The etiquette on this list is to Cc everyone who was involved so far, usually meaning everyone who was already a recipient of the mail you are replying to.

Am 08.08.2013 16:20, schrieb Thomas Rast - trast@inf.ethz.ch:

It seems to run 'much better' 
  v1.8.2.3 : 3/10 runs do fail
  fb56570  : 9/10 runs do fail

They always fail on a big blob (39MB) as I wrote in my first e-mail:

ben@n179 /tmp/project.git $ ~/projects/git.git/git-show 49cdd0b21a351f3366008615d2cf8d03ca943978 | wc -c error: sha1 mismatch 49cdd0b21a351f3366008615d2cf8d03ca943978 fatal: bad object 49cdd0b21a351f3366008615d2cf8d03ca943978 0 ben@n179 /tmp/project.git $ ~/projects/git.git/git-show 49cdd0b21a351f3366008615d2cf8d03ca943978 | wc -c 39517156

I'm _very_ sorry for this. I was trying to hide my e-mail address from spam robots using spamgourmet.com as remailer. Unfortunately it breaks CC. Switching e-mail now.

Ben Tebulin <tebulin@googlemail.com> writes:

The good news is that this shifts the blame away from my commit ;-) as the problem clearly existed even before that.

The bad news, of course, is that this is another hunch that turned out to be wrong. I'm running out of ideas.

Hrmm. I wonder about the significance of those 39MB. What is your core.packedGitWindowSize? (Judging from the pastes you seem to be on 64bit, so the default would be 1GB.)

I was unable to reproduce the error with the same repo and same Git version on a different machine (Debian Squeeze x64 on a AMD Phenom x6 1045T).

Me, too. Based on out current observations I'd assume one of:

a) a rare, timing-sensitive bug in Git b) a compiler/distribution/environment sensitive issue c) or defect/buggy Hardware (CPU, Memory)

The default. I have 12GB RAM.

So I'll try to rule out b) and c) as far as I can and report in if I have any new findings.

Nevertheless thank you very much for your extensive assistance!

- Ben

Ben Tebulin <tebulin@googlemail.com> writes:

You may want to try a memcheck86 on your machine for a few hours, in case ... (if your RAM is broken, you do want to know it!).

Thomas Rast <trast@inf.ethz.ch> writes:

Hmm, from this, and a later one ...

... I am reading that (1) the packfile and repository is basically OK, (2) reading that object sometimes fails, and (3) the symptom is not limited to fsck but anything that reads the object with parse_object(). And that symptom exists only on that single machine (I am assuming that the repository was bit-for-bit copied, not "cloned", for the purpose of testing it on the other machine). That makes me suspect something outside the control of Git (e.g. faulty memory or disk controller cable).

Are there other big blobs in the repository, and would "show | wc" fail if you attempt to read it on that machine?

Thanks all for helping to track this, by the way.

Hello everybody!

I have some _very interesting_ news regarding this issue! Here is the deal:

  1. I was able to *reproduce the error on a machine of a coworker!*

  2. I was able to rule out
      - HDD: It's reproducible from /dev/shm
      - Memory: Memory tests works fine

now the interesting part:

  3. Occurs on Linux kernels 3.7.10, 3.8.x, 3.9.11, 3.10.5
     _but not on:_ 3.6.11, 3.5.7 and 2.6.32

Both machines showing this problem are »Dell Latitude E6330« with an »i5-3340M @ 2.70GHz« CPU. Mine running stock kernels, coworker using plain Ubuntu 13.04.

Furthermore I need to stress, that we never had any issues with our devices during daily _at all_.

So what to do best now?

- Ben

Am 08.08.2013 19:38, schrieb Junio C Hamano:

[..]

On 08/09/2013 02:27 PM, Ben Tebulin wrote:

Maybe include the kernel mailing list, they know what's up ;) Linking to the start of the discussion $gmane/33602 Maybe you could also run git through strace and diff the output of a faulty machine with a correct machine?

Stefan

Hello everybody!

I'm the guy having the issue, that in a particular Git repository the reads of an object fail the SHA1 reproducible on *two independent machines* .

The issue occurs on a very specific repository starting with Linux Kernel 3.7.2. Unfortunately my E-Mail to the kernel list dit get no response.

After a long session of rebooting and bisecting the Linux kernel (fortunately I had a SSD and ccache!) I was able to pinpoint this to the following patch related to _memory management_ causing my data corruption with git:

*"mm: limit mmu_gather batching to fix soft lockups on !CONFIG_PREEMPT"*
  787f7301074ccd07a3e82236ca41eefd245f4e07 linux stable [1]
  53a59fc67f97374758e63a9c785891ec62324c81 upstream commit [2]

The patch speaks about "batching [memory] pages to be freed" so I'm a bit unsure: Is this a Git or a Linux kernel issue?

Thanks
- Ben

[1] https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=787f7301074ccd07a3e82236ca41eefd245f4e07 [2] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=53a59fc67f97374758e63a9c785891ec62324c81

Ben Tebulin <tebulin@googlemail.com> writes:

If you're still interested...

What did memcheck86 say about these machines?

My best theory so far:

malloc()/free() actually use mmap()/munmap() for large allocations. mallopt(3) tells me that "large" here means a dynamic limit on modern glibc, but with an upper limit of 32MB on 64-bit. So your 39MB blob would always result in an mmap() type allocation.

And it should be easy for glibc to check mmap() type allocations against double free(), at least if the address has not been mapped again in the same process. So it probably does that, which aborts the program.

You could try to gather some data on this by looking at

  strace -o fsck.trace -f git fsck

for a crash case. If the theory is correct, you should see an munmap() for an address similar to the one pointed out by the glibc error message, as follows: if you get

  *** glibc detected *** <unknown>: free(): invalid pointer: 0x00007fe129669010 ***

check for the address 0x7fe129669000 (the start of the page that the address is in).

Note that this is a pretty weak theory, because double free() detection is squarely up valgrind's alley. So valgrind's lack of complaints is a strong argument against it. But it's the best I've got so far.

Many things I don't grab at first go :-)

Last night I did a long git-bisect of the kernel and was able to pinpoint a change in the Linux memory management as cause (see my pre-prepared email I just sent).

Would that fit into your theory?

Before I dive into that maybe you could throw a quick look at the causing Kernel change (which reading from the words _could_ be related) if this fits into the picture?

If yes, I'm happy to try to assist you in further pinning this issue down!

Just as a catchup for everybody being interested:

I finally wrote to the linux-mm newsgroup and Linus pointed out, that this might be a known bug yet not fixed in mainline.

Unfortunately this doesn't seem to stand the test; but as far as Git is concerned, it appears that that they are willing to take actions.

http://thread.gmane.org/gmane.linux.kernel/1541707/focus=105432

On Thu, Aug 15, 2013 at 2:32 AM, Ben Tebulin <tebulin@googlemail.com> wrote:

Thanks for following this up.

gitml.jexpert@recursor.net writes:

[...]

[...]

Hrm.  Can you try getting a backtrace from

  $ gdb ~/projects/git.git/git-fsck
  (gdb) run
  ... wait until it crashes ...
  (gdb) backtrace full

I would have been more interested in error output from valgrind, because memory corruption invariably happens long before glibc finally figures out that something is amiss. But as things stand, the backtrace is probably the only thing we have...

gitml.jexpert@recursor.net writes:

To fetch sources and compile:

  git clone https://github.com/git/git.git
  cd git/
  make CFLAGS='-g -O0'

To run gdb:

  gdb --args ./git fsck

Then type "run" at the gdb prompt. When the program crashes, you should get the gdb prompt back. Then, typing "bt" gives you a backtrace, and "bt full" gives you the same with more information (be careful, there may be private information in it).

To use valgrind, just do:

  valgrind ./git fsck

(essentially, it runs the program adding a bunch of runtime checks hence may provide better diagnosis)

On 08/08/2013 02:23 PM, gitml.jexpert@recursor.net wrote:

The version from the ppa seems to be 1.7.0.4-1ubuntu0.2 but the version of git being in the native ubuntu quantal repository (I assume you're running Ubuntu?) is already 1.7.10.4-1ubuntu1 (http://packages.ubuntu.com/quantal/git)

However to get an unoptimized version with debug symbols you could do this:

	# get the source:
	git clone git://git.kernel.org/pub/scm/git/git.git/
	cd git

	# read INSTALL, the section starting at 
	# > Git is reasonably self-sufficient, but does depend on a few external
	# > programs and libraries
	# this is a guess, maybe you need more or less packages, but you'd need the -dev packages for the C-headers
	sudo apt-get install libz-dev libopenssl-dev libcurl-dev libexpat-dev 
	
	# Now disable optimizing by overwriting default compile flags:
	echo "CFLAGS=-g" > config.mak

	# compile and install	
	make 
	make install # installs to ~/bin

	# open a new shell or relogin, and see if you're using the version you just build:
	git --version
	# git version 1.8.4.rc1....

Stefan

On 08/08/2013 01:56 PM, gitml.jexpert@recursor.net wrote:

Hi,

Regarding the backtrace, would it be possible to install debug symbols, so the backtrace is a little more meaningful? If you distribution doesn't provide debug symbols, compiling git yourself is rather easy (git clone && make && make install [defaults to ~/bin, so not root required for installing apart from missing dependencies])

Stefan