Home Original page

Zend Opcache on Solaris 11 x86 needs ZEND_MM_ALIGNMENT=4

Bug #65561 Zend Opcache on Solaris 11 x86 needs ZEND_MM_ALIGNMENT=4
Submitted: 2013-08-26 19:43 UTC Modified: 2013-08-29 06:36 UTC
From: craig dot mohrman at oracle dot com Assigned: dmitry (profile)
Status: Closed Package: opcache
PHP Version: Irrelevant OS: Solaris 11
Private report: No CVE-ID: None

 [2013-08-26 19:43 UTC] craig dot mohrman at oracle dot com

Description:
------------
This is a place holder bug for anyone working with Solaris and php 5.3.27
I haven't tried the latest version of PHP so maybe this just goes away.

I've documented this in a thread here:
https://github.com/zendtech/ZendOptimizerPlus/issues/122

But the problem appears to be in php itself.

This is compiling the Zend Opcache 7.0.2 from:
http://pecl.php.net/package/ZendOpcache

When compiling ZendOpcache with php 5.3.27 on Solaris 11 x86 with
the Solaris Studio compiler (12.1) I'm seeing Overflown errors even with the
most trivial of php programs.

This is all being done in 32-bit.
Sparc has no such issue.  Works out of the box.

As a workaround I'm patching ZEND_MM_ALIGNMENT:
#define ZEND_MM_ALIGNMENT 8
#define ZEND_MM_ALIGNMENT_LOG2 3

to

#define ZEND_MM_ALIGNMENT 4
#define ZEND_MM_ALIGNMENT_LOG2 2

over in PHP/Zend/Zend.m4
and everything works fine.

I got this 4 when compiling php 5.3.27 with gcc 4.5.
That comes up with ZEND_MM_ALIGNMENT=4 but when compiling
with Solaris Studio I get ZEND_MM_ALIGNMENT=8.

Oddly on Solaris sparc both Solaris Studio and gcc 4.5 come up with:
ZEND_MM_ALIGNMENT=8
but that works fine.

So see the actual patch below.
This is not the solution but gets Zend Opcache working on Solaris x86.


Test script:
---------------
$ cat simple.php
<?php

      function m_x_plus_b($m, $x, $b) {

            return $m*$x+$b;

      }

      $slope=1.5;

      $x=2;

      $b=3;

      echo "y = ".m_x_plus_b($slope,$x,$b)."\n<br>";
?>


Expected result:
----------------
$ php -v
PHP 5.3.27 (cli) (built: Aug 20 2013 11:05:05)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2013 Zend Technologies
    with Zend OPcache v7.0.2, Copyright (c) 1999-2013, by Zend Technologies
    with Xdebug v2.2.0, Copyright (c) 2002-2012, by Derick Rethans
    with Suhosin v0.9.33, Copyright (c) 2007-2012, by SektionEins GmbH
$ php -f simple.php
y = 6
<br>


Actual result:
--------------
$ php -f simple.php
File /home/cmohrman/Public/PHP/simple.php func m_x_plus_b
Block: 0-5 (6) unused
Block: 6-6 (1)
T0: 0
T1: 0
Opt Block: 0-5 (6)
T0: 0
T1: 0
Opt Block: 0-5 (6)
T0: 0
T1: 0
Opt Block: 0-5 (6)
T0: 0
T1: 0
Out Block: 0-5 (6)
File /home/cmohrman/Public/PHP/simple.php func main
Block: 0-11 (12) unused
T0: 0
T1: 0
T2: 0
T3: 0
T4: 0
T5: 0
[Fri Aug  9 11:10:45 2013]  Script:  '/home/cmohrman/Public/PHP/simple.php'
---------------------------------------
./Optimizer/block_pass.c(2053) : Block 0x0935e970 status:
Beginning:      OK (allocated on ./Optimizer/block_pass.c:1911, 6 bytes)
    Start:      OK
      End:      Overflown (magic=0x00000000 instead of 0x530646BC)
                1 byte(s) overflown
---------------------------------------
Opt Block: 0-11 (12)
[Fri Aug  9 11:10:45 2013]  Script:  '/home/cmohrman/Public/PHP/simple.php'
---------------------------------------
./Optimizer/block_pass.c(1220) : Block 0x0935fa70 status:
Beginning:      OK (allocated on ./Optimizer/block_pass.c:631, 24 bytes)
    Start:      OK
      End:      Overflown (magic=0xFFFFFFB4 instead of 0x530646BC)
                At least 4 bytes overflown
---------------------------------------
T0: 0
T1: 0
T2: 0
T3: 0
T4: 0
T5: 0
[Fri Aug  9 11:10:45 2013]  Script:  '/home/cmohrman/Public/PHP/simple.php'
---------------------------------------
./Optimizer/block_pass.c(2053) : Block 0x0935e9a8 status:
Beginning:      OK (allocated on ./Optimizer/block_pass.c:1911, 6 bytes)
    Start:      OK
      End:      Overflown (magic=0x00000000 instead of 0x530646BC)
                1 byte(s) overflown
---------------------------------------
Opt Block: 1-11 (11)
[Fri Aug  9 11:10:45 2013]  Script:  '/home/cmohrman/Public/PHP/simple.php'
---------------------------------------
./Optimizer/block_pass.c(1220) : Block 0x0935fc80 status:
Beginning:      OK (allocated on ./Optimizer/block_pass.c:631, 24 bytes)
    Start:      OK
      End:      Overflown (magic=0xFFFFFFB4 instead of 0x530646BC)
                At least 4 bytes overflown
