php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #39620 SEGV in zend_do_fcall_common_helper_SPEC
Submitted: 2006-11-24 15:09 UTC Modified: 2006-12-12 08:35 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: jens at strawberry dot com Assigned: tony2001 (profile)
Status: Closed Package: Reproducible crash
PHP Version: 5.2.0, 5.2.1-dev OS: Solaris 8, 32bit, Solaris 10 x86
Private report: No CVE-ID: None
 [2006-11-24 15:09 UTC] jens at strawberry dot com
Description:
------------
I've compiled and installed PHP version 5.2.0
in the following environment:

   Server:  SparcStation 20 dual CPU
   OS:      Solaris 8, Kernel patch 117350-41
   Apache:  2.2.2

The apache server starts and answers requests.
Upon loading a php test page from this server, the
http server process begins consuming 100% CPU and
finally crashes in format_converter with signal 11
(SEGV).

Reproduce code:
---------------
Enable short tags in php.ini.
Load the following page from the server

test.php:
<?phpinfo()?>


Expected result:
----------------
Info page should show up.
http process should keep stable.

Actual result:
--------------
http server enters a loop between the functions
zend_do_fcall_common_helper_SPEC and 
execute_internal which after a while leads to the SEGV
in format_converter

The following output is produced using adb attached to a
nonfork apache server:



SIGSEGV: Segmentation Fault (address not mapped to object)
stopped at:
format_converter+8:             st      %i0, [%sp + 0x64]
symbol not found
process terminated

$c
...
execute_internal(0xed4bd430,0x14,0xefff7f08,0xed673178,0x501be8,0x50) + 204
        [savfp=0xefff7f48,savpc=0xed4bd064]
zend_do_fcall_common_helper_SPEC(0xefff8088,0xefff808c,0xce2c,0xefff8494,0x1,0x0) + 4c8
        [savfp=0xefff7fa8,savpc=0xed4bcb18]
execute_internal(0xed4bd430,0x1,0xefff8088,0xed673178,0x457a80,0x4) + 204
        [savfp=0xefff80c8,savpc=0xed4bd064]
zend_do_fcall_common_helper_SPEC(0xefff84a8,0xefff84ac,0xce2c,0xefff8724,0x1,0x0) + 4c8
        [savfp=0xefff8128,savpc=0xed4bcb18]
execute_internal(0xed4bd430,0x7,0xefff84a8,0xed673178,0x4f8578,0x1c) + 204
        [savfp=0xefff84e8,savpc=0xed4bd064]
zend_do_fcall_common_helper_SPEC(0xefff8768,0xefff876c,0xce2c,0xefff914c,0x1,0x0) + 4c8
        [savfp=0xefff8548,savpc=0xed4bcb18]
execute_internal(0xed4bd430,0xa,0xefff8768,0xed673178,0x5324e8,0x28) + 204
        [savfp=0xefff87a8,savpc=0xed4bd064]
zend_do_fcall_common_helper_SPEC(0xefffef80,0xefffef84,0xce2c,0xeffff0b4,0x1,0x0) + 4c8
        [savfp=0xefff8808,savpc=0xed4bcb18]
execute_internal(0xed4bd430,0x76,0xefffef80,0xed673178,0x41e4c0,0x1d8) + 204
        [savfp=0xefffefc0,savpc=0xed489a30]
zend_execute_scripts(0x8,0x0,0x3,0xeffff65c,0xed672f58,0x0) + 110
        [savfp=0xeffff0b8,savpc=0xed4111f8]
php_execute_script(0xa800,0x25edc8,0xed5c9f8c,0xed6729a8,0xd000,0x3c) + 350
        [savfp=0xeffff5b8,savpc=0xed502f0c]
php_handler(0x262178,0xd018,0xed5c9f8c,0xd400,0xc800,0x0) + 588
        [savfp=0xeffff6e0,savpc=0x402e0]
ap_run_handler(0x25cf98,0x94980,0x948f0,0xffffffff,0x6,0x948f0) + 48
        [savfp=0xeffff740,savpc=0x409a4]
ap_invoke_handler(0x25cf98,0x238018,0x25cf98,0x953a8,0x0,0x0) + f8
        [savfp=0xeffff7a8,savpc=0x4d7cc]
ap_process_request(0x25cf98,0x0,0xc8,0x25cf98,0x0,0x0) + 54
        [savfp=0xeffff808,savpc=0x4ac78]
ap_filter_protocol(0x246680,0x25cf98,0x79800,0x1,0x1000,0x5) + 31c
        [savfp=0xeffff868,savpc=0x46db8]
ap_run_process_connection(0x246680,0x95064,0x95010,0xffffffff,0x3,0x95010) + 48
        [savfp=0xeffff8c8,savpc=0x520a0]
