From owner-freebsd-chromium@FreeBSD.ORG Mon Feb 4 22:08:19 2013 Return-Path: Delivered-To: freebsd-chromium@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 30D4F7EF for ; Mon, 4 Feb 2013 22:08:19 +0000 (UTC) (envelope-from fbsd@opal.com) Received: from mho-02-ewr.mailhop.org (mho-04-ewr.mailhop.org [204.13.248.74]) by mx1.freebsd.org (Postfix) with ESMTP id 01ABE34F for ; Mon, 4 Feb 2013 22:08:18 +0000 (UTC) Received: from pool-151-203-245-187.bos.east.verizon.net ([151.203.245.187] helo=homobox.opal.com) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1U2UD3-000PBx-U5; Mon, 04 Feb 2013 22:08:18 +0000 Received: from shibato (shibato.opal.com [IPv6:2001:470:8cb8:4:221:63ff:fe5a:c9a7]) (authenticated bits=0) by homobox.opal.com (8.14.4/8.14.4) with ESMTP id r14M8EsA086865 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 4 Feb 2013 17:08:14 -0500 (EST) (envelope-from fbsd@opal.com) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 151.203.245.187 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+8Sf0Xa1oFb/4k32vQKxhz Date: Mon, 4 Feb 2013 17:08:02 -0500 From: "J.R. Oldroyd" To: George Liaskos Subject: Re: IPC memory leakage on latest chromium-24.0.1312.57 Message-ID: <20130204170802.3ed0ac23@shibato> In-Reply-To: References: <1563077977.10385807.1359749865202.JavaMail.root@k-state.edu> <20130203122913.6c0cf4e9@shibato> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.6; amd64-portbld-freebsd9.1) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/D50Q57cyMqMrZiPMK3ZD4P8"; protocol="application/pgp-signature" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (homobox.opal.com [IPv6:2001:470:8cb8:4::1]); Mon, 04 Feb 2013 17:08:14 -0500 (EST) X-Spam-Status: No, score=-2.2 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, OPAL_URI_COUNT_5_9, RP_MATCHES_RCVD shortcircuit=no autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on homobox.opal.com Cc: freebsd-chromium@freebsd.org X-BeenThere: freebsd-chromium@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: FreeBSD-specific Chromium issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 22:08:19 -0000 --Sig_/D50Q57cyMqMrZiPMK3ZD4P8 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 4 Feb 2013 20:55:58 +0200 George Liaskos 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=3D1 which we are told > > to set in the pkg-message. >=20 > 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. >=20 > 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. >=20 > ... 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. >=20 > Maybe we are correct according to the Posix spec but now i understand > why almost no one follows this specific behavior. >=20 >=20 > [1] http://src.chromium.org/viewvc/chrome/trunk/src/ui/surface/transport_= dib_linux.cc?revision=3D167669&content-type=3Dtext%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=3D1 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 --Sig_/D50Q57cyMqMrZiPMK3ZD4P8 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlEQMU0ACgkQls33urr0k4n64wCfa4jL/8deXRrIWRNJZJRFKRgS aw0AoKeR7jrpk6p0+3ez7Yrg2r8AXGXw =ZxoY -----END PGP SIGNATURE----- --Sig_/D50Q57cyMqMrZiPMK3ZD4P8--