Date: Tue, 14 Aug 2018 12:18:28 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: Mark Martinec <Mark.Martinec+freebsd@ijs.si>, stable@freebsd.org, Alan Somers <asomers@freebsd.org> Cc: Mark Johnston <markj@freebsd.org> Subject: Re: All the memory eaten away by ZFS 'solaris' malloc - on 11.1-R amd64 Message-ID: <34871f1f-b890-a129-7ead-ed15d8e2e22e@FreeBSD.org> In-Reply-To: <a1e730def80ae4d188f5ba782b70b46d@ijs.si> References: <1a039af7758679ba1085934b4fb81b57@ijs.si> <3e56e4de076111c04c2595068ba71eec@ijs.si> <20180731220948.GA97237@raichu> <2ec91ebeaba54fda5e9437f868d4d590@ijs.si> <b3aa2bbe947914f8933b24cf0d0b15f0@ijs.si> <20180804170154.GA12146@raichu> <87f6a55cc2ee3d754ddb89475bbfbab8@ijs.si> <20180804194757.GD12146@raichu> <a1e730def80ae4d188f5ba782b70b46d@ijs.si>
next in thread | previous in thread | raw e-mail | index | archive | help
On 07/08/2018 15:58, Mark Martinec wrote: > Collected, here it is: > > https://www.ijs.si/usr/mark/tmp/dtrace-cmd.out.bz2 I see one memory leak, not sure if it's the only one. It looks like vdev_geom_read_config() leaks all parsed vdev nvlist-s but the last. The problems seems to come from r316760. Before that commit the function would return upon finding the first valid config, but now it keeps iterating. The memory leak should not be a problem when vdev-s are probed sufficiently rarely, but it appears that with an unhealthy pool the probing can happen much more frequently (e.g., every time pools are listed). -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?34871f1f-b890-a129-7ead-ed15d8e2e22e>