On Tue, Mar 19, 2013 at 11:11 PM, Thomas Rast wrote:
> Actually scratch that again. It *is* a stack overflow, except that this
> is a thread stack, for which the OS X defaults are 512kB apparently, as
> opposed to 2MB on linux.
Thanks. I was scratching my head last night wondering if there was
u
Thomas Rast writes:
> Actually scratch that again. It *is* a stack overflow, except that this
> is a thread stack, for which the OS X defaults are 512kB apparently, as
> opposed to 2MB on linux.
> ...
> And indeed the following patch fixes it. Sounds like the delta
> unpacking needs a rewrite t
Thomas Rast writes:
> Thomas Rast writes:
>
>> (gdb) r index-pack --keep --stdin -v --pack_header=2,50757 > Starting program: /Users/trast/.local/bin/git index-pack --keep
>> --stdin -v --pack_header=2,50757 > Reading symbols for shared libraries +++ done
>> Recei
Thomas Rast writes:
> (gdb) r index-pack --keep --stdin -v --pack_header=2,50757Starting program: /Users/trast/.local/bin/git index-pack --keep
> --stdin -v --pack_header=2,50757Reading symbols for shared libraries +++ done
> Receiving objects: 100% (50757/5075
sza...@google.com (Stefan Zager) writes:
> We have uncovered a regression in this commit:
>
> b8a2486f1524947f232f657e9f2ebf44e3e7a243
>
> The symptom is that 'git fetch' dies with:
>
> error: index-pack died of signal 10
> fatal: index-pack failed
So after that fun detour into threading issues,
On Tue, Mar 19, 2013 at 3:17 PM, Thomas Rast wrote:
>> but the line in question is:
>>
>> if (deepest_delta < delta_obj->delta_depth)
>>
>...
>
> Duy, what was the reasoning why resolve_delta() does not need to hold
> locks when it looks when it looks at deepest_delta? My coffee levels
> aren't
On Tue, Mar 19, 2013 at 11:45:56AM +0100, Thomas Rast wrote:
> Now consider
>
> // somewhere on the stack
> struct foo {
> char c;
> int i;
> } a, b;
> a.c = a.i = 0;
>
> memcpy(&b, &a, sizeof(struct foo));
>
> The compiler could legitimately leave the padding between c and i
Jeff King writes:
> On Tue, Mar 19, 2013 at 11:29:36AM +0100, Thomas Rast wrote:
>
>> > Ah, indeed. Putting:
>> >
>> > fprintf(stderr, "%lu\n", base->obj->delta_depth);
>> >
>> > before the conditional reveals that base->obj->delta_depth is
>> > uninitialized, which is the real problem. I'm sur
On Tue, Mar 19, 2013 at 11:29:36AM +0100, Thomas Rast wrote:
> > Ah, indeed. Putting:
> >
> > fprintf(stderr, "%lu\n", base->obj->delta_depth);
> >
> > before the conditional reveals that base->obj->delta_depth is
> > uninitialized, which is the real problem. I'm sure there is some
> > perfectly
Jeff King writes:
> On Tue, Mar 19, 2013 at 06:08:00AM -0400, Jeff King wrote:
>
>> @@ -538,6 +539,8 @@ static void resolve_delta(struct object_entry *delta_obj,
>>
>> delta_obj->real_type = base->obj->real_type;
>> delta_obj->delta_depth = base->obj->delta_depth + 1;
>> +if (deep
On Tue, Mar 19, 2013 at 06:08:00AM -0400, Jeff King wrote:
> @@ -538,6 +539,8 @@ static void resolve_delta(struct object_entry *delta_obj,
>
> delta_obj->real_type = base->obj->real_type;
> delta_obj->delta_depth = base->obj->delta_depth + 1;
> + if (deepest_delta < delta_obj->de
On Tue, Mar 19, 2013 at 05:59:43AM -0400, Jeff King wrote:
> > Yes, that has been my experience with valgrind false positives, too. But
> > if this is a real problem, it may be different from the OP's issue. It
> > seems to trigger for me in v1.7.10, before Duy's threading patches. It
> > does not
On Tue, Mar 19, 2013 at 05:30:34AM -0400, Jeff King wrote:
> On Tue, Mar 19, 2013 at 09:17:32AM +0100, Thomas Rast wrote:
>
> > > but the line in question is:
> > >
> > > if (deepest_delta < delta_obj->delta_depth)
> > >
> > > And in the debugger, both of those variables appear to have sane val
On Tue, Mar 19, 2013 at 09:17:32AM +0100, Thomas Rast wrote:
> > but the line in question is:
> >
> > if (deepest_delta < delta_obj->delta_depth)
> >
> > And in the debugger, both of those variables appear to have sane values
> > (nor should either impacted by the patch you bisected to). On top
Jeff King writes:
> On Fri, Mar 15, 2013 at 03:42:40PM -0700, Stefan Zager wrote:
>
>> We have uncovered a regression in this commit:
>>
>> b8a2486f1524947f232f657e9f2ebf44e3e7a243
>>
>> The symptom is that 'git fetch' dies with:
>>
>> error: index-pack died of signal 10
>> fatal: index-pack f
On Sat, Mar 16, 2013 at 6:41 PM, Jeff King wrote:
> On Fri, Mar 15, 2013 at 03:42:40PM -0700, Stefan Zager wrote:
>
>> We have uncovered a regression in this commit:
>>
>> b8a2486f1524947f232f657e9f2ebf44e3e7a243
What version did you test? We used to have problems with multithreaded
index-pack on
On Fri, Mar 15, 2013 at 03:42:40PM -0700, Stefan Zager wrote:
> We have uncovered a regression in this commit:
>
> b8a2486f1524947f232f657e9f2ebf44e3e7a243
>
> The symptom is that 'git fetch' dies with:
>
> error: index-pack died of signal 10
> fatal: index-pack failed
>
> I have only been abl
We have uncovered a regression in this commit:
b8a2486f1524947f232f657e9f2ebf44e3e7a243
The symptom is that 'git fetch' dies with:
error: index-pack died of signal 10
fatal: index-pack failed
I have only been able to reproduce it on a Mac thus far; will try ubuntu next.
We can make it go away
18 matches
Mail list logo
