[PolyORB-users] Re: Error passing float sequence to server

[Will Normand]

> Can you please detail your setup ? if you are using the CVS version,
> you'll find the a form in doc/PROBLEM-REPORT-FORM
Running SuSE Linux, kernel 2.4.20-64GB-SMP on i686.
GNAT 3.4.1
polyorb-1.2r

> > I am receiving the following error:
> > raised CONSTRAINT_ERROR :
> > polyorb-sequences-unbounded-corba_helper.adb:117 range check failed
> > 
> > This occurs when my client tries to call a procedure on the server.
> > The procedure passes a sequence of floats to the server.
> 
> Humm, from the remaining of your post, it seems that the exception is
> triggered on the client side, right ?
Yes.

> > >From the client code:
> > 
> > declare
> >         Seq : Corbabenchmarks.FloatSeq;
> > begin
> >         Seq := Corbabenchmarks.To_Sequence(Payload);
> >         Corbabenchmarks.Replace_Element(Seq, Payload, 1.0);
> >         Corbabenchmarks.Server.FloatIn(Myserver, Seq);
> > end;
> > 
> > The IDL file includes:
> > 
> > module corbaBenchmarks {
> >         typedef sequence<float> FloatSeq;
> >         typedef sequence<long> IntSeq;
> >         interface Server {
> >                 void floatIn(in FloatSeq data);
> >                 void intIn(in IntSeq data);
> >         }
> > }
> > 
> > The strange thing is that this error only occurs with certain payloads
> > (length of float sequence).  The majority of sequence lengths work.
> 
> Can you please detail the values that cause this problem ?
> Is there a threshold that triggers it ?
Using the Orbacus Name Server, a number of floats in the ranges 31--42
and 123--134 causes the problem.  No other payloads up to 2000 floats
produce the error.

Using the po_cos_naming errors occur in the range 175--200.  

> > Also, even if the Server is no longer running --- though still
> > registered on the Name Server, so a reference can be returned --- this
> > error still occurs, so CORBA.COMM_FAILURE is not raised.  So the error
> > seems to occur in the call Corbabenchmarks.Server.FloatIn(Myserver,
> > Seq), but before the procedure is actually called on the server.
> 
> and before the request is actually issued by the client, AFAICT
Yes, I think so.

> We can tell more when you complete some elements, thanks
Thanks,
Will