[omniORB] OmniORB 4.1.4 assertion failure

[Duncan Grisby]

On Mon, 2010-03-22 at 09:21 +0000, Richard Pitts wrote:

[...]
> [<--- Request n]
> [<--- Request n + 1]
> omniORB: Assertion failed.  This indicates a bug in the application
> using omniORB, or maybe in omniORB itself.
>  file: SocketCollection.cc
>  line: 955
>  info: s->pd_fd_index >= 0
> omniORB: Unexpected exception caught by giopRendezvouser
> omniORB: Unrecoverable error for this endpoint:
> giop:tcp:10.26.60.62:2503, it will no longer be serviced.
> [<--- Request n + 2]
> [<--- No more requests]

[...]
> My initial guess is incompatible between different versions of
> OmniORB, then again I'm unsure because it appears to work fine
> until a random event. Ideally I'd like to upgrade the client to
> OmniORB 4.1.4 using Visual Studio 2008 but I can't at the moment. 
> If the problem persists then this issue should hopefully forces us to
> do so sooner.

It's definitely not an incompatibility between omniORB versions. It
should not be possible for a client to crash a server no matter what.

Are you running in thread per connection mode or thread pool mode?
Having analysed the code, I think it is conceivable that there is a race
condition in thread pool mode if the scheduler behaves in an unlikely
way. If you are running in thread pool mode, can you try thread per
connection mode to see if the problem goes away?

Regardless, I would expect the attached patch to fix it. Can you try
that?

Cheers,

Duncan.

-- 
 -- Duncan Grisby          --
  -- duncan at grisby.org      --
   -- http://www.grisby.org/ --
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SocketCollection.patch
Type: text/x-patch
Size: 743 bytes
Desc: not available
Url : http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20100322/721e6500/SocketCollection.bin