[omniORB] OmniORB-4.2.2 compiled with gcc8 and C++14 leads into crash

Prasath_Palaniappan at amat.com Prasath_Palaniappan at amat.com
Mon Mar 25 06:19:08 GMT 2019


Hi,

Thanks in advance.

We have been using OmniORB-4.2.2 in our project to establish client/server communication. Earlier we compiled the entire project with "gcc4.8 and C++14".
So that we compiled the OmniORB-4.2.2 source with same "gcc4.8 and C++14" and were using that with our project. It was working properly without any issue.
That means we are able to receive the request through OmniORB-4.2.2 from OmniClient, process the request with application, retrieve the response from application and send the response to OmniClient.

But now for project need, we have upgraded the compiler and std library from "gcc4.8 and C++14" to "gcc8 and C++17". So that we compiled the source OmniORB-4.2.2 with "gcc8 and C++17".
We are using the following Omni libraries and binary in our project,

  *   libomniORB422.a
  *   libomniDynamic422.a
  *   libomnithread40.a
  *   omniidl

We tested the project (Our Application + OmniORB-4.2.2) which is completely compiled with "gcc8 and C++17". But the process got crashed with terminate caught due to throwing dynamic exception on communication failure.
OmniORB server is able to receive the request from OmniClient, process the request with application and get the response from application but it is getting crashed on sending the chunk to OmniClient.
Please find the traces and stack below,

18/03/2019 10:22:35.443
CORBA: Omni: Number of columns from dlis reply: 9
CORBA: Omni: Number of rows from dlis reply: 43
CORBA: Omni: Sent reply to SiView client
CORBA: Omni retVal->systemErrorCode: 0
CORBA: Omni retVal->systemErrorMessage: no error
CORBA: Omni retVal->userErrorCode: 0
CORBA: Omni retVal->userErrorMessage:: no error
CORBA: Omni retVal->dispatchErrorMessage:
CORBA: Omni retVal->numberRows: 43
CORBA: Omni retVal->numberCols: 9
omniORB: sendChunk: to giop:tcp:[::ffff:10.41.46.93]:33260 4656 bytes
omniORB:
4749 4f50 0102 0001 0000 1224 0000 0004 GIOP.......$....
0000 0000 0000 0000 0000 002b 0000 0009 ...........+....
0000 0002 3000 0000 0000 0009 6e6f 2065 ....0.......no e
7272 6f72 0000 0000 0000 0002 3000 0000 rror........0...
0000 0009 6e6f 2065 7272 6f72 0000 0000 ....no error....
0000 0001 0000 0000 0000 002b 0000 0009 ...........+....
0000 0001 0000 0000 0000 0005 5761 6974 ............Wait
....
0000 0008 494e 5445 4745 5200 0000 0007 ....INTEGER.....
5354 5249 4e47 0000 0000 0007 5354 5249 STRING......STRI
4e47 0000 0000 0007 5354 5249 4e47 0000 NG......STRING..
0000 0008 494e 5445 4745 5200 0000 0000 ....INTEGER.....
omniORB: giopWorker task execute.
omniORB: inputMessage: from giop:tcp:[::ffff:10.41.46.93]:33260 12 bytes
omniORB:
4749 4f50 0102 0005 0000 0000           GIOP........
omniORB: Orderly connection shutdown: giop:tcp:[::ffff:10.41.46.93]:33260
omniORB: throw giopStream::CommFailure from giopImpl12.cc:1243(0,NO,COMM_FAILURE_UnMarshalArguments)
Terminate caught

