Thread: RedHat6.0 & Alpha

RedHat6.0 & Alpha

From
Uncle George
Date:
In the regression test rules.sql there is this SQL command

        update rtest_v1 set a = rtest_t3.a + 20 where b = rtest_t3.b;

Which causes my alpha port to go core.  The above line can be reduced to:

        update rtest_v1 set a = rtest_t3.a + 20 ;

which also causes the same problem. It seems that the 64 bit address
((Expr*)nodeptr)->oper gets truncated ( high 32 bits ) somewhere along the way.

I was able to locate the errant code in  rewriteManip.c:712. but There seems to be a
bigger problem other than eraseing the upper 32bit address. It seems that
FindMatchingNew() returns a node of type T_Expr, rather than the expected  type of
T_Var.  Once u realize this then u can see why the now MISCAST "(Var *)
*nodePtr)->varlevelsup = this_varlevelsup" will cause a problem.  On my alpha this erases
a portion in the address in the T_Expr. On the redhat 5.2/i386 this code seems to be
benign, BUT YOU ARE ERASEING SOMETHING that doesn't belong to to T_Expr !

So what gives?
gat
Maybe an assert() will help in finding some of the miscast returned types? Wuddya think?
sure would catch some of the boo-boo's hanging around

rewriteManip.c:
              if (this_varno == info->new_varno &&
                    this_varlevelsup == sublevels_up)
                {
                    n = FindMatchingNew(targetlist,
                                        ((Var *) node)->varattno);
                    if (n == NULL)
                    {
                        if (info->event == CMD_UPDATE)
                        {
                            *nodePtr = n = copyObject(node);
                            ((Var *) n)->varno = info->current_varno;
                            ((Var *) n)->varnoold = info->current_varno;
                        }
                        else
                            *nodePtr = make_null(((Var *) node)->vartype);
                    }
                    else
                    {
                        *nodePtr = copyObject(n);
                       ((Var *) *nodePtr)->varlevelsup = this_varlevelsup;    /* This
line zaps the address */
                    }
                }






Re: [HACKERS] RedHat6.0 & Alpha

From
Tom Lane
Date:
Uncle George <gatgul@voicenet.com> writes:
> In the regression test rules.sql there is this SQL command
>         update rtest_v1 set a = rtest_t3.a + 20 where b = rtest_t3.b;
> Which causes my alpha port to go core.

Yeah.  This was reported by Pedro Lobo on 11 June, and we've been
patiently waiting for Jan to decide what to do about it :-(

You could stop the coredump by putting a test into ResolveNew:

                    {
                        *nodePtr = copyObject(n);
+                       if (IsA(*nodePtr, Var))
                            ((Var *) *nodePtr)->varlevelsup = this_varlevelsup;
                    }

but what's not so clear is what's supposed to happen when the
replacement item *isn't* a Var.  I tried to convince myself that nothing
needed to happen in that case, but wasn't successful.  (Presumably the
replacement expression contains no instances of the variable being
replaced, so recursing into it with ResolveNew shouldn't be needed
--- but maybe its varlevelsup values need adjusted?)

            regards, tom lane

Re: [PORTS] RedHat6.0 & Alpha

From
Bruce Momjian
Date:
Can anyone address the status of this bug?


