[omniORB] SEGV on Red Hat Enterprise Linux AS release 3 in servant_to_reference

radamkie at kdm.pl radamkie at kdm.pl
Tue Mar 14 19:29:34 GMT 2006


I tried to change code as follows

poa->activate_object_with_id(oid, this);
...
CosNaming::Name  leaf;
/***/leaf.length(1);
...
context->bind(leaf, ref);

but received also segmentation fault, generated by following
line in file ..../include/omniORB4/seqTemplatedecls.h

tmp = new T[nelems];

in function allocbuf(..), called by copybuffer(..), called by length(..)

CosNaming::Name , as I think is defined as follows:

module CosNaming {

  typedef string Istring;

  struct NameComponent {
    Istring id;
    Istring kind;
  };

  typedef sequence<NameComponent> Name; ....

But how "sequence" is defined .... black magic. How it is related to 
class _CORBA_Sequence ?in ..../include/omniORB4/seqTemplatedecls.h ?
What could be the problem?

Valgrind is now hard to analize for me, but I dont see anything, that 
could correspond to length() function there.
This is summary leak.
==11395== LEAK SUMMARY:
==11395==    definitely lost: 218 bytes in 28 blocks.
==11395==      possibly lost: 5,984 bytes in 29 blocks.
==11395==    still reachable: 523,432 bytes in 2,199 blocks.


Regards
Radek


Quoting Duncan Grisby <duncan at grisby.org>:

> On Thursday 9 March, radamkie at kdm.pl wrote:
>
>> I have problem with Segmentation fault by migration omniORB
>> application from SunOS Sparc platform to Linux ix86 platform. On the
>> first everything goes allright. I use there omniORB4.0.3. By migration
>> on Linux platform I tested the same application with omniORB4.0.3 but
>> also with omniORB4.1.0. In both cases I receive Segmentation fault
>> error in this place (marked by ***)
>
> It looks like the servant has been deleted, so I guess you have a
> reference counting problem. You might try running your program inside
> valgrind. That will probably tell you where thing went wrong.
>
> Cheers,
>
> Duncan.
>
> --
> -- Duncan Grisby         --
>  -- duncan at grisby.org     --
>   -- http://www.grisby.org --
>






More information about the omniORB-list mailing list