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
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
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
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
6 matches
Mail list logo
