IPC memory leakage on latest chromium-24.0.1312.57

[J.R. Oldroyd]

On Mon, 4 Feb 2013 20:55:58 +0200 George Liaskos
<geo.liaskos at gmail.com> wrote:
>
> > I think the problem may be related to
> > files/patch-ui__surface__transport_dib_linux.cc which replaces the
> > immediate removal of the shm after attaching to it with removal in
> > the destructor iff we're the last who is attached to it.
> >
> > The comment states:
> > // On BSD we can't access the shared memory after is marked for
> > deletion.
> > but this is not true if kern.ipc.shm_allow_removed=1 which we are told
> > to set in the pkg-message.
> 
> The problem is definitely in this patch, if kern.ipc.shm_allow_removed
> is set then the patch is not needed at all.
> The issue here is that the sysctl is not set by default and we must /
> should support the default configuration.
> 
> I don't really know how to solve correctly this issue, TransportDIBs
> are created from a static function and the shm keys are cached.
> Simply removing the key in the destructor is not correct because there
> are other TransportDIB instances which use the same key.
> 
> ... and even if you handle the removal gracefully, what happens when
> the process crashes? More leaks, that's why all other platforms allow
> the removal immediately.
> 
> Maybe we are correct according to the Posix spec but now i understand
> why almost no one follows this specific behavior.
> 
> 
> [1] http://src.chromium.org/viewvc/chrome/trunk/src/ui/surface/transport_dib_linux.cc?revision=167669&content-type=text%2Fplain

Hey George,

I saw you were the submitter of this patch, so thanks for chiming in.

I can say that I've run without the patch for about 36-48 hours now
and the problem has not recurred.  So those wanting a simple fix can
simply remove the patch, recompile chrome, set
	kern.ipc.shm_allow_removed=1
and run.

Since the patch breaks things, I think it needs to be replaced.  A
simple fix would be to remove the patch and add a wrapper sh script
that checks if the sysctl is set and prints a message if not.

As for a proper fix, I haven't really studied that code in detail.
Some possible thoughts.  I am not sure what is using this shm
region...  separate processes or separate threads?  Could the shm
perhaps be replaced by something else, such as a malloc'd region
accessed through a global variable?  If not, is the removal code
in the right place in the destructor; should it perhaps be in the
TransportDIB::Detach method instead, or somewhere else?  Do we know
why it is not being executed - is this due to the removal code not
being reached or is it due to something crashing?  If something is
crashing (and we can't fix that problem), can we trap that event and
remove the shm there?

	-jr
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-chromium/attachments/20130204/b3c9d94b/attachment.sig>