On Thu, Aug 15, 2013 at 2:32 AM, Ben Tebulin 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 test; but as far
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
Ben Tebulin 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
> - Memory: Memory
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
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
Thomas Rast writes:
> Ben Tebulin 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 nonre
Ben Tebulin writes:
> c) or defect/buggy Hardware (CPU, Memory)
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!).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsu
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
Ben Tebulin 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 seems to run '
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
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 gi
> 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 $ addr
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 litt
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 a
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)
> /tm
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 majord...@vger.kernel
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 val
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,
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
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
> 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
> manageme
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
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 ***
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
26 matches
Mail list logo
