Re: Segmentation fault with latest git (070c57df)
- From
Jeff King <peff@peff.net>
- Date
- Jan 31, 2013, 08:54 UTC
- Message-ID
- <20130131085431.GA8467@sigill.intra.peff.net>
- In-Reply-To
- <87wqutvj4w.fsf@pctrast.inf.ethz.ch>
On Thu, Jan 31, 2013 at 09:42:07AM +0100, Thomas Rast wrote:
Show 10 quoted lines
> > 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