FreeBSD 11.1 + Clang 4.0 + PHP source = Core dumps

[Dimitry Andric]

On 14 Jan 2018, at 00:24, J David <j.david.lists at gmail.com> wrote:
> 
> 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’s not clear if this is a compiler bug, or what exactly is
> happening.
> 
> For example, this code (from PHP’s intl extension) core dumps:
> 
> U_CFUNC TimeZone *timezone_process_timezone_argument(zval *zv_timezone,
>                                                     intl_error *outside_error,
>                                                     const char *func)
> {
>    zval        local_zv_tz;
>    char        *message = NULL;
>    TimeZone    *timeZone;
> 
>    if (zv_timezone == NULL || Z_TYPE_P(zv_timezone) == IS_NULL) {
>        timelib_tzinfo *tzinfo = get_timezone_info();
>        ZVAL_STRING(&local_zv_tz, tzinfo->name);
>        zv_timezone = &local_zv_tz;
>    } else {
>        ZVAL_NULL(&local_zv_tz);
>    }
> 
>    if (Z_TYPE_P(zv_timezone) == IS_OBJECT &&
>            instanceof_function(Z_OBJCE_P(zv_timezone), TimeZone_ce_ptr)) {
> 
> If zv_timezone is passed in as a NULL pointer, this code core dumps on
> the “if (Z_TYPE_P(zv_timezone)” 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.
> 
> 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.
> 
> This crash can also be “fixed” by placing the following line (a memory
> barrier) above the second if statement:
> 
>    __asm__ volatile(“" : : : "memory");
> 
> Although that addresses this one, it seems like there may be a number
> of other similar issues throughout the PHP code base.
> 
> This just can’t be right; that should not be necessary.  What’s going on?
> 
> Is this a bug in clang?  Is PHP doing something dodgy?  User error on
> our part?  We don’t 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.  From a cursory look, PHP seems to use a
*lot* of aliasing and type punning.

-Dimitry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 223 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20180114/519f514d/attachment.sig>