[omniORB] assertion in omniORB (4.0.6)

Slawomir Lisznianski slisznianski at asyncnet.com
Thu Aug 18 12:14:25 BST 2005


Folks, 

At this point I'm able to reproduce the assertion once in about 10
minutes of testing session. The test consists of simulating unstable
CORBA clients (they connect, make a call or two, and die shortly after).
The clients are also passing callback references (so they may act as
servers too). The server is supposed to survive the dying clients, but
at this point the assertion causes, well, "denial of service" ;-)

All clients and servers are using omniORB 4.0.6.

Here is the omniORB configuration of the server that asserts:

omniORB: Current configuration is as follows:
omniORB:   DefaultInitRef (file) =
omniORB:   DefaultInitRef (args) =
omniORB:   abortOnInternalError = 0
omniORB:   acceptBiDirectionalGIOP = 0
omniORB:   acceptMisalignedTcIndirections = 0
omniORB:   bootstrapAgentHostname =
omniORB:   bootstrapAgentPort = 900
omniORB:   clientCallTimeOutPeriod = 0
omniORB:   clientTransportRule = * unix,ssl,tcp
omniORB:   diiThrowsSysExceptions = 0
omniORB:   dumpConfiguration = 1
omniORB:   endPoint = giop:tcp::40000
omniORB:   endPointPublishAllIFs = 0
omniORB:   giopMaxMsgSize = 20971520
omniORB:   giopTargetAddressMode = KeyAddr
omniORB:   id = omniORB4
omniORB:   inConScanPeriod = 180
omniORB:   lcdMode = 0
omniORB:   maxGIOPConnectionPerServer = 5
omniORB:   maxGIOPVersion = 1.2
omniORB:   maxInterleavedCallsPerConnection = 5
omniORB:   maxServerThreadPerConnection = 100
omniORB:   maxServerThreadPoolSize = 200
omniORB:   nativeCharCodeSet = ISO-8859-1
omniORB:   nativeWCharCodeSet = UTF-16
omniORB:   objectTableSize = 0
omniORB:   offerBiDirectionalGIOP = 0
omniORB:   omniORB_27_CompatibleAnyExtraction = 0
omniORB:   oneCallPerConnection = 0
omniORB:   outConScanPeriod = 120
omniORB:   poaHoldRequestTimeout = 0
omniORB:   poaUniquePersistentSystemIds = 1
omniORB:   principal = [Null]
omniORB:   scanGranularity = 5
omniORB:   serverCallTimeOutPeriod = 0
omniORB:   serverTransportRule = * unix,ssl,tcp
omniORB:   strictIIOP = 1
omniORB:   supportBootstrapAgent = 0
omniORB:   supportCurrent = 1
omniORB:   supportPerThreadTimeOut = 0
omniORB:   tcAliasExpand = 0
omniORB:   threadPerConnectionLowerLimit = 9000
omniORB:   threadPerConnectionPolicy = 0
omniORB:   threadPerConnectionUpperLimit = 10000
omniORB:   threadPoolWatchConnection = 1
omniORB:   traceExceptions = 0
omniORB:   traceInvocations = 0
omniORB:   traceLevel = 2
omniORB:   traceThreadId = 0
omniORB:   unixTransportDirectory = /tmp/omni-%u
omniORB:   unixTransportPermission =  777
omniORB:   useTypeCodeIndirections = 1
omniORB:   verifyObjectExistsAndType = 1

At the assertion point, status on strands is:

nbusy  = 1
ndying = 4
max    = 5

Any idea on how to tackle this problem, through say configuration,
greatly appreciated.

Regards,
Slawomir



On Wed, 17 Aug 2005 13:02:13 -0500, "Slawomir Lisznianski"
<slisznianski at asyncnet.com> said:
> Hello,
> 
> I'm testing various error handling procedures of our CORBA application.
> In one of our tests, I'm simulating random client and/or server crashes,
> while observing how the other side reacts to them. I've been able to
> generate an assertion in omniORB during one of such sessions:
>  
> omniORB: Assertion failed.  This indicates a bug in the application
> using omniORB, or maybe in omniORB itself.
>  file: giopRope.cc
>  line: 374
>  info: s
> 
> Any idea why would this happen?
> 
> System info: 4 CPU Linux, Kernel 2.4.21
> Compiler: g++ (GCC) 3.2.3 20030502
> omniORB: 4.0.6
> 
> Regards,
> Slawomir
> 
> _______________________________________________
> 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