[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