php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #25738 Long Scripts Consistently Segfault
Submitted: 2003-10-02 22:13 UTC Modified: 2003-10-03 19:20 UTC
Votes:4
Avg. Score:4.5 ± 0.9
Reproduced:4 of 4 (100.0%)
Same Version:0 (0.0%)
Same OS:0 (0.0%)
From: ohornoiu at bellevuechristian dot org Assigned:
Status: Closed Package: Scripting Engine problem
PHP Version: 4.3.3 OS: Mac OS X 10.2.6+
Private report: No CVE-ID: None
View Add Comment Developer Edit
 [2003-10-02 22:13 UTC] ohornoiu at bellevuechristian dot org 
Description:
------------
This bug is a reference to Bug?#25394 which was deemed 
"bogus" without any serious research by the developers.  
This is a very serious bug which basically results in the 
inability to create rich, meaningful applications on OS X 
since php consistently and mindlessly crashes on this 
platform.  The venom with which this topic was approached 
by the developers in this forum in the past is entirely 
innapropriate for an open source project and I expect a 
more fair and thorough investigation this time since I am 
providing a concrete script that is part of a huge 77,000 
line project for school calendaring called Kronophobia. 
  
I am the lead developer of this project and some of my 
users have requested to run this project on Mac OS X only 
to find out that this bug affects them in such a way as to 
make using the program impossible.  This bug does not 
exist in Linux, FreeBSD or OpenBSD, all of which have been 
thoroughly tested and we support. 
 
If the php developers refuse to look at this code for some 
reason because it is "beneath" them to fix a Mac problem 
since they do not care about Mac OS X then I would at 
least expect some sort of public statement about this and 
an explanation to the Mac community of why they are to be 
ostracized. 

Reproduce code:
---------------
The Kronophobia package is available from the following url:

http://kronophobia.sourceforge.net

The main file of the project, index.php is the affected file as it spans roughly 7,000 lines of code.

Expected result:
----------------
When run on any other platform besides Mac OS X, the code 
renders the page in question flawlessly.  The page is just 
a series of switch() statements with multiple includes for 
each case. 

Actual result:
--------------
The actual result is an apache segfault, a "Page not 
Found" error results in the browser and a crash is logged 
in apache logfiles. 
 
 
NO, increasing the memory limit in PHP does NOT fix this 
problem like some have suggested and PHP seems to only use 
about 1 megabyte of memory even after 7k lines of code.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-10-03 15:46 UTC] moriyoshi@php.net 
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.


NOTE: See also bug #22231, bug #22367, and bug #22510.
 [2003-10-03 16:14 UTC] mark dot meredith at shaw dot ca 
Here is the backtrace as a result of crashing the simpler, 
$x = 1; done 10,000 times script as per the original 
reported bug #25394...

#0  0x900048b0 in malloc ()
(gdb) bt
#0  0x900048b0 in malloc ()
#1  0x000f0bb4 in zend_hash_add_or_update (ht=0x139c14, 
arKey=0x3773a8 "x", nKeyLength=2, pData=0xbff80184, 
nDataSize=4, pDest=0xbff80168, flag=1) at /Users/markmere/
Sources/php4-snapshot/Zend/zend_hash.c:272
#2  0x000fe230 in zend_fetch_var_address (opline=0x424028, 
Ts=0xbff801e0, type=1) at /Users/markmere/Sources/php4-
snapshot/Zend/zend_execute.c:596
#3  0x00100a88 in execute (op_array=0x375f28) at /Users/
markmere/Sources/php4-snapshot/Zend/zend_execute.c:1252
#4  0x000e9f94 in zend_execute_scripts (type=8, retval=0x0, 
file_count=3) at /Users/markmere/Sources/php4-snapshot/
Zend/zend.c:885
#5  0x0009c6b8 in php_execute_script 
(primary_file=0xbffff760) at /Users/markmere/Sources/php4-
snapshot/main/main.c:1732
#6  0x0010a744 in main (argc=2, argv=0xbffffcc0) at /Users/
markmere/Sources/php4-snapshot/sapi/cli/php_cli.c:819
#7  0x00001a50 in _start (argc=2, argv=0xbffffcc0, 
envp=0xbffffccc) at /SourceCache/Csu/Csu-45/crt.c:267
#8  0x000018d0 in start ()

... I generated this backtrace using the latest snapshot.

Bug #29394 is just a test case representing any script long 
enough to tickle the crasher. It is just $x = 1; done 
around 10,000 times. On my Mac, it takes 8041 assignments. 
The crasher still goes if the script is broken up into 
multiple include()'s.
 [2003-10-03 17:25 UTC] wez@php.net 
Using:
Darwin aphrodite 6.6 Darwin Kernel Version 6.6:
Thu May  1 21:48:54 PDT 2003;
root:xnu/xnu-344.34.obj~1/RELEASE_PPC
Power Macintosh powerpc

latest PHP_4_3 branch, a vanilla configure, and a
script containing approx 16000 $x=1; assignments, I get
this:

Program received signal EXC_BAD_ACCESS, Could not access memory.
execute (op_array=0x460780) at /Users/wez/src/php4.3cvs/Zend/zend_execute.c:1027
1027            EX(Ts) = (temp_variable *) do_alloca(sizeof(temp_variable)*op_array->T);
(gdb) bt
#0  execute (op_array=0x460780) at /Users/wez/src/php4.3cvs/Zend/zend_execute.c:1027
#1  0x000d6b14 in zend_execute_scripts (type=0, retval=0x0, file_count=3) at /Users/wez/src/php4.3cvs/Zend/zend.c:885
#2  0x000ab9e8 in php_execute_script (primary_file=0x0) at /Users/wez/src/php4.3cvs/main/main.c:1732
#3  0x000e9f88 in main (argc=3, argv=0xbffffd60) at /Users/wez/src/php4.3cvs/sapi/cli/php_cli.c:819
#4  0x000023e4 in _start (argc=3, argv=0xbffffd60, envp=0xbffffd70) at /SourceCache/Csu/Csu-45/crt.c:267
#5  0x00002264 in start ()

My guess is that we are overflowing either the stack
or the Ts storage space since the scope of the function
"never" ends.
 [2003-10-03 17:36 UTC] moriyoshi@php.net 
Sounds like yet another alloca() problem to me.
Could try this patch and tell me what would actually happen.

http://www.voltex.jp/patches/bug25738-preliminary.patch.diff
 [2003-10-03 17:58 UTC] wez@php.net 
Seems to work for me.
 [2003-10-03 19:18 UTC] mark dot meredith at shaw dot ca 
Beautiful. The patch seems to work for me as well. I tried 
with over 100,000 assignments with no problems.
 [2003-10-03 19:20 UTC] moriyoshi@php.net 
This bug has been fixed in CVS.

In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.

Thank you again!
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Fri Apr 19 23:01:28 2024 UTC