ID:               47522
 Updated by:       stas@[...].net
 Reported By:      ms419 at freezone dot co dot uk
-Status:           No Feedback
+Status:           Verified
 Bug Type:         Reproducible crash
 Operating System: Debian
 PHP Version:      5.2CVS-2009-02-27 (snap)
 New Comment:

Verified for 5.2.x, not reproduceable for 5.3.x

Analysis: 
the problem is cause by applying strpos() to Zend_Date object. When
convert_to_string in strpos() is called to convert object to string,
Zend_Date::__toString is called and on the course of the execution the
variable stack is reallocated. However haystack variable still points to
the old stack location, which means any access to it will produce the
UMR. Valgrind dump:

=22070== Invalid read of size 4
==22070==    at 0x81E36FB: zif_strpos (string.c:1814)
==22070==    by 0x8292509: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:200)
==22070==    by 0x827F6AF: execute (zend_vm_execute.h:92)
==22070==    by 0x8291E75: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)
==22070==    by 0x827F6AF: execute (zend_vm_execute.h:92)
==22070==    by 0x8291E75: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)
==22070==    by 0x827F6AF: execute (zend_vm_execute.h:92)
==22070==    by 0x8291E75: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)
==22070==    by 0x827F6AF: execute (zend_vm_execute.h:92)
==22070==    by 0x8251FC7: zend_eval_string (zend_execute_API.c:1214)
==22070==    by 0x825211E: zend_eval_string_ex
(zend_execute_API.c:1248)
==22070==    by 0x82CAACF: main (in /root/php)
==22070==  Address 0x4C876E4 is 52 bytes inside a block of size 256
free'd
==22070==    at 0x40054FB: realloc (vg_replace_malloc.c:306)
==22070==    by 0x8291F2C: zend_do_fcall_common_helper_SPEC
(zend_ptr_stack.h:73)
==22070==    by 0x827F6AF: execute (zend_vm_execute.h:92)
==22070==    by 0x8291E75: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)
==22070==    by 0x827F6AF: execute (zend_vm_execute.h:92)
==22070==    by 0x8291E75: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)
==22070==    by 0x827F6AF: execute (zend_vm_execute.h:92)
==22070==    by 0x8291E75: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)
==22070==    by 0x827F6AF: execute (zend_vm_execute.h:92)
==22070==    by 0x8291E75: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)
==22070==    by 0x827F6AF: execute (zend_vm_execute.h:92)
==22070==    by 0x8291E75: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:234)

Not sure how to fix it.


Previous Comments:
------------------------------------------------------------------------

[2009-07-30 22:12:47] alex at innovacomputing dot com

I'm able to reproduce this as well on PHP 5.2.9 on Debian Linux 5.0
i386, but not on amd64 versions.

I was able to reproduce this by unpacking Zend Framework 1.8.4 and
running the following PHP script:

<?php
require_once 'Zend/Date.php';
$x = new Zend_Date();
$y = new Zend_Date($x);

In this case, it seems to happen when passing an object to strpos(). 
I've noticed that when you do this, it does not immediately segfault. 
Instead, it continues executing PHP code, until the Zend_Date
constructor returns, at which point it segfaults.

I've posted a workaround for Zend Framework at
http://framework.zend.com/issues/browse/ZF-7413 .

Here's a backtrace from gdb:
#0  0x0824d2a0 in zif_strpos (ht=2, return_value=0xb6900238,
return_value_ptr=0x0, this_ptr=0x0,
    return_value_used=1) at
/usr/src/php5/source/php5-5.2.9/ext/standard/string.c:1814
#1  0x0832a413 in zend_do_fcall_common_helper_SPEC
(execute_data=0xbf822cec)
    at /usr/src/php5/source/php5-5.2.9/Zend/zend_vm_execute.h:200
#2  0x08315580 in execute (op_array=0xb688ea80)
    at /usr/src/php5/source/php5-5.2.9/Zend/zend_vm_execute.h:92
