From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35260) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1UgT-0005DC-67 for qemu-devel@nongnu.org; Wed, 25 Nov 2015 02:40:10 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a1UgP-0006kQ-QQ for qemu-devel@nongnu.org; Wed, 25 Nov 2015 02:40:09 -0500 Received: from mail-pa0-x22a.google.com ([2607:f8b0:400e:c03::22a]:34861) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1UgP-0006kF-Lq for qemu-devel@nongnu.org; Wed, 25 Nov 2015 02:40:05 -0500 Received: by pacej9 with SMTP id ej9so49282227pac.2 for ; Tue, 24 Nov 2015 23:40:05 -0800 (PST) Date: Wed, 25 Nov 2015 15:40:00 +0800 From: Stefan Hajnoczi Message-ID: <20151125074000.GB7357@stefanha-x1.localdomain> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qcHopEYAB45HaUaB" Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] QEMU versus Facebook's Infer static analysis tool List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: QEMU Developers --qcHopEYAB45HaUaB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Nov 14, 2015 at 09:53:44PM +0000, Peter Maydell wrote: > So I tried out Facebook's Infer static analysis tool (http://fbinfer.com/) > on QEMU this evening, just to see whether it would be able to handle our > codebase and if it would report anything interesting. >=20 > The good news is it was easy enough to install and didn't fall over; > all you have to do to run it is (a) configure; (b) run "infer -- make -j4" > in the build directory. >=20 > The bad news is that it really doesn't get on with our QOM cast macros. > It produces over a thousand false positives for code like > CadenceUARTState *s =3D CADENCE_UART(dev); > s->r[R_CR] =3D 0x00000128; > where as far as I can tell it thinks that 's' could be NULL when > deferenced because: > * the QOM cast macro has an internal call to object_dynamic_cast_assert() > * object_dynamic_cast_assert() handles being passed NULL (it returns NULL > if the input is NULL), so it includes tests for 'obj !=3D NULL' > * infer assumes that this test implies that obj could be NULL in this > code path >=20 > That's a shame, because it would have been nice to include another > kind of static analysis in what we run on QEMU (especially since > the coverity tests are "only runs every so often when we do a build"), > and the ability to do incremental analysis would have meant you could > include it in day to day workflow much more easily. >=20 > In summary: worth keeping an eye on to see if it improves, but for > now I figured I'd just post this email to the list to save anybody > else running through the same process to come to the same conclusion. Is it possible to send feedback to the fbinfer team? Maybe they are willing to solve the issue. From your description it seems like the tool's NULL analysis is too shallow and not useful due to the false positives. Stefan --qcHopEYAB45HaUaB Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJWVWXQAAoJEJykq7OBq3PI3TQIALNDb4GpRPcOukxAAJLBNZD3 tBsY5uih8nv+doJ2bOtW3QYTXUX1wTOL9SkATY32wCKmpHrltcpxDDUwKhzH264d Y58ZaZmD2Xs1QvPPIhPZGWrczF3s9CrEEXonrJXSlFC7BCu9OXx6aA1tnQKYVEq9 ZPX50nnF/tzVJSHi3HhEvaD/+DmWJ17tX40f2zYMtjVVGZU/g6eSkGJlrVolu/SM 2NEyXSGEvi4ah5V6bKkgQos3fD6WF36uWkDzpfPcvXqZC2AT65BnKyoomirAaFgL YlAvWAGLsCzV3pmsvf4B4EKma6hVXsO7HgpzZRItg87Ir3dxmaMwlnOfY0TYYMs= =8+Kb -----END PGP SIGNATURE----- --qcHopEYAB45HaUaB--