[omniORB] omni::giopRope::match() crash

Michael Teske subscribe at teskor.de
Tue Apr 7 17:09:37 BST 2015


Hi,

did you ever resolve this problem?  I had the same right now with omniORB 4.2:

(gdb) where
#0  0x00000005 in ?? () 
#1  0xf7f22d4f in omni::giopRope::match (this=0xf214b728, addrlist=..., info=0x8af0088) at giopRope.cc:647
#2  0xf7f23ef4 in omni::giopRope::selectRope (addrlist=..., info=0x8af0088, rope=@0xf4883c4c, is_local=@0xf4883c47) at giopRope.cc:588
#3  0xf7ee4e4a in omni::createIdentity (ior=0xe7dba388, target=0xf7f76465 "IDL:omg.org/CORBA/Object:1.0", locked=false) at omniInternal.cc:734
#4  0xf7ee6b09 in omni::createObjRef (targetRepoId=0xf7f76465 "IDL:omg.org/CORBA/Object:1.0", ior=0xe7dba388, locked=false, id=0x0) at omniInternal.cc:810
#5  0xf7f15933 in omni::corbalocURIHandler::locToObject (c=@0xf488401c, cycles=0, def_key=0x0) at uri.cc:889
#6  0xf7f16c86 in omni::corbalocURIHandler::toObject (this=0xf7fced34, uri=0x8a525ac "corbaloc::sbz1:5572/ExchangeAgent", cycles=0) at uri.cc:488
#7  0xf7f142f4 in omni::omniURI::stringToObject (uri=0x8a525ac "corbaloc::sbz1:5572/ExchangeAgent", cycles=0) at uri.cc:277
#8  0xf7eb5be1 in omniOrbORB::string_to_object (this=0x8a38238, uri=0x8a525ac "corbaloc::sbz1:5572/ExchangeAgent") at corbaOrb.cc:426
#9  0x0807b4da in UsedEA::run (this=0x8a525d8) at /home/build/Builds/Trader-build857/Trader/src/LoginServer/EAInfo.cpp:500
#10 0x0808215e in tools::P0Hook<UsedEA>::run (this=0x8a526e8) at /home/build/Builds/Trader-build857/Trader/include/tools/ThreadHook.hpp:41
#11 0x081c54d8 in omniJTCThread::entrance_hook (this=0x8a526e8) at /home/build/Builds/Trader-build857/Trader/src/libomniJTC/Thread.cpp:772
#12 0x081c5612 in lsf_thread_adapter (arg=0x8a526e8) at /home/build/Builds/Trader-build857/Trader/src/libomniJTC/Thread.cpp:85
#13 0xf7fd3edc in omni_thread_wrapper (ptr=0x8a52990) at posix.cc:447
#14 0x0036e912 in start_thread () from /lib/libpthread.so.0
#15 0x002ad7ce in clone () from /lib/libc.so.6

(gdb) p i
$1 = <value optimized out>

(unfortunately we used -O2). But:

(gdb) p addrlist
$2 = (const omni::giopAddressList &) @0x8af008c: {
  start = 0x8d922d0,
  finish = 0x8d922d4,
  end_of_storage = 0x8d922d4
}

(gdb) p *(*addrlist->start)
$6 = (omni::tcpAddress) {
  <omni::giopAddress> = {
    _vptr.giopAddress = 0xf7fca788
  },
  members of omni::tcpAddress:
  pd_address = {
    host = {
      _ptr = 0x8d3feb8 "sbz1"
    },
    port = 5572
  },
  pd_address_string = {
    _data = 0x8ca90f0 "giop:tcp:sbz1:5572"
  }
}

looks ok to me.

Same here:

(gdb) p pd_addresses
$11 = {
  start = 0xf21a0b80,
  finish = 0xf21a0b88,
  end_of_storage = 0xf21a0b88
}

(gdb) p *(*pd_addresses.start)
$8 = (omni::tcpAddress) {
  <omni::giopAddress> = {
    _vptr.giopAddress = 0xf7fca788
  },
  members of omni::tcpAddress:
  pd_address = {
    host = {
      _ptr = 0xf21fa5c0 "sbz1"
    },
    port = 5571
  },
  pd_address_string = {
    _data = 0xe7dba018 "giop:tcp:sbz1:5571"
  }
}

(gdb) p *(*(pd_addresses.start+1))
$10 = (omni::tcpAddress) {
  <omni::giopAddress> = {
    _vptr.giopAddress = 0xf7fca788
  },
  members of omni::tcpAddress:
  pd_address = {
    host = {
      _ptr = 0xf218a848 "192.168.68.194"
    },
    port = 5571
  },
  pd_address_string = {
    _data = 0xe7dba400 "giop:tcp:192.168.68.194:5571"
  }
}


I can't see anything obviously wrong here. Maybe other threads?

At the moment it seems reproducible, maybe I can test some more?
If I add
-ORBtraceLevel 25 -ORBtraceThreadId 1 -ORBtraceTime 1
to the start parameters, it doesn't crash. Missing mutex somewhere?

Thanks for any help,
  Michael



Am 16.09.14 um 19:42 schrieb Duncan Grisby:
> On Fri, 2014-09-12 at 19:20 -0500, Michael Lim wrote:
>> More update to the omni:giopRope::match() crash... 
> 
> [...]
> 
>> pd_addresses
>>  start  0x10062170 (contains 0x20202020)
>>  finish 0x10062180 (contains 0xE9000003)
>>
>> 00000000  20 20 20 20 54 20 20 20 10 93 86 c0 10 06 21 88  |    T
>>  ......!.|
>> 00000010  e9 00 00 03 00 00 00 19  0f 6c 30 e0 10 05 cb 38
>>  |.........l0....8|
>>
>> So that lead to the crash.  The question right now is how/when/where
>> pd_addresses is getting initialized? 
>>
> Are you able to reproduce the problem with a debug build of omniORB?
> Edit src/lib/omniORB/orbcore/dir.mk and uncomment the line that sets
> 
> CXXDEBUGFLAGS = -g
> 
> That will make it easier to see what is going on. It might also reveal
> something useful to run with lots of omniORB tracing:
> 
> -ORBtraceLevel 25 -ORBtraceThreadId 1 -ORBtraceTime 1
> 
> 
> Duncan.
> 




More information about the omniORB-list mailing list