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
On Thu, Aug 15, 2013 at 2:32 AM, Ben Tebulin tebu...@googlemail.com wrote:
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
Ben Tebulin tebu...@googlemail.com writes:
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
-
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
My best theory so far:
malloc()/free() actually use mmap()/munmap() for large allocations.
mallopt(3) tells me that [...]
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
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
On 08/09/2013 02:27 PM, Ben Tebulin wrote:
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
-
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
gitml.jexp...@recursor.net writes:
➜ 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:
On 08/08/2013 01:56 PM, gitml.jexp...@recursor.net wrote:
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:
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
gitml.jexp...@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
On 08/08/2013 02:23 PM, gitml.jexp...@recursor.net wrote:
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
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
gitml.jexp...@recursor.net writes:
So - now the puzzling thing: With valgrind it seems to work!
Weird, indeed. What about GDB ?
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to
gitml.jexp...@recursor.net writes:
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== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)
Am 08.08.2013 15:18, schrieb Matthieu Moy - matthieu@grenoble-inp.fr:
gitml.jexp...@recursor.net writes:
So - now the puzzling thing: With valgrind it seems to work!
Weird, indeed. What about GDB ?
Ah - come on. Is this another Heisenberg bug ?
Still trying to reproduce it using gdb
gitml.jexp...@recursor.net writes:
/lib/x86_64-linux-gnu/libc.so.6(+0x7eb96)[0x7fe162d3eb96]
[0x51e401]
[0x51e53c]
[0x51ecc3]
[0x4e707b]
[0x4e7485]
[0x43d433]
[0x405158]
[0x4052ee]
[0x4054ba]
Using
addr2line -e ~/projects/git.git/git-fsck
on these addresses may help a little, but
gitml.jexp...@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
Am 08.08.2013 16:20, schrieb Thomas Rast - tr...@inf.ethz.ch:
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.
It seems to run 'much better'
v1.8.2.3 : 3/10
Ben Tebulin tebu...@googlemail.com writes:
Am 08.08.2013 16:20, schrieb Thomas Rast - tr...@inf.ethz.ch:
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.
It
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).
I'm running out of ideas.
Me, too. Based on out current observations I'd assume one of:
a) a rare, timing-sensitive bug in Git
b) a
Thomas Rast tr...@inf.ethz.ch writes:
Ben Tebulin tebu...@googlemail.com writes:
Am 08.08.2013 16:20, schrieb Thomas Rast - tr...@inf.ethz.ch:
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
23 matches
Mail list logo