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