> In the regression test rules.sql there is this SQL command
>
>         update rtest_v1 set a = rtest_t3.a + 20 where b = rtest_t3.b;
>
> Which causes my alpha port to go core.  The above line can be reduced to:
>
>         update rtest_v1 set a = rtest_t3.a + 20 ;
>
> which also causes the same problem. It seems that the 64 bit address
> ((Expr*)nodeptr)->oper gets truncated ( high 32 bits ) somewhere along the way.
>
> I was able to locate the errant code in  rewriteManip.c:712. but There seems to be a
> bigger problem other than eraseing the upper 32bit address. It seems that
> FindMatchingNew() returns a node of type T_Expr, rather than the expected  type of
> T_Var.  Once u realize this then u can see why the now MISCAST "(Var *)
> *nodePtr)->varlevelsup = this_varlevelsup" will cause a problem.  On my alpha this erases
> a portion in the address in the T_Expr. On the redhat 5.2/i386 this code seems to be
> benign, BUT YOU ARE ERASEING SOMETHING that doesn't belong to to T_Expr !
>
> So what gives?
> gat
> Maybe an assert() will help in finding some of the miscast returned types? Wuddya think?
> sure would catch some of the boo-boo's hanging around
>
> rewriteManip.c:
>               if (this_varno == info->new_varno &&
>                     this_varlevelsup == sublevels_up)
>                 {
>                     n = FindMatchingNew(targetlist,
>                                         ((Var *) node)->varattno);
>                     if (n == NULL)
>                     {
>                         if (info->event == CMD_UPDATE)
>                         {
>                             *nodePtr = n = copyObject(node);
>                             ((Var *) n)->varno = info->current_varno;
>                             ((Var *) n)->varnoold = info->current_varno;
>                         }
>                         else
>                             *nodePtr = make_null(((Var *) node)->vartype);
>                     }
>                     else
>                     {
>                         *nodePtr = copyObject(n);
>                        ((Var *) *nodePtr)->varlevelsup = this_varlevelsup;    /* This
> line zaps the address */
>                     }
>                 }
>
>
>
>
>
>
>


--
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Re: [PORTS] Re: [HACKERS] RedHat6.0 & Alpha

From
Bruce Momjian
Date:
This seems to be the detail on the bug report.


> Uncle George <gatgul@voicenet.com> writes:
> > In the regression test rules.sql there is this SQL command
> >         update rtest_v1 set a = rtest_t3.a + 20 where b = rtest_t3.b;
> > Which causes my alpha port to go core.
>
> Yeah.  This was reported by Pedro Lobo on 11 June, and we've been
> patiently waiting for Jan to decide what to do about it :-(
>
> You could stop the coredump by putting a test into ResolveNew:
>
>                     {
>                         *nodePtr = copyObject(n);
> +                       if (IsA(*nodePtr, Var))
>                             ((Var *) *nodePtr)->varlevelsup = this_varlevelsup;
>                     }
>
> but what's not so clear is what's supposed to happen when the
> replacement item *isn't* a Var.  I tried to convince myself that nothing
> needed to happen in that case, but wasn't successful.  (Presumably the
> replacement expression contains no instances of the variable being
> replaced, so recursing into it with ResolveNew shouldn't be needed
> --- but maybe its varlevelsup values need adjusted?)
>
>             regards, tom lane
>
>


--
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Re: [PORTS] RedHat6.0 & Alpha

From
Lamar Owen
Date:
Bruce Momjian wrote:
>
> Can anyone address the status of this bug?
[actual bug text snipped...]

Wow, Bruce.  That's an old thread.  I'll just say this -- 6.5.1 with
Uncle George and Ryan Kirkpatrick's patchset applied passes regression
at RedHat on their alpha development machine (for the RPM distribution).

Whether the current pre-6.6 tree passes regression or not, I can't say.

The author of the original message you replied to is gat -- AKA Uncle
George.

Lamar OWen
WGCR Internet Radio

Re: [HACKERS] Re: [PORTS] RedHat6.0 & Alpha

From
Tom Lane
Date:
Bruce Momjian <maillist@candle.pha.pa.us> writes:
> Can anyone address the status of this bug?

AFAIK it hasn't changed since July --- we've been waiting for Jan
to opine on the proper fix, but he's been busy...

            regards, tom lane

Re: [PORTS] Re: [HACKERS] RedHat6.0 & Alpha

From
Bruce Momjian
Date:
Any ideas on this one?

> Uncle George <gatgul@voicenet.com> writes:
> > In the regression test rules.sql there is this SQL command
> >         update rtest_v1 set a = rtest_t3.a + 20 where b = rtest_t3.b;
> > Which causes my alpha port to go core.
>
> Yeah.  This was reported by Pedro Lobo on 11 June, and we've been
> patiently waiting for Jan to decide what to do about it :-(
>
> You could stop the coredump by putting a test into ResolveNew:
>
>                     {
>                         *nodePtr = copyObject(n);
> +                       if (IsA(*nodePtr, Var))
>                             ((Var *) *nodePtr)->varlevelsup = this_varlevelsup;
>                     }
>
> but what's not so clear is what's supposed to happen when the
> replacement item *isn't* a Var.  I tried to convince myself that nothing
> needed to happen in that case, but wasn't successful.  (Presumably the
> replacement expression contains no instances of the variable being
> replaced, so recursing into it with ResolveNew shouldn't be needed
> --- but maybe its varlevelsup values need adjusted?)
>
>             regards, tom lane
>
>


