php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #27161 phpSysInfo's usage of Php.Xpath class crashes Zend engine (segmentation fault)
Submitted: 2004-02-05 12:18 UTC Modified: 2004-02-09 14:50 UTC
From: bjorn dot wiberg at home dot se Assigned:
Status: Not a bug Package: Scripting Engine problem
PHP Version: 5CVS-2004-02-06 10:30 OS: Debian GNU/Linux 3.0r2 (mixed)
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: bjorn dot wiberg at home dot se
New email:
PHP Version: OS:

 

 [2004-02-05 12:18 UTC] bjorn dot wiberg at home dot se
Description:
------------
When running phpSysInfo, asking it to produce output in non-XML format (i.e. to use a template other than 'xml'), it crashes the Zend engine in its calls to the Php.Xpath class ($tpl->set_var(...)) and all you get in the web browser is a blank screen.

If one runs it with the ?template=xml parameter in the URL, the script correctly outputs XML data with the system information. But as soon as you call it without a parameter (it then defaults to a certain template), you get the error.

The Apache 2 error log shows that the worker thread exhibits a segmentation fault.

The same thing happens if you run the script from the command line through the PHP CLI.

Reproduce code:
---------------
Using phpSysInfo 2003-12-13 (CVS) version from http://phpsysinfo.sourceforge.net/phpsysinfo-20031213.tar.gz, but it also happens with earlier releases.

Using Debian Apache 2.0.48-7 (apache2-mpm-worker, apache2-common, apache2-doc).

More or less using the recommended php.ini-recommended settings in my php.ini (just some paths changed).

Also tried the latest stable version (3.4) of the Php.Xpath class from http://sourceforge.net/projects/phpxpath/, but that didn't help.


The failing calls seem to be the set_var() calls at the end of phpSysInfo's index.php script:

$tpl->set_var('title', $text['title'] . ': ' . 
(...)
  $tpl->set_var('vitals', makebox($text['vitals'], html_vitals(), '100%'));
  $tpl->set_var('network', makebox($text['netusage'], html_network(), '100%'));
  $tpl->set_var('hardware', makebox($text['hardware'], html_hardware(), '100%'));
  $tpl->set_var('memory', makebox($text['memusage'], html_memory(), '100%'));
  $tpl->set_var('filesystems', makebox($text['fs'], html_filesystems(), '100%'));


Expected result:
----------------
HTML output shown in the web browser with system information.

Actual result:
--------------
A blank page in the web browser.

From the Apache 2 error.log:

[Thu Feb 05 18:04:44 2004] [notice] child pid 3429 exit signal Segmentation fault (11)
[Thu Feb 05 18:04:46 2004] [notice] child pid 3430 exit signal Segmentation fault (11)

Executing the script through GDB and the PHP CLI instead of through Apache 2 yields the following information:

gloomy:/mnt/storage/usr/lib/php-bin/vhosts/bwiberg.dyndns.org/admin/phpSysInfo# gdb php
GNU gdb 2002-04-01-cvs
Copyright 2002 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-linux"...
(gdb) set args index.php
(gdb) run
Starting program: /usr/local/bin/php index.php
[New Thread 16384 (LWP 4481)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 4481)]
zend_case_handler (execute_data=0xbfff6c30, op_array=0x409f9f7c, tsrm_ls=0x8419ff8) at /root/software/php-5.0.0b3/Zend/zend_execute.c:58
58              z->refcount++;
(gdb) bt
#0  zend_case_handler (execute_data=0xbfff6c30, op_array=0x409f9f7c, tsrm_ls=0x8419ff8) at /root/software/php-5.0.0b3/Zend/zend_execute.c:58
#1  0x0820d235 in execute (op_array=0x409f9f7c, tsrm_ls=0x8419ff8) at /root/software/php-5.0.0b3/Zend/zend_execute.c:1260
#2  0x08210ac6 in zend_do_fcall_common_helper (execute_data=0xbfff7220, op_array=0x409e276c, tsrm_ls=0x8419ff8)
    at /root/software/php-5.0.0b3/Zend/zend_execute.c:2564
