[omniORB] omniORB 4.0.1 bug: socket leak with threadPerConnectionPolicy=0

[Bastiaan Bakker]

Hi,

As mentioned in my 'omniORB 4.0.1 crash: pure virtual method call in
giopServer.cc:973' messages, I'm seeing socket leaks with omiORB 4.0.1
when 'threadPerConnectionPolicy=0'. Since I can repoduce it with the
echo example client and server, I'm confident now that it's a bug in
omniORB rather than our own code.

Symptoms:
If the server process runs in 'thread pool mode', it keeps sockets to
clients open even though the client has gone, as can be witnessed with
netstat:

$ netstat -a --unix -p
Proto RefCnt Flags       Type       State         I-Node PID/Program
name    Path
unix  2      [ ACC ]     STREAM     LISTENING     2025382
16236/eg2_impl      /tmp/omni-lmsbuild/000016236-1063202502
unix  2      [ ]         STREAM     CONNECTED     2053046
16236/eg2_impl      /tmp/omni-lmsbuild/000016236-1063202502
unix  2      [ ]         STREAM     CONNECTED     2049902
16236/eg2_impl      /tmp/omni-lmsbuild/000016236-1063202502
unix  2      [ ]         STREAM     CONNECTED     2046324
16236/eg2_impl      /tmp/omni-lmsbuild/000016236-1063202502
unix  2      [ ]         STREAM     CONNECTED     2046318
16236/eg2_impl      /tmp/omni-lmsbuild/000016236-1063202502
unix  2      [ ]         STREAM     CONNECTED     2027593
16236/eg2_impl      /tmp/omni-lmsbuild/000016236-1063202502
unix  2      [ ]         STREAM     CONNECTED     2025491
16236/eg2_impl      /tmp/omni-lmsbuild/000016236-1063202502

Here the server was started with a unix endpoint, but the problem
manifests itself with TCP sockets as well. In that connections in
'CLOSED_WAIT' status show up in the netstat output:

tcp        0      0 10.88.2.37:57193        10.88.2.37:57431       
CLOSE_WAIT  26641/eg2_impl


Repeat by:
1) start eg2_impl with thread pool (and unix endpoint):
./eg2_impl -ORBthreadPerConnectionPolicy 0 -ORBendPoint giop:unix:

2) run eg2_clt a few hundred times. Maybe concurrent calls to the server
trigger the problem more easily, but serialized calls appear to do as
well. 

Platform:
RedHat x86 Linux 7.3, with omniORB 4.0.1


I wasn't able to reproduce the problem with the 'thread per connection'
policy, but that may be because the chances for the race condition are
slimmer. 
Next, I'll try omniORB 4.0.2.

Cheers,

Bastiaan Bakker
LifeLine Networks bv