--
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Re: [PORTS] Re: [HACKERS] RedHat6.0 & Alpha

From
Uncle George
Date:
I'm sorry, the resultant node as returned is not expected. The solution, as
provided,  did stop the insidious erasure of a field in a structure it did not own.
I'm content ( but i dont know any better )
If ur asking me what one is suppose to do at this point  - I dunno.
gat

Bruce Momjian wrote:

> Any ideas on this one?
>
> > Uncle George <gatgul@voicenet.com> writes:
> > > In the regression test rules.sql there is this SQL command
> > >         update rtest_v1 set a = rtest_t3.a + 20 where b = rtest_t3.b;
> > > Which causes my alpha port to go core.
> >
> > Yeah.  This was reported by Pedro Lobo on 11 June, and we've been
> > patiently waiting for Jan to decide what to do about it :-(
> >
> > You could stop the coredump by putting a test into ResolveNew:
> >
> >                     {
> >                         *nodePtr = copyObject(n);
> > +                       if (IsA(*nodePtr, Var))
> >                             ((Var *) *nodePtr)->varlevelsup = this_varlevelsup;
> >                     }
> >
> > but what's not so clear is what's supposed to happen when the
> > replacement item *isn't* a Var.  I tried to convince myself that nothing
> > needed to happen in that case, but wasn't successful.  (Presumably the
> > replacement expression contains no instances of the variable being
> > replaced, so recursing into it with ResolveNew shouldn't be needed
> > --- but maybe its varlevelsup values need adjusted?)
> >
> >                       regards, tom lane
> >
> >
>
> --
>   Bruce Momjian                        |  http://www.op.net/~candle
>   maillist@candle.pha.pa.us            |  (610) 853-3000
>   +  If your life is a hard drive,     |  830 Blythe Avenue
>   +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026
>
> ************


Re: [PORTS] Re: [HACKERS] RedHat6.0 & Alpha

From
Tom Lane
Date:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Any ideas on this one?

>> Uncle George <gatgul@voicenet.com> writes:
>>>> In the regression test rules.sql there is this SQL command
>>>> update rtest_v1 set a = rtest_t3.a + 20 where b = rtest_t3.b;
>>>> Which causes my alpha port to go core.
>>
>> Yeah.  This was reported by Pedro Lobo on 11 June, and we've been
>> patiently waiting for Jan to decide what to do about it :-(
>>
>> You could stop the coredump by putting a test into ResolveNew:
>>
>>           {
>>               *nodePtr = copyObject(n);
>> +             if (IsA(*nodePtr, Var))
>>                   ((Var *) *nodePtr)->varlevelsup = this_varlevelsup;
>>           }
>>
>> but what's not so clear is what's supposed to happen when the
>> replacement item *isn't* a Var.  I tried to convince myself that nothing
>> needed to happen in that case, but wasn't successful.  (Presumably the
>> replacement expression contains no instances of the variable being
>> replaced, so recursing into it with ResolveNew shouldn't be needed
>> --- but maybe its varlevelsup values need adjusted?)


That code currently reads like:

                /* Make a copy of the tlist item to return */
                n = copyObject(n);
                if (IsA(n, Var))
                {
                    ((Var *) n)->varlevelsup = this_varlevelsup;
                }
                /* XXX what to do if tlist item is NOT a var?
                 * Should we be using something like apply_RIR_adjust_sublevel?
                 */
                return n;

so it won't coredump when the tlist item is not a Var, but I'm not
convinced it does the right thing either.  Jan is the only man who
understands that code well enough to say what needs to be done about
it...

            regards, tom lane