ID: 48668
Comment by: dmda at yandex dot ru
Reported By: dmda at yandex dot ru
Status: Critical
Bug Type: Reproducible crash
Operating System: Solaris
PHP Version: 5.3.0RC4
Assigned To: dsp
New Comment:
another example is code below
execute_data = (zend_execute_data *)zend_vm_stack_alloc(
sizeof(zend_execute_data) +
sizeof(zval**) * op_array->last_var * (EG(active_symbol_table)
? 1 :
2) +
sizeof(temp_variable) * op_array->T TSRMLS_CC);
If I got it right, it tries to allocate multiple entities in the same
chunk of memory under zend_vm_stack's control.
If that's the case, all the entities should be aligned separately, like
below
execute_data = (zend_execute_data *)zend_vm_stack_alloc(
ZEND_MM_ALIGNED_SIZE(sizeof(zend_execute_data)) +
ZEND_MM_ALIGNED_SIZE(sizeof(zval**)) * op_array->last_var *
(EG(active_symbol_table) ? 1 : 2) +
ZEND_MM_ALIGNED_SIZE(sizeof(temp_variable)) * op_array->T
TSRMLS_CC);
Previous Comments:
------------------------------------------------------------------------
[2009-08-18 10:42:27] dmda at yandex dot ru
everything is correct, except 8byte requirement.
The alignment requirement for all CPUs (including x86, of course) is
per following:
to access data of n bytes, its address should start with n-byte
boundary, in particular
-to access 8byte data (such as 64bit long long) the address should be
aligned to 8byte boundary (for example 0x12340 and 0x12348 are correct
addresses, while 0x12344 and 0x12342 are not)
-to access 4byte data (such as 32bit integer) the address must be
aligned to 4byte (0x12340, 0x12344, and 0x12348 are correct addresses,
while 0x12342 is not)
-to access 2byte data (such as 16bit short) the address must be aligned
to 2byte (0x12340, 0x12342, 0x12344, and 0x12348 are correct)
in case of x86 CPU, it has 2 modes: it can raise interrupt or issue an
extra bus cycle to fetch the remaining data. Under most OSes x86 is
configured to issue bus cycle. As of the other CPUs they raise Bus
error.
How to fix:
the code below taken from zend_execute.h is just an example of bad
practice in address calculation:
size = (size + (sizeof(void*) - 1)) / sizeof(void*);
ZEND_VM_STACK_GROW_IF_NEEDED((int)size);
ret = (void*)EG(argument_stack)->top;
EG(argument_stack)->top += size;
it takes into account size of the addres (which is 32bit in my case),
but target data size may be 64bit.
Interestingly enough that an APPROPRIATE code can also be found there,
see Zend.m4 with ZEND_MM_ALIGNMENT, so it would be enough to replace
sizeof(void*) with ZEND_MM_ALIGNMENT :)
------------------------------------------------------------------------
[2009-08-18 04:02:34] sriram dot natarajan at gmail dot com
i have been looking into this issue over the week end and here is what
i found.
a) this is memory alignment issue and nothing to do with compilers or
optimizations. hence, bug - 47230
(http://bugs.php.net/bug.php?id=47230&edit=1) should be closed as
duplicate of this bug.
now, why this is happening ?
here is a rough and crude explanation : with php 5.3, addresses
returned from zend_vm_stack_top , _get_zval_ptr_tmp etc are not 8 byte
aligned. hence, accessing the 8 byte data results in crashes.
i haven't come up with a solution yet. i will look more into this after
next week.
------------------------------------------------------------------------
[2009-08-10 21:44:07] dmda at yandex dot ru
> by any chance, the submitter built this php5.3 on one machine
> and ran it on another machine ?
no.
> currently, php 5.3 build process includes -xtarget=native
> within the configure flags when used with sun studio compiler.
I used only gcc which is available from sunfreeware. It did never
create any problems with various applications I compiled with it,
including php versions from 4.0.6 up to 5.2.10.
------------------------------------------------------------------------
[2009-08-10 21:24:58] srina...@php.net
by any chance, the submitter built this php5.3 on one machine and ran
it on another machine ?
currently, php 5.3 build process includes -xtarget=native within the
configure flags when used with sun studio compiler. this would mean that
this compiled program will not work on different class of sparc machines
(unless recompiled for that platform)
for e.g, if some one currently built php 5.3 on ultra-sparc III+/IV+
based system (like v410, v220, v880 etc) then if they try to run the
same on older hardware with chips like sparc II+ hardware, then they
might run into crash.
------------------------------------------------------------------------
[2009-07-28 14:25:31] d...@php.net
PHP is broken on Sparc (and possible every other processor that
requires memalignment) at the moment
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/48668
--
Edit this bug report at http://bugs.php.net/?id=48668&edit=1
