[omniORB] omniAsyncWorker issue in OmniORB version 4.0.1

[Gurminder Singh]

Hi All,



We are using OmniORB version 4.0.1 in our multi threaded server
application (solaris 8 platform).

The application tends to crash say about once a week in the production
environment.

We have not been able to reproduce it in our test environment.

The thread stack from the core file is shown below:


fdd9fb84 _lwp_kill (6, 0, f977ac10, fe1b5434, 1, f977ac5c) + 8
fdd36d10 abort (f8486a98, 4, fe1cf0b8, 15360, 1, f8486a98) + 100
fe1b504c __1cH__CimplRdefault_terminate6F_v_ (f8486a9c, 4, fe1cf0b8,
15360, 1, fe1b5048) + 4
fe1b5060 __1cH__CimplSdefault_unexpected6F_v_ (f8486a98, fe1b505c,
f8486a98, fe1cb080, 1, 1) + 4
fe1b4fd8 __1cH__CimplNex_unexpected6F_v_ (f977ade0, fe1b707c, fe1caf8c,
fe1cb080, fe1ca780, 1) + 14
fe1b5edc __1cG__CrunRex_chk_unexpected6F_v_ (fe1cae64, fe1b707c,
fe1cae68, 14df8, 14928, 0) + 88
fe1b707c __1c2n6FI_pv_ (100000, fe3abe1c, 500000, 13798, fe1ca780, 0) +
98
ff23cdfc __1cP_CORBA_Sequence4CC_Kcopybuffer6ML_v_ (f8551af8, 100000,
ffffffff, 1704f7c, 0, f85becae) + 4
ff23c040 __1cP_CORBA_Sequence4CC_Glength6ML_v_ (f8551af8, 100000,
100000, 1, f86398d4, fe3abd78) + 70
ff23b24c __1cV_CORBA_Sequence_Octet2L6MrnJcdrStream__v_ (f8551af8,
f86398d4, 3, 13798, fe1ca780, f8551af8) + 68
ff2357e8
__1cbH_0RL_cd_0e4d908b42cfa273_80000000SunmarshalArguments6MrnJcdrStream
__v_ (f977b87c, f86398d4, b8b6c, ff3501d0, ff2357bc, ff00) + 2c
fe307f00 __1cEomniGGIOP_SOReceiveRequest6MrnSomniCallDescriptor__v_
(f86398d0, f977b87c, 1574, fe3a07e8, 5, ff34fdb4) + 74
fe2e71f8
__1cOomniCallHandleGupcall6MpnLomniServant_rnSomniCallDescriptor__v_
(f977bb90, f8668a88, f977b87c, 6, 1, f86398d0) + 94
ff239064 __1cT_impl_AmMMOResourceJ_dispatch6MrnOomniCallHandle__b_
(f8668a98, f977bb90, 1c00, f8639988, 0, 1d50) + 23c
fe2d3454
__1cEomniKomniOrbPOAIdispatch6MrnOomniCallHandle_pnRomniLocalIdentity__v
_ (fe3a9628, f977bb90, f8668aa8, 0, ecd664, ecd664) + 2f4
fe2b6a90 __1cRomniLocalIdentityIdispatch6MrnOomniCallHandle__v_
(f8668aa8, f977bb90, 7f486da2, 1, 2f30, f85becae) + 94
fe307260 __1cEomniGGIOP_SNhandleRequest6M_b_ (f86398d0, f85beca0, 0,
f86398d4, f86398d4, f977bb8c) + 104
fe306e84 __1cEomniGGIOP_SKdispatcher6M_b_ (f86398d0, fe3ab0c4,
fe383086, 1, fe316a48, fe3a07e8) + 124
fe304558 __1cEomniKgiopWorkerMreal_execute6M_v_ (f8636f98, 9c6b0, 1400,
0, 0, 1504) + 424
fe30406c __1cEomniOgiopWorkerInfoDrun6M_v_ (f977bde4, f8636f98,
f977bde8, 0, fe3f48ec, 0) + 38
fe304114 __1cEomniKgiopWorkerHexecute6M_v_ (f8636f98, 45651c50,
2f706cf8, 0, 0, 2f706cf8) + 10
fe2aff18 __1cPomniAsyncWorkerIreal_run6M_v_ (f86344e0, f8636f98, 0,
fe3abb30, fe304104, ecc200) + 20c
fe2af418 __1cTomniAsyncWorkerInfoDrun6M_v_ (f977bf34, f86344e0, 0, 0,
0, 0) + 38
fe2b0108 __1cPomniAsyncWorkerDrun6Mpv_v_ (f86344e0, 0, 0, 0, 0, 0) + 14
fe3e28d4 omni_thread_wrapper (f86344e0, fe3f44c8, 0, 0, 0, 0) + d4
fdf65854 _lwp_start (0, 0, 0, 0, 0, 0)



Any help on the above mentioned issue will be highly appreciated.

Thanks & Regards
Gurminder singh

[Duncan Grisby]

Post by Gurminder Singh
We are using OmniORB version 4.0.1 in our multi threaded server
application (solaris 8 platform).

Are you able to upgrade to 4.0.7 or 4.1.0? 4.0.1 is ancient now.

Post by Gurminder Singh
The application tends to crash say about once a week in the production
environment.

The stack trace shows it blowing up with an unhandled C++ exception.
That's particularly bad because everything the omniAsyncWorker
does is wrapped in a try..catch(...) block that should catch absolutely
all exceptions.

Perhaps you're running out of memory? copybuffer() tries to allocate
new memory.

Cheers,

Duncan.

[Steffen DETTMER]

Post by Duncan Grisby

Post by Gurminder Singh
The application tends to crash say about once a week in the production
environment.

The stack trace shows it blowing up with an unhandled C++ exception.
That's particularly bad because everything the omniAsyncWorker
does is wrapped in a try..catch(...) block that should catch absolutely
all exceptions.

just in case it may help, I just had a similar issue. catch(...)
- at least on g++, not sure how it is specified by C++ - has no
effect if a method has a throw-clause but throws something
different, like e.g.:

static void Class::crashMethod(void) throw std::exception
{
// would be caugth by "catch(...)" IF we had NO throw-clause
// but so it will abort()
class Private {};
throw Private;
}

try {
Class::crashMethod();
// throws Private (in constrast to throw-clause) and C++ aborts.
} catch (...) {
// won't be reached!
}

just in case it helps. ermm... and I hope I'm right, at least I
had this in my test, where the catch was "far away" from the
throw. Well, anyway, best seems to avoid "throw ..." in C++...

oki,

Steffen