#3  0x08210df4 in zend_do_fcall_by_name_handler (execute_data=0x1, op_array=0x409e276c, tsrm_ls=0x8419ff8)
    at /root/software/php-5.0.0b3/Zend/zend_execute.c:2651
#4  0x0820d235 in execute (op_array=0x409e276c, tsrm_ls=0x8419ff8) at /root/software/php-5.0.0b3/Zend/zend_execute.c:1260
#5  0x08210ac6 in zend_do_fcall_common_helper (execute_data=0xbfff9a50, op_array=0x409e269c, tsrm_ls=0x8419ff8)
    at /root/software/php-5.0.0b3/Zend/zend_execute.c:2564
#6  0x08210df4 in zend_do_fcall_by_name_handler (execute_data=0x1, op_array=0x409e269c, tsrm_ls=0x8419ff8)
    at /root/software/php-5.0.0b3/Zend/zend_execute.c:2651
#7  0x0820d235 in execute (op_array=0x409e269c, tsrm_ls=0x8419ff8) at /root/software/php-5.0.0b3/Zend/zend_execute.c:1260
#8  0x08210ac6 in zend_do_fcall_common_helper (execute_data=0xbfffa0b0, op_array=0x409e2214, tsrm_ls=0x8419ff8)
    at /root/software/php-5.0.0b3/Zend/zend_execute.c:2564
#9  0x08210df4 in zend_do_fcall_by_name_handler (execute_data=0x1, op_array=0x409e2214, tsrm_ls=0x8419ff8)
    at /root/software/php-5.0.0b3/Zend/zend_execute.c:2651
#10 0x0820d235 in execute (op_array=0x409e2214, tsrm_ls=0x8419ff8) at /root/software/php-5.0.0b3/Zend/zend_execute.c:1260
#11 0x08210ac6 in zend_do_fcall_common_helper (execute_data=0xbfffa7b0, op_array=0x409dec44, tsrm_ls=0x8419ff8)
    at /root/software/php-5.0.0b3/Zend/zend_execute.c:2564
#12 0x08210df4 in zend_do_fcall_by_name_handler (execute_data=0x1, op_array=0x409dec44, tsrm_ls=0x8419ff8)
    at /root/software/php-5.0.0b3/Zend/zend_execute.c:2651
#13 0x0820d235 in execute (op_array=0x409dec44, tsrm_ls=0x8419ff8) at /root/software/php-5.0.0b3/Zend/zend_execute.c:1260
#14 0x08210ac6 in zend_do_fcall_common_helper (execute_data=0xbfffaeb0, op_array=0x409c9464, tsrm_ls=0x8419ff8)
    at /root/software/php-5.0.0b3/Zend/zend_execute.c:2564
#15 0x08210df4 in zend_do_fcall_by_name_handler (execute_data=0x1, op_array=0x409c9464, tsrm_ls=0x8419ff8)
    at /root/software/php-5.0.0b3/Zend/zend_execute.c:2651
#16 0x0820d235 in execute (op_array=0x409c9464, tsrm_ls=0x8419ff8) at /root/software/php-5.0.0b3/Zend/zend_execute.c:1260
#17 0x08210ac6 in zend_do_fcall_common_helper (execute_data=0xbfffb090, op_array=0x409c8ffc, tsrm_ls=0x8419ff8)
    at /root/software/php-5.0.0b3/Zend/zend_execute.c:2564
#18 0x08210df4 in zend_do_fcall_by_name_handler (execute_data=0x1, op_array=0x409c8ffc, tsrm_ls=0x8419ff8)
    at /root/software/php-5.0.0b3/Zend/zend_execute.c:2651
