[omniORB] Infinite polling loop with HUP socket causing 100% CPU usage

Duncan Grisby duncan at grisby.org
Wed May 6 15:27:48 BST 2015


On Tue, 2015-04-21 at 11:27 +0200, Erik Cumps wrote:

[...]
> Context: services implemented in python using omniORB and the omniORB python bindings, using
> the following debian packages:
> 
> 	ii  libomniorb4-1   4.1.6-2  i386  omniORB core libraries
> 	ii  python-omniorb  3.6-1    i386  Python bindings for omniORB

Can you test with omniORB 4.2.0, or the current svn snapshot?  It would
be easier to look into this if you were using a modern version of
omniORB.

[...]
> With strace the first case looks like this:
>         ...
>         poll([{fd=3, events=POLLIN}, {fd=5, events=POLLIN}], 2, 1) = 1 ([{fd=5, revents=POLLIN|POLLERR|POLLHUP}])
>         accept(5, 0, NULL)                      = -1 EINVAL (Invalid argument)

The fact that it's calling accept() shows that the socket in question is
the listening socket used to accept new incoming connections. I don't
see how that can possibly receive a "hang-up" condition. There is
nothing to hang up. The EINVAL return from accept() shows that it thinks
the socket is invalid, but I don't know how that could be. Has the
network interface been disabled or something?

If the socket omniORB is using to listen for new connections has become
invalid, I'm not sure what it should do. It can't usefully carry on.

[...]
> The second case looks like this:
>         ...
>         poll([{fd=4, events=POLLIN}, {fd=6, events=POLLIN}], 2, 50) = 1 ([{fd=4, revents=POLLHUP}])
>         gettimeofday({1429607075, 414623}, NULL) = 0  
[...]
> Again, notice how each poll() returns with the POLLHUP event for the socket.

I assume that this socket is one associated with a connection. In this
case, omniORB doesn't think anything of interest has occurred on the
socket, because it's only looking for POLLIN. Perhaps it should look for
POLLIN | POLLHUP, then it would try to read from the socket and
(presumably) notice an error condition. Does the attached patch help?
The patch is against omniORB 4.2.x, but you should be able to apply
something similar to your 4-year-old 4.1.6 if you need to.

Cheers,

Duncan.

-- 
 -- Duncan Grisby         --
  -- duncan at grisby.org     --
   -- http://www.grisby.org --

-------------- next part --------------
A non-text attachment was scrubbed...
Name: pollhup.patch
Type: text/x-patch
Size: 449 bytes
Desc: not available
URL: <http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20150506/3cefdbeb/attachment.bin>


More information about the omniORB-list mailing list