Pstack:
0x0000000100b4960c  handleSignalFatal(??, ??, ??) + 0x20
<signal>
0x090000000056ff14  pthread_kill(??, ??) + 0xd4
0x090000000056f764  _p_raise(??) + 0x44
0x09000000000393e8  raise(??) + 0x48
0x0900000000055de4  abort() + 0xc4
0x00000001001d4198  _ZN12_GLOBAL__N_115catch_terminateEv() + 0xcc
0x0000000100018268  _ZN10__cxxabiv111__terminateEPFvvE(??) + 0x24
0x00000001000093b4  _ZSt9terminatev() + 0x14
0x0000000100017eac  __cxa_throw(??, ??, ??) + 0x6c
0x00000001014b7314  _ZN4omni10giopStream11CommFailure6_raiseEjN5CORBA16CompletionStatusEbPKcjS5_PNS_10giopStrandE(??, ??, ??, ??, ??, ??, ??) + 0x1dc
0x00000001025b7d44  _ZN4omni10giopImpl1221inputRaiseCommFailureEPNS_10giopStreamEPKc(??, ??) + 0xa4
0x00000001025ba1a0  _ZN4omni10giopImpl1230unmarshalWildCardRequestHeaderEPNS_10giopStreamE(??) + 0x84
0x00000001025ba45c  _ZN4omni10giopImpl1217inputMessageBeginEPNS_10giopStreamEPFvS2_E(??, ??) + 0x11c
0x00000001014d1834  _ZN4omni6GIOP_S10dispatcherEv(??) + 0x88
0x00000001015045d8  _ZN4omni10giopWorker7executeEv(??) + 0x54
0x0000000101502394  _ZN15omniAsyncWorker8real_runEv(??) + 0xf4
0x0000000101503db4  _ZN19omniAsyncPoolServer9workerRunEP15omniAsyncWorker(??, ??) + 0x28
0x0000000101501e64  _ZN15omniAsyncWorker7mid_runEv(??) + 0x68
0x0000000101503808  _ZN15omniAsyncWorker3runEPv(??, ??) + 0xe8
0x0000000101458f08  omni_thread_wrapper(??) + 0x154

Earlier Application + OmniORB-4.2.2 compiled with "gcc4.8 and C++14" is also throwing the same communication failure on sending response to OmniClient but it does not lead the process into crash and works properly with below traces,
omniORB: throw giopStream::CommFailure from giopImpl12.cc:1243(0,NO,COMM_FAILURE_UnMarshalArguments)
omniORB: Server connection giop:tcp:[::ffff:10.41.46.93]:33981 refcount = 1
omniORB: Server connection giop:tcp:[::ffff:10.41.46.93]:33981 refcount = 0
omniORB: Server close connection from giop:tcp:[::ffff:10.41.46.93]:33981
omniORB: SocketCollection idle. Sleeping.
omniORB: Scan for idle connections (1552469237,436079000)
omniORB: Scan for idle connections done (1552469237,436079000)

We tried to find out the solution to this problem and found below suggestions,

  *   Catch the exception in application code - It is not possible in our project since omniorb will be running as a separate service. Omni will communicate with our application through the interface provided in idl file.
  *   Turnoff the exception - We commented out the exception throw code at line number:512 in "src\lib\omniORB\orbcore\giopStream.cc"

throw CommFailure(minor,status,retry);

                With Commenting out the above code, project works fine as expected and OmniORB sends response to OmniClient without any crash. Log snippet with commenting out the above code,
omniORB: Orderly connection shutdown: giop:tcp:[::ffff:10.41.46.93]:39501
omniORB: throw giopStream:: CommFailure from giopImpl12.cc:1247(0,NO,COMM_FAILURE_UnMarshalArguments)
omniORB: Unexpected message type (5) received by a server thread at GIOP_S.cc: line 166
omniORB: Server connection giop:tcp:[::ffff:10.41.46.93]:39501 refcount = 1

Could you please guide us whether commenting out the exception is right solution? Or what has to be done to get rid of this issue?

Thanks & Regards,
P. Prasath.

The content of this message is APPLIED MATERIALS CONFIDENTIAL. If you are not the intended recipient, please notify me, delete this email and do not use or distribute this email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20190325/a50ec60e/attachment-0001.html>


More information about the omniORB-list mailing list