Date: Sun, 14 Jan 2018 01:47:13 +0100 From: Dimitry Andric <dim@FreeBSD.org> To: J David <j.david.lists@gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD 11.1 + Clang 4.0 + PHP source = Core dumps Message-ID: <6ED2FBBD-8404-4979-BC4B-559AE5229B3B@FreeBSD.org> In-Reply-To: <CABXB=RQoLTiDc8_vGhiv95pxN02Twfi_5m0Q%2Bc7OCAKBe9Np0w@mail.gmail.com> References: <CABXB=RQoLTiDc8_vGhiv95pxN02Twfi_5m0Q%2Bc7OCAKBe9Np0w@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_3447DD2F-7FA3-4DAE-9CFE-CFD3CAAB8FB8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
On 14 Jan 2018, at 00:24, J David <j.david.lists@gmail.com> wrote:
>=20
> Starting with Clang 4.0 on FreeBSD 11.1 we are seeing really odd
> behavior and crashes on a version of PHP that we compile in house.
> It=E2=80=99s not clear if this is a compiler bug, or what exactly is
> happening.
>=20
> For example, this code (from PHP=E2=80=99s intl extension) core dumps:
>=20
> U_CFUNC TimeZone *timezone_process_timezone_argument(zval =
*zv_timezone,
> intl_error =
*outside_error,
> const char *func)
> {
> zval local_zv_tz;
> char *message =3D NULL;
> TimeZone *timeZone;
>=20
> if (zv_timezone =3D=3D NULL || Z_TYPE_P(zv_timezone) =3D=3D =
IS_NULL) {
> timelib_tzinfo *tzinfo =3D get_timezone_info();
> ZVAL_STRING(&local_zv_tz, tzinfo->name);
> zv_timezone =3D &local_zv_tz;
> } else {
> ZVAL_NULL(&local_zv_tz);
> }
>=20
> if (Z_TYPE_P(zv_timezone) =3D=3D IS_OBJECT &&
> instanceof_function(Z_OBJCE_P(zv_timezone), =
TimeZone_ce_ptr)) {
>=20
> If zv_timezone is passed in as a NULL pointer, this code core dumps on
> the =E2=80=9Cif (Z_TYPE_P(zv_timezone)=E2=80=9D and gdb says that =
zv_timezone is NULL.
> But if you look immediately above, if zv_timezone is NULL it is set to
> another value.
>=20
> If you add a printf of the zv_timezone pointer above the second if
> block, it will show that zv_timezone is no longer NULL (because it was
> just set to &local_zv_tz), and the program will no longer crash.
>=20
> This crash can also be =E2=80=9Cfixed=E2=80=9D by placing the =
following line (a memory
> barrier) above the second if statement:
>=20
> __asm__ volatile(=E2=80=9C" : : : "memory");
>=20
> Although that addresses this one, it seems like there may be a number
> of other similar issues throughout the PHP code base.
>=20
> This just can=E2=80=99t be right; that should not be necessary. =
What=E2=80=99s going on?
>=20
> Is this a bug in clang? Is PHP doing something dodgy? User error on
> our part? We don=E2=80=99t see this behavior compiling the same =
source with
> clang 3.x / FreeBSD 10.x.
I suspect that you need to add -fno-strict-aliasing to your compilation
flags, if you haven't already. =46rom a cursory look, PHP seems to use =
a
*lot* of aliasing and type punning.
-Dimitry
--Apple-Mail=_3447DD2F-7FA3-4DAE-9CFE-CFD3CAAB8FB8
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.2
iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCWlqokQAKCRCwXqMKLiCW
o8QqAJ4qZxilGT92p+cqkMzUrYs1wihXwwCgpZIWxuuPDE1Vo3SzDx1aFm69PYw=
=V07W
-----END PGP SIGNATURE-----
--Apple-Mail=_3447DD2F-7FA3-4DAE-9CFE-CFD3CAAB8FB8--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6ED2FBBD-8404-4979-BC4B-559AE5229B3B>