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
> 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'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
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
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 compiler/distrib
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/1
6 matches
Mail list logo
