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

radamkie at kdm.pl radamkie at kdm.pl
Wed Mar 15 11:24:36 GMT 2006


Gdb was helpfull to recognize that SEGV is received by executing line ..
p = (void *) malloc (sz);
..
in function defining operator new in base gcc compiler file 
...gcc-2.95.2/gcc/cp/new1.cc

See below extract from gdb:
...
__builtin_new (sz=8) at ../../gcc/cp/new1.cc:75
75        if (sz == 0)
(gdb) n
77        p = (void *) malloc (sz);
(gdb) n

Program received signal SIGSEGV, Segmentation fault.
0x0049eabe in _int_malloc () from /lib/tls/libc.so.6
....

Valgrind gives only such hints some time before segfault, but I dont 
understand , what can be done with them:

==11395== Invalid read of size 4
==11395==    at 0x40F34DF: omniORB::logger::operator<<(char const *) 
(in /home/radamkie/omniORB-4.1.0-beta1/build/lib/libomniO
RB4.so.1.0)
==11395==    by 0x40F4499: pp_key(omniORB::logger &, unsigned char 
const *, int) (in /home/radamkie/omniORB-4.1.0-beta1/build/
lib/libomniORB4.so.1.0)
==11395==    by 0x40F3A95: omniORB::logger::operator<<(omniIdentity 
const *) (in /home/radamkie/omniORB-4.1.0-beta1/build/lib/
libomniORB4.so.1.0)
==11395==    by 0x4136F51: 
omniRemoteIdentity::locateRequest(omniCallDescriptor &) (in 
/home/radamkie/omniORB-4.1.0-beta1/buil
d/lib/libomniORB4.so.1.0)
==11395==    by 0x410D4DB: omniObjRef::_locateRequest(void) (in 
/home/radamkie/omniORB-4.1.0-beta1/build/lib/libomniORB4.so.1.
0)
==11395==    by 0x4109AA2: 
omniObjRef::_assertExistsAndTypeVerified(void) (in 
/home/radamkie/omniORB-4.1.0-beta1/build/lib/lib
omniORB4.so.1.0)
==11395==    by 0x410AD2C: omniObjRef::_invoke(omniCallDescriptor &, 
bool) (in /home/radamkie/omniORB-4.1.0-beta1/build/lib/li
bomniORB4.so.1.0)
==11395==    by 0x41A97D3: 
CosNaming::_objref_NamingContext::bind(CosNaming::Name const &, 
CORBA::Object *) (in /home/radamkie
/omniORB-4.1.0-beta1/build/lib/libomniORB4.so.1.0)

==11395==  Address 0x5162868 is 16 bytes inside a block of size 19 alloc'd
==11395==    at 0x401AC85: __builtin_vec_new 
(m_replacemalloc/vg_replace_malloc.c:190)
==11395==    by 0x40F437E: pp_key(unsigned char const *, int) (in 
/home/radamkie/omniORB-4.1.0-beta1/build/lib/libomniORB4.so.
1.0)
==11395==    by 0x40F4488: pp_key(omniORB::logger &, unsigned char 
const *, int) (in /home/radamkie/omniORB-4.1.0-beta1/build/
lib/libomniORB4.so.1.0)
==11395==    by 0x40F3A95: omniORB::logger::operator<<(omniIdentity 
const *) (in /home/radamkie/omniORB-4.1.0-beta1/build/lib/
libomniORB4.so.1.0)
==11395==    by 0x4136F51: 
omniRemoteIdentity::locateRequest(omniCallDescriptor &) (in 
/home/radamkie/omniORB-4.1.0-beta1/buil
d/lib/libomniORB4.so.1.0)
==11395==    by 0x410D4DB: omniObjRef::_locateRequest(void) (in 
/home/radamkie/omniORB-4.1.0-beta1/build/lib/libomniORB4.so.1.
0)
==11395==    by 0x4109AA2: 
omniObjRef::_assertExistsAndTypeVerified(void) (in 
/home/radamkie/omniORB-4.1.0-beta1/build/lib/lib
omniORB4.so.1.0)
==11395==    by 0x410AD2C: omniObjRef::_invoke(omniCallDescriptor &, 
bool) (in /home/radamkie/omniORB-4.1.0-beta1/build/lib/li
bomniORB4.so.1.0)
==11395==    by 0x41A97D3: 
CosNaming::_objref_NamingContext::bind(CosNaming::Name const &, 
CORBA::Object *) (in /home/radamkie
/omniORB-4.1.0-beta1/build/lib/libomniORB4.so.1.0)
==11395==    by 0x8169473: 
CorbaUtils::bindObjectToName(basic_string<char, 
string_char_traits<char>, __default_alloc_template<
true, 0> > const &, CORBA::Object *) (CorbaUtils.cc:175)

Regards
Radek


Quoting Harri Pasanen <harri.pasanen at trema.com>:

> In the valgrind output you should not be interested in leaks,
> but possible hints to memory corruption etc.
>
> Look for all the lines in valgrind output that start with
>
> ==
>
> Typically the bad free/access happened quite some time before
> the segfault.
>
> -Harri
>
>
> On Tuesday 14 March 2006 19:29, radamkie at kdm.pl wrote:
>> 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 --
>>
>> _______________________________________________
>> omniORB-list mailing list
>> omniORB-list at omniorb-support.com
>> http://www.omniorb-support.com/mailman/listinfo/omniorb-lis
>> t
>
>
> Privileged or confidential information may be contained in this 
> message.  If you are not the addressee of this message please notify 
> the sender by return and thereafter delete the message, and you may 
> not use, copy, disclose or rely on the information contained in it. 
> Internet e-mail may be susceptible to data corruption, interception 
> and unauthorised amendment for which Trema does not accept liability. 
> Whilst we have taken reasonable precautions to ensure that this 
> e-mail and any attachments have been swept for viruses, Trema does 
> not accept liability for any damage sustained as a result of viruses. 
>  Statements in this message or attachments that do not relate to the 
> business of Trema are neither given nor endorsed by the company or 
> its directors. A list of Trema's directors is available on our web 
> site: www.trema.com
>






More information about the omniORB-list mailing list