#3  0x08329cd6 in zend_do_fcall_common_helper_SPEC
(execute_data=0xbf82311c)
    at /usr/src/php5/source/php5-5.2.9/Zend/zend_vm_execute.h:234
#4  0x08315580 in execute (op_array=0xb688a90c)
    at /usr/src/php5/source/php5-5.2.9/Zend/zend_vm_execute.h:92
#5  0x08329cd6 in zend_do_fcall_common_helper_SPEC
(execute_data=0xbf823a5c)
    at /usr/src/php5/source/php5-5.2.9/Zend/zend_vm_execute.h:234
#6  0x08315580 in execute (op_array=0x9c163d4)
    at /usr/src/php5/source/php5-5.2.9/Zend/zend_vm_execute.h:92
#7  0x08329cd6 in zend_do_fcall_common_helper_SPEC
(execute_data=0xbf823c7c)
    at /usr/src/php5/source/php5-5.2.9/Zend/zend_vm_execute.h:234
#8  0x08315580 in execute (op_array=0x9c0dbbc)
    at /usr/src/php5/source/php5-5.2.9/Zend/zend_vm_execute.h:92
#9  0x082e28ce in zend_eval_string (
    str=0xbf82593e "require_once \"Zend/Date.php\"; $x = new
Zend_Date(); $y = new Zend_Date($x);", retval_ptr=0x0,
string_name=0x8551cfc "Command line code")
    at /usr/src/php5/source/php5-5.2.9/Zend/zend_execute_API.c:1217
#10 0x082e2a3b in zend_eval_string_ex (
    str=0xbf82593e "require_once \"Zend/Date.php\"; $x = new
Zend_Date(); $y = new Zend_Date($x);", retval_ptr=0x0,
string_name=0x8551cfc "Command line code", handle_exceptions=1)
    at /usr/src/php5/source/php5-5.2.9/Zend/zend_execute_API.c:1251
#11 0x083755f9 in main (argc=3, argv=0xbf824044)
    at /usr/src/php5/source/php5-5.2.9/sapi/cli/php_cli.c:1178

------------------------------------------------------------------------

[2009-03-28 01:00:01] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

------------------------------------------------------------------------

[2009-03-20 15:37:22] pajoye@[...].net

Please provide a small script to reproduce the problem. The Zend
Framework is not a small script. You can also post a bug there and ask
them to figure out what's wrong.

------------------------------------------------------------------------

[2009-03-20 15:04:30] josh dot butts at vertive dot com

We have also tracked down a segfault which appears to be directly
related to this.  

<?=html_entity_decode($form-> getElement('query'))?>

where $form is a Zend_Form object from Zend Framework.  Not able to
reproduce it out of context but within the  context of the site happens
almost 100% of the time.  Removing html_entity_decode() fixes the
segfault, as does casting (string) on the $form, or calling
$form-> render().  The implicit call to __toString() appears to be the
root cause of this problem.

------------------------------------------------------------------------

[2009-03-02 19:23:02] ms419 at freezone dot co dot uk

Unfortunately I have been unable to reproduce this segfault in a short
script - it seems whenever I try to cut something out of the larger
project where it occurs, the segfault disappears.

Casting the object to a string in a parent function does not produce a
segfault, while calling a function and casting in the called function
does. Even passing the object as the first as opposed to fourth argument
of the function causes the segfault to disappear.

The segfault occurs at line eight of this file:
http://code.google.com/p/qubit-toolkit/source/browse/trunk/qubit/apps/qubit/modules/reposito
ry/templates/showIsdiahSuccess.php#8

Since r2041, a workaround has been committed to the render_title()
function: http://code.google.com/p/qubit-toolkit/source/detail?r=2041

Removing that workaround causes the segfault to reappear.

I am eager to help any way I can - but I have had no luck reproducing
this segfault in a short script...

------------------------------------------------------------------------

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/47522

-- 
Edit this bug report at http://bugs.php.net/?id=47522&edit=1