From owner-freebsd-chromium@FreeBSD.ORG Mon Feb 4 18:56:05 2013 Return-Path: Delivered-To: freebsd-chromium@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 21F38256 for ; Mon, 4 Feb 2013 18:56:05 +0000 (UTC) (envelope-from geo.liaskos@gmail.com) Received: from mail-ea0-f176.google.com (mail-ea0-f176.google.com [209.85.215.176]) by mx1.freebsd.org (Postfix) with ESMTP id B67BE659 for ; Mon, 4 Feb 2013 18:56:04 +0000 (UTC) Received: by mail-ea0-f176.google.com with SMTP id a13so3083200eaa.21 for ; Mon, 04 Feb 2013 10:55:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=aPh/razzctisCVJM37vIICkvy9gn4akNtx92n7Y119c=; b=dihkaO/WPC5JYHW62YFhAGlgAmcC4XRMkIXYTUbkn7AV3feNA82Q4nPkLopwkzmCTQ Vw8TBb0o4DQIDqTWj+06kl+oJWPFkjwlY4xCUE+MxFsiD/1kLnIcP3dRCDLfhUuNEUlv QerE+ekSKsBK/3MmpLqCOkPvkhQiON6hjLgVKH0dg0LaL9gUjiqREr2JNEt5oCTKM/ZO 7z+YEiBDkzoFaFrrr8FOaR3kzRLoK33hhuXFu6mkx2ciH8ufHRGmU0uv3lWCVF845zyf OhUZDIzipD4jrWOPJAmhOJ2afU9lxBnm/y0bn6dKRYsfuXWo0W96WF7UgtJtPdFxitkX hChQ== MIME-Version: 1.0 X-Received: by 10.14.219.5 with SMTP id l5mr75057916eep.7.1360004158653; Mon, 04 Feb 2013 10:55:58 -0800 (PST) Received: by 10.223.31.145 with HTTP; Mon, 4 Feb 2013 10:55:58 -0800 (PST) In-Reply-To: <20130203122913.6c0cf4e9@shibato> References: <1563077977.10385807.1359749865202.JavaMail.root@k-state.edu> <20130203122913.6c0cf4e9@shibato> Date: Mon, 4 Feb 2013 20:55:58 +0200 Message-ID: Subject: Re: IPC memory leakage on latest chromium-24.0.1312.57 From: George Liaskos To: "J.R. Oldroyd" Content-Type: text/plain; charset=UTF-8 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 18:56:05 -0000 > 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