Date: Fri, 25 May 2018 17:44:24 +0000 From: Brooks Davis <brooks@freebsd.org> To: araujo@freebsd.org Cc: Eitan Adler <lists@eitanadler.com>, src-committers <src-committers@freebsd.org>, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r334199 - head/usr.sbin/bhyve Message-ID: <20180525174424.GD99063@spindle.one-eyed-alien.net> In-Reply-To: <CAOfEmZhS4RZPn6%2BqOcU56HUtUgGids79cS=fBKfuGjpBBQQm5g@mail.gmail.com> References: <201805250207.w4P275Pf060725@repo.freebsd.org> <20180525151134.GB99063@spindle.one-eyed-alien.net> <CAOfEmZgV9yssn5v8ZpbkwL=rrifoD1Z=uRxe6a0KyM3mrXrSjQ@mail.gmail.com> <CAF6rxgm32%2B_XazDvbtyFChPigxVB0HQ30r3=CvN65ko=zHq0yA@mail.gmail.com> <CAOfEmZhS4RZPn6%2BqOcU56HUtUgGids79cS=fBKfuGjpBBQQm5g@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--mJm6k4Vb/yFcL9ZU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, May 26, 2018 at 01:21:33AM +0800, Marcelo Araujo wrote: > On Sat, May 26, 2018, 1:11 AM Eitan Adler <lists@eitanadler.com> wrote: >=20 > > On 25 May 2018 at 08:23, Marcelo Araujo <araujobsdport@gmail.com> wrote: > > > > > > > > > On Fri, May 25, 2018, 11:11 PM Brooks Davis <brooks@freebsd.org> wrot= e: > > >> > > >> On Fri, May 25, 2018 at 02:07:05AM +0000, Marcelo Araujo wrote: > > >> > Author: araujo > > >> > Date: Fri May 25 02:07:05 2018 > > >> > New Revision: 334199 > > >> > URL: https://svnweb.freebsd.org/changeset/base/334199 > > >> > > > >> > Log: > > >> > Fix a memory leak on topology_parse(). > > >> > > > >> > strdup(3) allocates memory for a copy of the string, does the co= py > > and > > >> > returns a pointer to it. If there is no sufficient memory NULL is > > >> > returned > > >> > and the global errno is set to ENOMEM. > > >> > We do a sanity check to see if it was possible to allocate enough > > >> > memory. > > >> > > > >> > Also as we allocate memory, we need to free this memory used. Or= it > > >> > will > > >> > going out of scope leaks the storage it points to. > > >> > > > >> > Reviewed by: rgrimes > > >> > MFC after: 3 weeks. > > >> > X-MFC: r332298 > > >> > Sponsored by: iXsystems Inc. > > >> > Differential Revision: https://reviews.freebsd.org/D15550 > > >> > > > >> > Modified: > > >> > head/usr.sbin/bhyve/bhyverun.c > > >> > > > >> > Modified: head/usr.sbin/bhyve/bhyverun.c > > >> > > > >> > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > > >> > --- head/usr.sbin/bhyve/bhyverun.c Fri May 25 01:38:59 2018 > > >> > (r334198) > > >> > +++ head/usr.sbin/bhyve/bhyverun.c Fri May 25 02:07:05 2018 > > >> > (r334199) > > >> > @@ -193,6 +193,7 @@ topology_parse(const char *opt) > > >> > c =3D 1, n =3D 1, s =3D 1, t =3D 1; > > >> > ns =3D false, scts =3D false; > > >> > str =3D strdup(opt); > > >> > + assert(str !=3D NULL); > > >> > > >> Using assert seems like an odd choice when you've already added a > > >> failure path and the strsep will crash immediately if assert is elid= ed. > > > > > > > > > Just to make a better point, I had the same discussion about assert(3= ) in > > > another review, we don't do NDEBUG even for RELEASE. > > > > IMHO we only use assert for asserting things ought to never be false > > except in buggy code. Using assert for handling is poor practice. > > >=20 > Again, in this case we are using it all over the place and we must replace > it. Also we should document it in somewhere perhaps in the assert(3) > otherwise myself and others will keep using it. If you use find, not only > myself is using it to check strdup! So what is the suggestion to handle > assert(3)? Deprecated it? Code that uses assert() in place of error handling is wrong and should be fixed. assert(condition) means that condition must never happen and if it does a bug has occurred (or the programmers assumptions are wrong). In this case failure would not be due to a bug, but do to resource exhaustion which is expected to be handled. -- Brooks --mJm6k4Vb/yFcL9ZU Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJbCEt3AAoJEKzQXbSebgfAiloIAJ+qdzgQpTJD9I2mO369RHsU IvzmcaoSXv11CeIFgk+/+j4qLcFdgWIte0HlnK8Hj6p9sbeK2EJYcBBpVEwFPdBd n1YXdqGRBosEmyatyoIcL5Ls6jmy11XICgXjKRiGxuGdkHype+qtI2TWR9faMBDt VK2OOiXnDu0JIYISv9ksXZ6kOrbrCKZg6q2lgHE3XVM3QDh/PkS+mWvW776cknFZ j4up69nod74kww1d6J0vgTTvkLJmWpS+d/mmvamxgQ3wZ8HSjwYUDIEytwGb4+oe hN6jeEvEj3uhFQz42ph8cmF78XLvfNKXNrWOyDZk2sRb+l+UMgsstzoIM7ghJnI= =IvH8 -----END PGP SIGNATURE----- --mJm6k4Vb/yFcL9ZU--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180525174424.GD99063>