ap_graceful_stop_signalled(0x53dac,0x246680,0x7c400,0x7e800,0x0,0x1) + 40c
        [savfp=0xeffff960,savpc=0x52190]
ap_graceful_stop_signalled(0x88448,0x0,0x94e0c,0x94de0,0xffffffff,0x79800) + 4fc
        [savfp=0xeffff9c0,savpc=0x5270c]
ap_mpm_run(0x865a8,0x79800,0x88448,0x79800,0x79b6c,0x7c6e8) + 1c8
        [savfp=0xeffffa40,savpc=0x2c8d4]
main(0x79800,0x0,0x5e400,0x0,0x78958,0x88448) + 97c
        [savfp=0xeffffac8,savpc=0x2b714]


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2006-11-24 15:11 UTC] tony2001@php.net
Please try using this CVS snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5.2-win32-latest.zip


 [2006-11-29 06:14 UTC] jens at strawberry dot com
Hi,

I tried it again with 

   5.2.0 on Solaris 10 x86
   php5.2-200611281530 also on Solaris 10 x86

Both of them show the same behavior. 

This bug has heavy impact! It results in PHP being unusable at all in this environment. The bug is pretty reproducable. It happens everytime a script consisting of <?phpinfo()?> is called.

However, I have a PHP 5.1.4 running on Solaris 10 Sparc in a 64 Bit environment which does not show this problems. At the time being I've only seen it in 32 bit environments.

Jens
 [2006-11-29 06:27 UTC] jens at strawberry dot com
Hi,

I've sent the output of phpinfo directly to tony2001@php.net

Jens
 [2006-11-29 08:06 UTC] jens at strawberry dot com
Bug also found in 5.2.1-dev
 [2006-11-29 08:07 UTC] jens at strawberry dot com
Bug also found on Solaris 10 x86 (32bit)
 [2006-11-29 10:19 UTC] tony2001@php.net
Let me guess: you're using GCC 4.1.x, right?
 [2006-11-29 11:08 UTC] jens at strawberry dot com
I'm using Sun Studio 11.0 
Sun patch 121016-03 is applied to this compiler.

Jens
 [2006-11-29 11:14 UTC] tony2001@php.net
On both Solaris 8 and Solaris 10?
 [2006-11-29 11:34 UTC] jens at strawberry dot com
Hi,

yes and no.

SunStudio 11.0 requires either a UltraSparc II, a Intel
or AMD CPU (32 and 64 bit for Intel and AMD). It does not
support HyperSparc and SuperSparc CPUs. 

Thus I'm using

   SunStudio 11.0 for
       8/9/10   Sparc 64 bit
       8/9/10   Intel 32 bit

   SunStudio 8.0 for
       8/9      Sparc 32 bit

It turns out that in fact I was using 3 different compilers
in this case:

   SunStudio 11.0 for Sparc 64 bit
       -> Everything fine. Problem does not occur

   SunStudio 11.0 for Intel
       -> Problem

   SunStudio 8.0 for Sparc 32 bit
       -> Problem

I was also hoping that it could be a compiler issue on the
32bit Sparc box, but in this case the same problem would be
in the 11.0 Intel version of the Sun compiler but not in
the Sparc version ... unlikely but possible ;-)

Jens
 [2006-11-29 11:36 UTC] tony2001@php.net
Is it possible to get GDB backtrace instead of dbx (or whatever it was..) ?
 [2006-11-29 13:10 UTC] jens at strawberry dot com
Unfortunatelly no ...


Ther's no gdb on the system. The only one I found
on the net (sunfreeware) is for Solaris 8 x86. And this
version starts and crashes when it tries to read the 
symbol table.

The traceback I've provided is produced using adb/mdb
which is shipped with Solaris.



<Boreas,root> local 80 # gdb /opt/apache_2.2.2/bin/httpd 4141 |& tee -a /var/tmp/apache.gdb
GNU gdb 6.0
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-pc-solaris2.8"...
(no debugging symbols found)...
Attaching to program `/opt/apache_2.2.2/bin/httpd', process 4141
Reading symbols from /opt/apache_2.2.2/lib/libaprutil-1.so.0...Segmentation fault



Bummer ...
 [2006-11-29 13:22 UTC] tony2001@php.net
Ok, is it possible to get an account on one of these machines?
I can't reproduce it on SunOS 5.8 with gcc, but I don't have a Solaris 10 machine near at hand.
 [2006-11-29 13:43 UTC] jens at strawberry dot com
I've created an account for you.

Login, password and other things in a mail direct
to you ;-)

Jens
 [2006-12-12 08:35 UTC] jens at strawberry dot com
Bug found in apache 2.2.x mod_dbd.
Apache bug id 41142.
This is not ap PHP bug
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Wed Apr 24 07:01:29 2024 UTC