---------------------------------------
T0: 0
T1: 0
T2: 0
T3: 0
T4: 0
T5: 0
[Fri Aug  9 11:10:45 2013]  Script:  '/home/cmohrman/Public/PHP/simple.php'
---------------------------------------
./Optimizer/block_pass.c(2053) : Block 0x0935e9e0 status:
Beginning:      OK (allocated on ./Optimizer/block_pass.c:1911, 6 bytes)
    Start:      OK
      End:      Overflown (magic=0x00000000 instead of 0x530646BC)
                1 byte(s) overflown
---------------------------------------
Opt Block: 1-11 (11)
[Fri Aug  9 11:10:45 2013]  Script:  '/home/cmohrman/Public/PHP/simple.php'
---------------------------------------
./Optimizer/block_pass.c(1220) : Block 0x0935ea50 status:
Beginning:      OK (allocated on ./Optimizer/block_pass.c:631, 24 bytes)
    Start:      OK
      End:      Overflown (magic=0xFFFFFFB4 instead of 0x530646BC)
                At least 4 bytes overflown
---------------------------------------
T0: 0
T1: 0
T2: 0
T3: 0
T4: 0
T5: 0
[Fri Aug  9 11:10:45 2013]  Script:  '/home/cmohrman/Public/PHP/simple.php'
---------------------------------------
./Optimizer/block_pass.c(2053) : Block 0x0935ea18 status:
Beginning:      OK (allocated on ./Optimizer/block_pass.c:1911, 6 bytes)
    Start:      OK
      End:      Overflown (magic=0x00000000 instead of 0x530646BC)
                1 byte(s) overflown
---------------------------------------
Out Block: 0-10 (11)
Segmentation Fault (core dumped)

$ mdb core
Loading modules: [ libc.so.1 libuutil.so.1 libnvpair.so.1 ld.so.1 ]
> ::stack
opcache.so`optimize_temporary_variables+0x504(935cdf0, 0)
opcache.so`zend_optimizer+0x2c3d(935cdf0, 0)
opcache.so`accel_op_array_handler+0x80(935cdf0, 0, 4c, 8af6905)
php`zend_extension_op_array_handler+0x1b(93fc4e0, 935cdf0, fea392d8, 8af3d21)
php`zend_llist_apply_with_argument+0x31(91e7b60, 8af6a8c, 935cdf0, 8af6ac5)
php`pass_two+0xac(935cdf0, 0, fea39448, 8aa0e38)
php`compile_file+0x5d9(fea3a400, 8, fea39620, 86a67dc)
php`phar_compile_file+0x370(fea3a400, 8)
opcache.so`compile_and_cache_file+0x424(fea3a400, 8, f8764444, 26, fea39950, 
fea39954)
opcache.so`persistent_compile_file+0x750(fea3a400, 8, 8058b50, 8b16131)
php`zend_execute_scripts+0x2da(8, 0, 3, 0, fea3a400, 0)
php`php_execute_script+0x3a8(fea3a400, 918f000, fea3a8c8, 8c94507)
php`main+0x15d6(3, fea3a8fc, fea3a90c, f8aa9940)
_start+0x7d(3, fea3a9fc, fea3aa00, fea3aa03, 0, fea3aa0e)
>

Patches

i386-Zend_Zend_m4.patch (last revision 2013-08-26 19:43 UTC by craig dot mohrman at oracle dot com)

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports

 [2013-08-27 14:37 UTC] Terry at ellisons dot org dot uk

The issue relates to the use of compiler-specific alignment directives in configure and in both the Zend and OPcache code.  (The whole standardisation of platform variants isn't consistent across the code, and I suspect some code paths have only been properly exercised for the gcc and vc compilers),   For example, Zend uses ZEND_MM_ALIGNMENT which is configured at the step  "checking for MM alignment and log values... " based on the following check:

#if (defined (__GNUC__) && __GNUC__ >= 2)
#define ZEND_MM_ALIGNMENT (__alignof__ (mm_align_test))
#else
#define ZEND_MM_ALIGNMENT (sizeof(mm_align_test))
#endif

whereas zend_shared_alloc.h instead sets its own PLATFORM_ALIGNMENT instead of using ZEND_MM_ALIGNMENT:

#if ZEND_GCC_VERSION >= 2000
# define PLATFORM_ALIGNMENT (__alignof__ (align_test))
#else
# define PLATFORM_ALIGNMENT (sizeof(align_test))
#endif

However, I'll try a 32-bit 5.3.27 on a LAMP stack and force this to see if I can track it down.

PS for Craig:  (i) Does the Solaris compiler have a pragma/builtin equivalent to __alignof__, and what is the correct constant to use to test for the Solaris C compiler?

 [2013-08-27 16:39 UTC] Terry at ellisons dot org dot uk

OK, I have got this as a repeatable bug on PHP 5.3.27 with OPcache installed on a std 32bit GCC LAMP VM -- if I force the dropping of the __alignof__ defines to default to sizeof (as happens configuring with the Solaris C compiler).  The minimum test that fails is 

$ php -d zend_extension=../modules/opcache.so -d opcache.enable=1 -d opcache.enable_cli=1
<?php
$config = opcache_get_configuration();
$status = opcache_get_status();
var_dump($config["directives"]["opcache.enable"]);

I'll trace this though dbg to work out the underlying bug and update the ticket :-)

 [2013-08-29 06:36 UTC] dmitry@php.net

-Assigned To: +Assigned To: dmitry

 [2013-08-29 22:36 UTC] craig dot mohrman at oracle dot com

To answer Terry's question:
PS for Craig:  (i) Does the Solaris compiler have a pragma/builtin equivalent to __alignof__, and what is the correct constant to use to test for the Solaris C compiler?

1) yes; Solaris Studio has
http://docs.oracle.com/cd/E19205-01/820-4155/c.html

Values are for this particular example:
x86 32-bit = 4
x86 64-bit = 8
sparc 32-bit = 8
sparc 64-bit = 8