ID: 25738 Comment by: mark dot meredith at shaw dot ca Reported By: ohornoiu at bellevuechristian dot org Status: Feedback Bug Type: Scripting Engine problem Operating System: Mac OS X 10.2.6+ PHP Version: 4.3.3 New Comment:
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. Previous Comments: ------------------------------------------------------------------------ [2003-10-03 15:46:30] [EMAIL PROTECTED] 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 15:42:10] mark dot meredith at shaw dot ca I downloaded and compiled again. And, yes, it still crashes. So why did my first comment on this, along with many others from other users on this page, as well as the #25394 page get deleted? I do not mean the comments that said "Me too!" on OPEN bug pages. Those can go. I am referring to the troubled user's posts that were requesting the bug be reopened, and my feedback on the snapshots. Are those deleted automatically? Feel free to delete this part of the comment, just please do not let it go unanswered. Thanks. ------------------------------------------------------------------------ [2003-10-03 01:53:58] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip ------------------------------------------------------------------------ [2003-10-02 22:13:09] 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. ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=25738&edit=1