Stub returns non-NULL return value even when a CORBA server isn't available.

Hello,

  When I call a method of a CORBA server, but that server is
down, I still
  get a return value that is non-NULL. Stub code declares
return value as a
  pointer and doesn't set it to NULL. Later, the code that
is called from
  stub doesn't change that ret variable, as a result,
whatever uninitialized
  value was there in the beginning, is returned to client
code.

Here's stub code:
/*
 * This file was generated by orbit-idl-2 - DO NOT EDIT!
 */

#include <string.h>
#include <stdio.h>
#define ORBIT2_STUBS_API
#include "cmd.h"

Cmd_OctetSeq* Cmd_run_cmd(Cmd _obj, const CORBA_char * cmd,
const Cmd_StringSeq* argv, const Cmd_OctetSeq* input,
CORBA_Environment *ev){
Cmd_OctetSeq* _ORBIT_retval;
gpointer _args[3];
_args[0] = (gpointer)&cmd;
_args[1] = (gpointer)argv;
_args[2] = (gpointer)input;

printf("stub start: %p, %pn", _ORBIT_retval,
&_ORBIT_retval);
ORBit_c_stub_invoke (_obj, &Cmd__iinterface.methods, 0,
&_ORBIT_retval, _args, NULL, ev, Cmd__classid,
G_STRUCT_OFFSET (POA_Cmd__epv, run_cmd),
(ORBitSmallSkeleton) _ORBIT_skel_small_Cmd_run_cmd);
printf("after ORBit_c_stub_invoke: %pn",
_ORBIT_retval);

return _ORBIT_retval;
}

This behaviour was introduced somewhere after 2.12.2, the
version I used for
the above testing was 2.14.3.

Because of that behaviour, it's now necessary to check
whether exception has
happened, before releasing memory. In 2.12.2 it was
sufficient to check
whether pointer is non-NULL.

-- 
/Dmitry <dmaksesphion.com>
_______________________________________________
orbit-list mailing list
orbit-listgnome.org
htt
p://mail.gnome.org/mailman/listinfo/orbit-list

Hi Dmitry,


On Tue, 2007-09-25 at 18:07 +1200, Dmitry Maksyoma wrote:
> Hello,
> 
>   When I call a method of a CORBA server, but that
server is down, I still
>   get a return value that is non-NULL. 

You should get an exception if the server is down. A TIMEOUT
or a
TRANSIENT is the most normal in this case depending on how
the server is
down. Section 1.2.2 in the CORBA spec (both 2.3 and 3.2)
says in
excerpts:

"The return result and the values stored into the
output and
input-output parameters are undefined if an exception is
returned"

So ORBit2 can do whatever it wants to the return value and
it is still
standards compliant.

HTH,
  jules




> Stub code declares return value as a
>   pointer and doesn't set it to NULL. Later, the code
that is called from
>   stub doesn't change that ret variable, as a result,
whatever uninitialized
>   value was there in the beginning, is returned to
client code.
> 
> Here's stub code:
> /*
>  * This file was generated by orbit-idl-2 - DO NOT
EDIT!
>  */
> 
> #include <string.h>
> #include <stdio.h>
> #define ORBIT2_STUBS_API
> #include "cmd.h"
> 
> Cmd_OctetSeq* Cmd_run_cmd(Cmd _obj, const CORBA_char *
cmd, const Cmd_StringSeq* argv, const Cmd_OctetSeq* input,
CORBA_Environment *ev){
> Cmd_OctetSeq* _ORBIT_retval;
> gpointer _args[3];
> _args[0] = (gpointer)&cmd;
> _args[1] = (gpointer)argv;
> _args[2] = (gpointer)input;
> 
> printf("stub start: %p, %pn", _ORBIT_retval,
&_ORBIT_retval);
> ORBit_c_stub_invoke (_obj,
&Cmd__iinterface.methods, 0, &_ORBIT_retval, _args,
NULL, ev, Cmd__classid, G_STRUCT_OFFSET (POA_Cmd__epv,
run_cmd),
> (ORBitSmallSkeleton) _ORBIT_skel_small_Cmd_run_cmd);
> printf("after ORBit_c_stub_invoke: %pn",
_ORBIT_retval);
> 
> return _ORBIT_retval;
> }
> 
> This behaviour was introduced somewhere after 2.12.2,
the version I used for
> the above testing was 2.14.3.
> 
> Because of that behaviour, it's now necessary to check
whether exception has
> happened, before releasing memory. In 2.12.2 it was
sufficient to check
> whether pointer is non-NULL.
> 

_______________________________________________
orbit-list mailing list
orbit-listgnome.org
htt
p://mail.gnome.org/mailman/listinfo/orbit-list