Re: [Firebird-devel] Grant bug

[Neil M. <nm...@zi...>]

On Sat, Dec 08, 2001 at 09:08:03PM -0400, Claudio Valderrama C. wrote:
> >
> > I do not have a fix but I can reproduce the problem with LI-T1.0.0.655
> > Classic and point to the area of code causing the problem which may
> > help.
> 
> 
> Is there any chance that GPRE doesn't work the same depending on classic v/s
> SS? Although Ded found the problem in WI-T6.2.632.
> 

I don't have a SS build around a the moment to try but as it happens on
Win I would doubt it.

> 
> Pay attention to the structs that GPRE defined at the beginning of
> set_field_class_name:
> 
>    struct {
>           TEXT  jrd_12 [32];	/* RDB$SECURITY_CLASS */
>    } jrd_11;
> [snip]
>    struct {
>           TEXT  jrd_20 [32];	/* RDB$SECURITY_CLASS */
>           SSHORT jrd_21;	/* gds__utility */
>           SSHORT jrd_22;	/* gds__null_flag */
>    } jrd_19;
> 

 Both the same here.

> Now, let's see the call:
> 
> >     gds__vtov (jrd_19.jrd_20, jrd_11.jrd_12, 32);
> 
> At least in my case (my generated DYN.C), I see that both source and target
> at 32 bytes.
> 
> >     EXE_start (tdbb, (REQ)request2, gbl->gbl_transaction);
> >     EXE_send (tdbb, (REQ)request2, 0, 32, (UCHAR*)&jrd_11);
> 
> Here, jrd_11 was passed completely, but this struct has only jrd_12 inside
> that a string of 32 bytes. Don't understand what's the supposed mismatch.
> 
[snip end of proc]
> 
> > In EXE_send it has a test which compares the length passed in as a
> > parameter 32 and the expected length of the of the statement in the node
> > it finds in request2 which in this case is 64. The 32 matches the size
> > of jrd_11 so looks correct.
> 
> What's 64, Neil. I can't see it. Does your GPRE generates different struct
> definitions?
> 

In EXE_send

if (length != format->fmt_length)
	ERR_post (gds__port_len,.....
 
with values  32 != 64

In a new isql session this happens on the second field, once failed if
you try running the grant again it fails on the first field.


-- 
Neil McCalden                @home     nm...@zi...