#19 0x0820d235 in execute (op_array=0x409c8ffc, tsrm_ls=0x8419ff8) at /root/software/php-5.0.0b3/Zend/zend_execute.c:1260
#20 0x08210ac6 in zend_do_fcall_common_helper (execute_data=0xbfffb680, op_array=0x409f4474, tsrm_ls=0x8419ff8)
    at /root/software/php-5.0.0b3/Zend/zend_execute.c:2564
#21 0x08210df4 in zend_do_fcall_by_name_handler (execute_data=0x1, op_array=0x409f4474, tsrm_ls=0x8419ff8)
    at /root/software/php-5.0.0b3/Zend/zend_execute.c:2651
#22 0x0820d235 in execute (op_array=0x409f4474, tsrm_ls=0x8419ff8) at /root/software/php-5.0.0b3/Zend/zend_execute.c:1260
#23 0x08212dc6 in zend_include_or_eval_handler (execute_data=0xbfffd6f0, op_array=0x1, tsrm_ls=0x8419ff8)
    at /root/software/php-5.0.0b3/Zend/zend_execute.c:3395
#24 0x0820d235 in execute (op_array=0x405dee94, tsrm_ls=0x8419ff8) at /root/software/php-5.0.0b3/Zend/zend_execute.c:1260
#25 0x081f273a in zend_execute_scripts (type=8, tsrm_ls=0x8419ff8, retval=0x0, file_count=3) at /root/software/php-5.0.0b3/Zend/zend.c:1048
#26 0x081be1c4 in php_execute_script (primary_file=0xbffffae0, tsrm_ls=0x8419ff8) at /root/software/php-5.0.0b3/main/main.c:1638
#27 0x08218b3c in main (argc=2, argv=0xbffffb64) at /root/software/php-5.0.0b3/sapi/cli/php_cli.c:910
(gdb) quit
A debugging session is active.
Do you still want to close the debugger?(y or n) y
gloomy:/mnt/storage/usr/lib/php-bin/vhosts/bwiberg.dyndns.org/admin/phpSysInfo#


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2004-02-06 11:20 UTC] sniper@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with <?php and ends with ?>,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc.

If possible, make the script source available online and provide
an URL to it here. Try avoid embedding huge scripts into the report.


 [2004-02-06 14:43 UTC] bjorn dot wiberg at home dot se
This does not happen with the PHP SAPI in PHP 5.0.0RC1-dev (snapshot 2004-02-06 10:30) which I'm running now -- however, even though it doesn't crash the Zend engine anymore, and nothing is shown in the Apache 2 error log, no output is produced to the web browser unless one calls the script with "?template=xml" at the end.

Calling the script from the CLI doesn't seem to work as it did in PHP 5.0.0b3 (where "php index.php?template=xml" from the command line worked -- now neither "php index.php template=xml" or "php index.php?template=xml" works), so I can't verify the CLI operation of the script.

If you have a couple of minutes left over, and would like to try the script (just unpack it somewhere in your php-bin directory and call index.php without parameters and with ?template=xml at the end, respectively), it can be downloaded from:
http://phpsysinfo.sourceforge.net/phpsysinfo-20031213.tar.gz

Even though I suspect that you can't be held responsible for arbitrary scripts sometimes not producing output. ;)

Nevertheless, it would be very interesting to know if the script produces output for you.

Thanks for your help!

Best regards,
Bj?rn
 [2004-02-09 12:13 UTC] sniper@php.net
Quick test shows that the script in question is not at all compatible with PHP 5. (there ARE differences..see README.PHP4-TO-PHP5-THIN-CHANGES)

And after nuking the error_reporting() in that one file caused so many warnings and notices that I gave up on trying to figure out what exactly is the main reason it didn't work.

As the crash is gone now, we'll have to assume the original bug has magically vanished too. :)

 [2004-02-09 14:50 UTC] bjorn dot wiberg at home dot se
:)

OK, thanks for your help!
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sun May 05 05:01:31 2024 UTC