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

[Michael Lim]

We are using omni version 4.1.6 on powerpc using linux os. Occasionally,
giopRope::match() crashed. Has any one seen this similar problem?
Here are trace stack from the core file.

Thread [8] (Suspended)
30 kill() 0x0f77c0b4
29 perc_sighandler() perc.C:636 0x0febbf84
28 <signal handler called>() 0x00100370
27 omni::giopRope::match(omnivector<omni::giopAddress*> const&) const()
0x0f5f0380
26 omni::giopRope::selectRope() 0x0f5f2150
25 omni::createIdentity() 0x0f5b69bc
24 omni::createObjRef() 0x0f5b7358
23 omniObjRef::_unMarshal() 0x0f5be8d0
22 CORBA::Object::_unmarshalObjRef() 0x0f582068
21 _0RL_cd_69ceca6a39f685b5_80000000::unmarshalReturnedValues()
0x0f63a81c
20 omniRemoteIdentity::dispatch() 0x0f5dd248
19 omniObjRef::_invoke() 0x0f5bf270
18 CosNaming::_objref_NamingContext::resolve() 0x0f63ca64
17 forb::FipsORBClient::getObjectRefFromNameServer() forblibclient.C:344
0x0f02d02c
16 forb::FipsORBClient::waitForServerReady() forblibclient.C:153
0x0f02d284
15 forb::FipsORBClient::getObjectReference() forblibclient.C:269
0x0f02d6bc
14 forb::AppClient::getObjectRef<BridgeSvc,
_CORBA_ObjRef_Var<_objref_BridgeSvc, BridgeSvc_Helper> >()
forbappclient.H:149 0x0deafe10
13 popBridgeSvc() rmgrClientLibPrivate.H:283 0x0dead378
12 rmgrInvokeRemoteCommand_DL() rmgrClientLib.C:1490 0x0dead444
11 rmgrInvokeRemoteCommand() rmgrWrapClientLib.C:690 0x0fd33f94
10 DumpUtilFile::open() dumpUtilFile.C:113 0x0ef451c8
9 DumpSummary::DumpSummary() dumpSummary.C:254 0x0ef4e048
8 dumpInitiateDump::requestDump() dumpInitiateDump.C:360 0x0fd876c4
7 panlDumpSystem() panlactions.C:1226 0x1000ad74
6 PanlFunction::execute() panlfunction.C:2786 0x1000d85c
5 panlExecutePanelFunction() panlwork.C:1723 0x1000f298
4 PanlWorkMsg::doWork() panlworkmsg.C:109 0x10010524
3 panlWorkerThread() panlworkqueue.C:154 0x10010a68
2 start_thread() pthread_create.c:303 0x0fbdf2b8
1 clone() 0x0f83cddc

Any info will be appreciated.



Best Regards,
Michael Y. Lim

PFD CHARM Execution Lead
Office: 045/C-08
Tie Line: 363-7244
Phone: [phone]
email: youhour at us.ibm.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20140909/864bfdd4/attachment.html>

[Michael Lim]

More update to the omni:giopRope::match() crash...

I looked at the core dump file and here is what is in the match()
function.

The addrlist looks correct.
The list locate at 0x10057324
Start 0x10056d80 (contains address 0x10056C98)
finish 0x10056d90 (contains address 0x02000003)
00000000 10 05 6c 98 10 05 78 d0 10 05 6b c0 10 05 78 98
|..l...x...k...x.|
00000010 02 00 00 03 00 00 00 19 00 00 00 01 00 00 00 01
|................|

Looking in giopRope::selectRope() function
p = giopRope::ropes.next
if p is valid
gr=p
then calling gr->match()
pd_addresses is a list within gr..

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?


Best Regards,
Michael Y. Lim

PFD CHARM Execution Lead
Office: 045/C-08
Tie Line: 363-7244
Phone: [phone]
email: youhour at us.ibm.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20140912/b451d2a9/attachment.html>

[Duncan Grisby]

Post by Michael Lim
More update to the omni:giopRope::match() crash...

[...]

Post by Michael Lim
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.