On Thu, Mar 20, 2008 at 06:53:27PM -0400, Tom Lane wrote:
> Kurt Roeckx <kurt@roeckx.be> writes:
> > I did some tests with gcc 4.3 on the branches from 7.4 to 8.3 and head.
> > 8.3 and head don't have a problem. All others failed in the
> > ContribCheck state.
>
> > You can see the results on buildfarm member panda.
>
> Bizarre. There doesn't seem to be any significant difference in the seg
> code between 8.2 and 8.3, so why is 8.2 failing there?
>
> The cube code got a significant overhaul (V0 to V1 call conventions)
> between 8.1 and 8.2, so that might explain why it's OK in 8.2 and up.
> Or not. If that is it, we'd likely just write it off as not-gonna-fix,
> but it could stand investigation to pinpoint the cause.
>
> Can you poke into it with a debugger? The first failure case in seg
> ought to be easy enough to investigate.
It seems this can even be reproduced at -O0.
What I see is that in seg.c we have:
typedef char bool;
bool seg_same(SEG * a, SEG * b);
And in fmgr_oldstyle() you have:
typedef char *(*func_ptr) ();
func_ptr user_fn;
char *returnValue;
user_fn = fnextra->func
returnValue = (*user_fn) (fcinfo->arg[0], fcinfo->arg[1]);
With fnextra->func set to seg_same.
Somewhere seg_same is converted from returning a bool to
returning a char pointer.
returnValue has the value 0xffffff00 for me, which of course is an
invalid pointer.
Kurt