Discussion:
[omniORB] memory leak in omniORB-4.1.x
Serguei Kolos
2012-10-26 13:36:41 UTC
Permalink
Hi

I believe I have found a memory leak in the omniORB-4.1.6 (which exists
also in the previous
versions). The 2 patches to fix the leak are attached. Below is the
description of the problem.

The giopServer class maintains the list of connectionState objects for
each opened connection,
but the issue is that objects are never removed from that list, even if
a connection is closed.
This happens because the removal may occur only if the condition in the
giopServer.cc:1172
line is met:

if (Link::is_empty(cs->workers))

But that actually never happens as the "workers" attribute of the
connectionState class is used
in rather weird way - this is a list which keeps accumulating workers
each time a new worker is
used for the given connection but no workers are ever removed from that
list, so it never becomes
empty. In general the other problem is that the "workers" list is not
really used in the code in
any way so it seems that it may go saving some memory and CPU cycles,
and this is what
the attached patches are doing.

Cheers,
Sergei

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: giopServer.cc.patch
URL: <http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20121026/962686df/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: giopServer.h.patch
URL: <http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20121026/962686df/attachment-0001.ksh>
Duncan Grisby
2012-10-29 10:42:44 UTC
Permalink
Post by Serguei Kolos
I believe I have found a memory leak in the omniORB-4.1.6 (which exists
also in the previous
versions).
How do you observe the leak?
Post by Serguei Kolos
The giopServer class maintains the list of connectionState objects for
each opened connection,
but the issue is that objects are never removed from that list, even if
a connection is closed.
The workers _are_ removed from the list. There are several places in
giopServer.cc that call w->remove(). Those calls are removing workers
from the list. If you are seeing a leak, it's a more subtle situation
than just that the list is never emptied.

That said, there is no current need for the code to keep track of the
workers in that list, and the logic is unnecessarily complicated. The
whole connection management approach could do with being refactored, not
just this aspect of it.

Cheers,

Duncan.
--
-- Duncan Grisby --
-- duncan at grisby.org --
-- http://www.grisby.org --
Serguei Kolos
2012-10-29 11:21:29 UTC
Permalink
Hi Duncan

You are right. I have finally found that the memory leak
was in my code, so the omniORB is innocent. Sorry for
the noise.

Cheers,
Sergei
Post by Duncan Grisby
Post by Serguei Kolos
I believe I have found a memory leak in the omniORB-4.1.6 (which exists
also in the previous
versions).
How do you observe the leak?
Post by Serguei Kolos
The giopServer class maintains the list of connectionState objects for
each opened connection,
but the issue is that objects are never removed from that list, even if
a connection is closed.
The workers _are_ removed from the list. There are several places in
giopServer.cc that call w->remove(). Those calls are removing workers
from the list. If you are seeing a leak, it's a more subtle situation
than just that the list is never emptied.
That said, there is no current need for the code to keep track of the
workers in that list, and the logic is unnecessarily complicated. The
whole connection management approach could do with being refactored, not
just this aspect of it.
Cheers,
Duncan.
Loading...