[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 12:05:40 GMT 2006
Something goes on...
Acorrdingly to suggestions:
"Most likely the problem is your code. Blow ups in malloc are most
likely due to one of the following: 1. writing outside of the
malloc'd area. 2. Calling free on something not malloc'd 3.
calling free multiple times on the same allocation "
so, I started to correct hints given by valgrind in memory corruption"
Ther was some: ==11395== Mismatched free() / delete / delete []
==11395== Invalid free() / delete / delete[]
and after corrections the problem appiering in code many lines after -
was reslved. Now program work without segfault.
Thaks.
Radek
Quoting radamkie at kdm.pl:
> 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
>>
>
>
>
>
> _______________________________________________
> omniORB-list mailing list
> omniORB-list at omniorb-support.com
> http://www.omniorb-support.com/mailman/listinfo/omniorb-list
>
More information about the omniORB-list
mailing list