Something really weird is happening to a repository I'm working on, and
it's only a problem in recent Gits. A bisect shows that from
v1.7.6-1-g2548183 ("fix phantom untracked files when core.ignorecase is
set") and newer, this happens:
$ git clone git://gitorious.org/tz/tzfiles.git
Cloning into tzfiles...
remote: Counting objects: 358, done.
remote: Compressing objects: 100% (352/352), done.
remote: Total 358 (delta 8), reused 343 (delta 3)
Receiving objects: 100% (358/358), 44.15 MiB | 3.76 MiB/s, done.
Resolving deltas: 100% (8/8), done.
$ cd tzfiles/
$ git status
git: malloc.c:3096: sYSMALLOc: Assertion `(old_top == (((mbinptr)
(((char *) &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct
malloc_chunk, fd)))) && old_size == 0) || ((unsigned long) (old_size)
>= (unsigned long)((((__builtin_offsetof (struct malloc_chunk,
fd_nextsize))+((2 * (sizeof(size_t))) - 1)) & ~((2 * (sizeof(size_t)))
- 1))) && ((old_top)->size & 0x1) && ((unsigned long)old_end &
pagemask) == 0)' failed.
Aborted
$ git status
*** glibc detected *** git: free(): invalid next size (normal): 0x089f5588 ***
======= Backtrace: =========
/lib/tls/i686/cmov/libc.so.6(+0x6b591)[0xb74d3591]
/lib/tls/i686/cmov/libc.so.6(+0x6cde8)[0xb74d4de8]
/lib/tls/i686/cmov/libc.so.6(cfree+0x6d)[0xb74d7ecd]
/lib/tls/i686/cmov/libc.so.6(+0x5c410)[0xb74c4410]
/lib/tls/i686/cmov/libc.so.6(fopen64+0x2c)[0xb74c69ec]
git[0x80c1fdd]
git[0x811b82b]
git[0x80637ea]
git[0x804bc87]
git[0x804be93]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe6)[0xb747ebd6]
git[0x804b521]
======= Memory map: ========
08048000-08160000 r-xp 00000000 ca:00 2474445
/usr/local/varprg/git.master.v1.7.7-419-g87009ed/bin/git
08160000-08161000 r--p 00117000 ca:00 2474445
/usr/local/varprg/git.master.v1.7.7-419-g87009ed/bin/git
08161000-08166000 rw-p 00118000 ca:00 2474445
/usr/local/varprg/git.master.v1.7.7-419-g87009ed/bin/git
08166000-081b0000 rw-p 00000000 00:00 0
089ec000-08a0d000 rw-p 00000000 00:00 0 [heap]
b7300000-b7321000 rw-p 00000000 00:00 0
b7321000-b7400000 ---p 00000000 00:00 0
b7444000-b7461000 r-xp 00000000 ca:00 24591 /lib/libgcc_s.so.1
b7461000-b7462000 r--p 0001c000 ca:00 24591 /lib/libgcc_s.so.1
b7462000-b7463000 rw-p 0001d000 ca:00 24591 /lib/libgcc_s.so.1
b7463000-b7464000 rw-p 00000000 00:00 0
b7464000-b7466000 r-xp 00000000 ca:00 1679643
/lib/tls/i686/cmov/libdl-2.11.1.so
b7466000-b7467000 r--p 00001000 ca:00 1679643
/lib/tls/i686/cmov/libdl-2.11.1.so
b7467000-b7468000 rw-p 00002000 ca:00 1679643
/lib/tls/i686/cmov/libdl-2.11.1.so
b7468000-b75bb000 r-xp 00000000 ca:00 25961
/lib/tls/i686/cmov/libc-2.11.1.so
b75bb000-b75bc000 ---p 00153000 ca:00 25961
/lib/tls/i686/cmov/libc-2.11.1.so
b75bc000-b75be000 r--p 00153000 ca:00 25961
/lib/tls/i686/cmov/libc-2.11.1.so
b75be000-b75bf000 rw-p 00155000 ca:00 25961
/lib/tls/i686/cmov/libc-2.11.1.so
b75bf000-b75c3000 rw-p 00000000 00:00 0
b75c3000-b75d8000 r-xp 00000000 ca:00 1679654
/lib/tls/i686/cmov/libpthread-2.11.1.so
b75d8000-b75d9000 r--p 00014000 ca:00 1679654
/lib/tls/i686/cmov/libpthread-2.11.1.so
b75d9000-b75da000 rw-p 00015000 ca:00 1679654
/lib/tls/i686/cmov/libpthread-2.11.1.so
b75da000-b75dc000 rw-p 00000000 00:00 0
b75dc000-b7714000 r-xp 00000000 ca:00 2007508
/lib/i686/cmov/libcrypto.so.0.9.8
b7714000-b771c000 r--p 00137000 ca:00 2007508
/lib/i686/cmov/libcrypto.so.0.9.8
b771c000-b772a000 rw-p 0013f000 ca:00 2007508
/lib/i686/cmov/libcrypto.so.0.9.8
b772a000-b772e000 rw-p 00000000 00:00 0
b772e000-b7741000 r-xp 00000000 ca:00 24635 /lib/libz.so.1.2.3.3
b7741000-b7742000 r--p 00012000 ca:00 24635 /lib/libz.so.1.2.3.3
b7742000-b7743000 rw-p 00013000 ca:00 24635 /lib/libz.so.1.2.3.3
b774b000-b774f000 rw-p 00000000 00:00 0
b774f000-b776a000 r-xp 00000000 ca:00 25083 /lib/ld-2.11.1.so
b776a000-b776b000 r--p 0001a000 ca:00 25083 /lib/ld-2.11.1.so
b776b000-b776c000 rw-p 0001b000 ca:00 25083 /lib/ld-2.11.1.so
bfc1b000-bfc3c000 rw-p 00000000 00:00 0 [stack]
f57fe000-f57ff000 r-xp 00000000 00:00 0 [vdso]
Aborted
$
Reverting 2548183 fixes the problem.
It also seems that the behaviour is not consistent. Sometimes, after
running the second "git status", this happens:
$ git st
error: index uses extension, which we do not understand
fatal: index file corrupt
And no, this is not memory corruption or something like that, the same
thing happens on my laptop.
Another curious thing: When using an earlier git (for example v1.7.6 in
the example below) on this repo after a "git status" with a recent git,
it segfaults. This indicates that recents Gits messes up something so
even old gits won't work in that repo anymore. This is the last lines of
an strace:
open(".git/objects/pack",
O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3
getdents64(3, /* 4 entries */, 32768) = 192
access(".git/objects/pack/pack-b9b05d1e8fed49138c1ffda8f0f2b7d7a8d31c6a.keep",
F_OK) = -1 ENOENT (No such file or directory)
stat64(".git/objects/pack/pack-b9b05d1e8fed49138c1ffda8f0f2b7d7a8d31c6a.pack",
{st_mode=S_IFREG|0444, st_size=46297839, ...}) = 0
getdents64(3, /* 0 entries */, 32768) = 0
close(3) = 0
open(".git/objects/info/alternates", O_RDONLY|O_LARGEFILE|O_NOATIME)
= -1 ENOENT (No such file or directory)
open(".git/objects/pack/pack-b9b05d1e8fed49138c1ffda8f0f2b7d7a8d31c6a.idx",
O_RDONLY|O_LARGEFILE|O_NOATIME) = 3
fstat64(3, {st_mode=S_IFREG|0444, st_size=11096, ...}) = 0
mmap2(NULL, 11096, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb76e1000
close(3) = 0
getrlimit(RLIMIT_NOFILE, {rlim_cur=1024, rlim_max=1024}) = 0
open(".git/objects/pack/pack-b9b05d1e8fed49138c1ffda8f0f2b7d7a8d31c6a.pack",
O_RDONLY|O_LARGEFILE|O_NOATIME) = 3
fstat64(3, {st_mode=S_IFREG|0444, st_size=46297839, ...}) = 0
fcntl64(3, F_GETFD) = 0
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
read(3, "PACK\0\0\0\2\0\0\1f", 12) = 12
_llseek(3, 46297819, [46297819], SEEK_SET) = 0
read(3, ",j\212\0375c\335\0k\244)\256\376\24\v\344\6]0\230", 20) = 20
mmap2(NULL, 33554432, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb53fc000
open(".git/info/grafts", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such
file or directory)
open(".git/shallow", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file
or directory)
brk(0x977e000) = 0x977e000
open("/proc/meminfo", O_RDONLY) = 4
fstat64(4, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0xb76e0000
read(4, "MemTotal: 1028684 kB\nMemF"..., 1024) = 1024
close(4) = 0
munmap(0xb76e0000, 4096) = 0
access(".git/info/exclude", R_OK) = 0
open(".git/info/exclude", O_RDONLY|O_LARGEFILE) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=240, ...}) = 0
read(4, "# git ls-files --others --exclud"..., 240) = 240
close(4) = 0
access("/home/sunny/src/git/home-sunny/.gitexclude", R_OK) = 0
open("/home/sunny/src/git/home-sunny/.gitexclude", O_RDONLY|O_LARGEFILE) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=86, ...}) = 0
read(4, "\n# ~/.gitexclude\n# File ID: bcf6"..., 86) = 86
close(4) = 0
open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 4
getdents64(4, /* 7 entries */, 32768) = 216
open(".gitignore", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file
or directory)
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
Complete strace dump is stored at https://gist.github.com/1318830 .
I'm currently using 1.7.7.419.g87009 , compiled with a regular "make"
from the master branch. A quick test with newest master
(v1.7.7.1-475-g997a194) shows the same error. Not installed properly,
though, as I haven't run the test suite yet.
System info:
Ubuntu 10.04.3 LTS
gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3
GNU ld (GNU Binutils for Ubuntu) 2.20.1-system.20100303
Same thing happens with Ubuntu 10.10 on my laptop.
Even when creating a bundle and recloning, this happens. Also when
initialising a new, clean repo and fetching from the original local
clone, same story.
The repository was created on 2011-10-08 06:54:00 +0200, and because I
create a tag everytime I compile (using
<https://github.com/sunny256/utils/blob/master/build-git>), I know the
repository was created with git v1.7.7-138-g7f41b6b.
Because Gmail probably will wrap long lines, a copy of this message is
stored at <https://gist.github.com/1318935>.
Regards,
Øyvind
--
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