On Thu, Jan 31, 2013 at 09:42:07AM +0100, Thomas Rast wrote:
> > int main(void)
> > {
> > struct foo f = { NULL, 0, 0, 0 };
> > printf("cmp is %lu\n", (unsigned long)f.cmp);
> > return 0;
> > }
>
> I doubt that would help because that stack region would be 0 anyway due
> to kernel initialization of new pages. You'd have to somehow trample
> over it first, like below.
Good point. Unfortunately, I can't get either yours or mine to fail,
neither with a recent version of gcc nor with gcc-4.1. But I can't
convince git to fail, either. The only gcc-4.1 I have is Debian's
4.1.3 release, which is not quite what the OP has.
> Or perhaps something in the build process went wrong, and fetch.c didn't
> get the memo about the new field in the struct. Depending on stack
> layout, the next variable might be the 'int i' right before the
> 'string_list list' in the code, which could explain the value of 1.
Yeah, that would make sense to me with respect to the behavior we are
seeing, but that part of the Makefile should be pretty simple and
bug-free, I'd think (and from the original report, it seems like he was
able to reproduce it well enough to bisect). Still, trying a "make clean
&& make" might be worth it just to rule that out.
Puzzled...
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
