[PHP-DEV] PHP 4.0 Bug #10230 Updated: Apache Segmentation Fault
ID: 10230 User Update by: [EMAIL PROTECTED] Old-Status: Feedback Status: Open Bug Type: Reproduceable crash Description: Apache Segmentation Fault I was desperately searching for code fragments that seemed to reproduce the problem, but I ran into it in the midst of an EXTREMELY large object-oriented app built on top of a full-blown generic PHP object framework...the page on which the error was generated was parsing at least 1500 lines of code before executing. Given that I was getting NO output for feedback, it was impossible to tell during what segment of execution PHP was tanking. I've written tens of thousands of lines of PHP code, and never ran into this problem before, so I knew it wasn't a simple matter, and wasn't likely to be captured in a short, self-contained script. Not much help for tracking down the problem, I know, but it is likely that it was a case of a whole series of events/variable declarations/parse errors that all contributed to the crash. Altering the code in several places at once (since most functionality was dependant upon other functionality) was the only way I managed to resolve the issue and stop the crashes. Previous Comments: --- [2001-04-08 01:54:20] [EMAIL PROTECTED] It would help a lot if you would add a shortest possible self containing script into this report which could be used to reproduce this. And you should also try with latest CVS snapshot from http://snaps.php.net/ --Jani --- [2001-04-08 01:38:56] [EMAIL PROTECTED] After careful rewriting of several code segments that contributed to the conditions causing the crash, I appear to have resolved the problem. I can now attribute the circumstances to bad coding somewhere, but there was nonetheless something un-graceful about PHP's handling of the error. I'll leave the bug open for now in case someone wants to look at cleaning up PHP's manner of handling the error, but close it if appropriate. --- [2001-04-07 20:41:24] [EMAIL PROTECTED] While developing a complex PHP application, I wrote an include file that generates a simple web-based form. This include file is accessed through one of 2 different pages (admins.php or members.php). When the file is included in admins.php, everything works peachy. When the file is included in members.php, the form only partially displays, Apache generates a seg fault, and the page is never rendered. This problem occurred on only one other script page that I noticed. I originally discovered this with an OS X install (on a dual-G4, built from packages found on the web), but copied all the relevant files to a Linux PPC machine (604e) with different build options, and encountered the same problem there. Then I copied the files to an OpenBSD machine, and did NOT see the problem (which leads me to believe it may be processor related). I built a new version of PHP to include --enable-debug and a few other options (gd, trans-sid), and now even MORE pages generate seg faults, though a simple php_info() page works fine. I'm including below a copy of the Apache seg fault error line, and the backtrace. Happy to allow access to php_info upon request... Apache's error log reads: [Sat Apr 7 20:18:18 2001] [notice] child pid 25681 exit signal Segmentation fault (11) No core is dumped (Mac OS X doesn't seem to do this). Running Apache under gdb as instructed generates this backtrace: #0 0x00ee7a4c in execute (op_array=0x9179b4) at ./ zend_execute.c:925 #1 0x00eebcd8 in execute (op_array=0x916fc4) at ./ zend_execute.c:1559 #2 0x00eebcd8 in execute (op_array=0x6f8e84) at ./ zend_execute.c:1559 #3 0x00eebcd8 in execute (op_array=0xa65880) at ./ zend_execute.c:1559 #4 0x00eebcd8 in execute (op_array=0x69ac94) at ./ zend_execute.c:1559 #5 0x00eebcd8 in execute (op_array=0x9179b4) at ./ zend_execute.c:1559 #6 0x00eebcd8 in execute (op_array=0x916fc4) at ./ zend_execute.c:1559 #7 0x00eebcd8 in execute (op_array=0x6f8e84) at ./ zend_execute.c:1559 #8 0x00eebcd8 in execute (op_array=0xa65880) at ./ zend_execute.c:1559 #9 0x00eebcd8 in execute (op_array=0x69ac94) at ./ zend_execute.c:1559 #10 0x00eebcd8 in execute (op_array=0x9179b4) at ./ zend_execute.c:1559 #11 0x00eebcd8 in execute (op_array=0x916fc4) at ./ zend_execute.c:1559 #12 0x00eebcd8 in execute (op_array=0x6f8e84) at ./ zend_execute.c:1559 #13 0x00eebcd8 in execute (op_array=0xa65880) at ./ zend_execute.c:1559 #14 0x00eebcd8 in execute (op_array=0x69ac94) at ./ zend_execute.c:1559 #15 0x00eebcd8 in execute (op_array=0x9179b4) at ./ zend_execute.c:1559 #16 0x00eebcd8 in execute (op_array=0x916fc4) at ./ zend_execute.c:1559 #17 0x00eebcd8 in execute (op_array=0x6f8e84) at
[PHP-DEV] PHP 4.0 Bug #10230 Updated: Apache Segmentation Fault
ID: 10230 Updated by: bbonev Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: Reproduceable crash Assigned To: Comments: i am almost sure this is the infinite include problem. e.g. a.php: ?include 'a.php'? it is known and can be fixed using include_once/require_once if you have found something different, please reopen Previous Comments: --- [2001-04-08 03:22:19] [EMAIL PROTECTED] I was desperately searching for code fragments that seemed to reproduce the problem, but I ran into it in the midst of an EXTREMELY large object-oriented app built on top of a full-blown generic PHP object framework...the page on which the error was generated was parsing at least 1500 lines of code before executing. Given that I was getting NO output for feedback, it was impossible to tell during what segment of execution PHP was tanking. I've written tens of thousands of lines of PHP code, and never ran into this problem before, so I knew it wasn't a simple matter, and wasn't likely to be captured in a short, self-contained script. Not much help for tracking down the problem, I know, but it is likely that it was a case of a whole series of events/variable declarations/parse errors that all contributed to the crash. Altering the code in several places at once (since most functionality was dependant upon other functionality) was the only way I managed to resolve the issue and stop the crashes. --- [2001-04-08 01:54:20] [EMAIL PROTECTED] It would help a lot if you would add a shortest possible self containing script into this report which could be used to reproduce this. And you should also try with latest CVS snapshot from http://snaps.php.net/ --Jani --- [2001-04-08 01:38:56] [EMAIL PROTECTED] After careful rewriting of several code segments that contributed to the conditions causing the crash, I appear to have resolved the problem. I can now attribute the circumstances to bad coding somewhere, but there was nonetheless something un-graceful about PHP's handling of the error. I'll leave the bug open for now in case someone wants to look at cleaning up PHP's manner of handling the error, but close it if appropriate. --- [2001-04-07 20:41:24] [EMAIL PROTECTED] While developing a complex PHP application, I wrote an include file that generates a simple web-based form. This include file is accessed through one of 2 different pages (admins.php or members.php). When the file is included in admins.php, everything works peachy. When the file is included in members.php, the form only partially displays, Apache generates a seg fault, and the page is never rendered. This problem occurred on only one other script page that I noticed. I originally discovered this with an OS X install (on a dual-G4, built from packages found on the web), but copied all the relevant files to a Linux PPC machine (604e) with different build options, and encountered the same problem there. Then I copied the files to an OpenBSD machine, and did NOT see the problem (which leads me to believe it may be processor related). I built a new version of PHP to include --enable-debug and a few other options (gd, trans-sid), and now even MORE pages generate seg faults, though a simple php_info() page works fine. I'm including below a copy of the Apache seg fault error line, and the backtrace. Happy to allow access to php_info upon request... Apache's error log reads: [Sat Apr 7 20:18:18 2001] [notice] child pid 25681 exit signal Segmentation fault (11) No core is dumped (Mac OS X doesn't seem to do this). Running Apache under gdb as instructed generates this backtrace: #0 0x00ee7a4c in execute (op_array=0x9179b4) at ./ zend_execute.c:925 #1 0x00eebcd8 in execute (op_array=0x916fc4) at ./ zend_execute.c:1559 #2 0x00eebcd8 in execute (op_array=0x6f8e84) at ./ zend_execute.c:1559 #3 0x00eebcd8 in execute (op_array=0xa65880) at ./ zend_execute.c:1559 #4 0x00eebcd8 in execute (op_array=0x69ac94) at ./ zend_execute.c:1559 #5 0x00eebcd8 in execute (op_array=0x9179b4) at ./ zend_execute.c:1559 #6 0x00eebcd8 in execute (op_array=0x916fc4) at ./ zend_execute.c:1559 #7 0x00eebcd8 in execute (op_array=0x6f8e84) at ./ zend_execute.c:1559 #8 0x00eebcd8 in execute (op_array=0xa65880) at ./ zend_execute.c:1559 #9 0x00eebcd8 in execute (op_array=0x69ac94) at ./ zend_execute.c:1559 #10 0x00eebcd8 in execute (op_array=0x9179b4) at ./ zend_execute.c:1559 #11 0x00eebcd8 in execute (op_array=0x916fc4) at ./ zend_execute.c:1559 #12 0x00eebcd8 in execute (op_array=0x6f8e84) at ./ zend_execute.c:1559 #13 0x00eebcd8 in
[PHP-DEV] PHP 4.0 Bug #10230 Updated: Apache Segmentation Fault
ID: 10230 User Update by: [EMAIL PROTECTED] Status: Open Bug Type: Reproduceable crash Description: Apache Segmentation Fault After careful rewriting of several code segments that contributed to the conditions causing the crash, I appear to have resolved the problem. I can now attribute the circumstances to bad coding somewhere, but there was nonetheless something un-graceful about PHP's handling of the error. I'll leave the bug open for now in case someone wants to look at cleaning up PHP's manner of handling the error, but close it if appropriate. Previous Comments: --- [2001-04-07 20:41:24] [EMAIL PROTECTED] While developing a complex PHP application, I wrote an include file that generates a simple web-based form. This include file is accessed through one of 2 different pages (admins.php or members.php). When the file is included in admins.php, everything works peachy. When the file is included in members.php, the form only partially displays, Apache generates a seg fault, and the page is never rendered. This problem occurred on only one other script page that I noticed. I originally discovered this with an OS X install (on a dual-G4, built from packages found on the web), but copied all the relevant files to a Linux PPC machine (604e) with different build options, and encountered the same problem there. Then I copied the files to an OpenBSD machine, and did NOT see the problem (which leads me to believe it may be processor related). I built a new version of PHP to include --enable-debug and a few other options (gd, trans-sid), and now even MORE pages generate seg faults, though a simple php_info() page works fine. I'm including below a copy of the Apache seg fault error line, and the backtrace. Happy to allow access to php_info upon request... Apache's error log reads: [Sat Apr 7 20:18:18 2001] [notice] child pid 25681 exit signal Segmentation fault (11) No core is dumped (Mac OS X doesn't seem to do this). Running Apache under gdb as instructed generates this backtrace: #0 0x00ee7a4c in execute (op_array=0x9179b4) at ./ zend_execute.c:925 #1 0x00eebcd8 in execute (op_array=0x916fc4) at ./ zend_execute.c:1559 #2 0x00eebcd8 in execute (op_array=0x6f8e84) at ./ zend_execute.c:1559 #3 0x00eebcd8 in execute (op_array=0xa65880) at ./ zend_execute.c:1559 #4 0x00eebcd8 in execute (op_array=0x69ac94) at ./ zend_execute.c:1559 #5 0x00eebcd8 in execute (op_array=0x9179b4) at ./ zend_execute.c:1559 #6 0x00eebcd8 in execute (op_array=0x916fc4) at ./ zend_execute.c:1559 #7 0x00eebcd8 in execute (op_array=0x6f8e84) at ./ zend_execute.c:1559 #8 0x00eebcd8 in execute (op_array=0xa65880) at ./ zend_execute.c:1559 #9 0x00eebcd8 in execute (op_array=0x69ac94) at ./ zend_execute.c:1559 #10 0x00eebcd8 in execute (op_array=0x9179b4) at ./ zend_execute.c:1559 #11 0x00eebcd8 in execute (op_array=0x916fc4) at ./ zend_execute.c:1559 #12 0x00eebcd8 in execute (op_array=0x6f8e84) at ./ zend_execute.c:1559 #13 0x00eebcd8 in execute (op_array=0xa65880) at ./ zend_execute.c:1559 #14 0x00eebcd8 in execute (op_array=0x69ac94) at ./ zend_execute.c:1559 #15 0x00eebcd8 in execute (op_array=0x9179b4) at ./ zend_execute.c:1559 #16 0x00eebcd8 in execute (op_array=0x916fc4) at ./ zend_execute.c:1559 #17 0x00eebcd8 in execute (op_array=0x6f8e84) at ./ zend_execute.c:1559 #18 0x00eebcd8 in execute (op_array=0xa65880) at ./ zend_execute.c:1559 #19 0x00eebcd8 in execute (op_array=0x69ac94) at ./ zend_execute.c:1559 #20 0x00eebcd8 in execute (op_array=0x9179b4) at ./ zend_execute.c:1559 #21 0x00eebcd8 in execute (op_array=0x916fc4) at ./ zend_execute.c:1559 #22 0x00eebcd8 in execute (op_array=0x6f8e84) at ./ zend_execute.c:1559 #23 0x00eebcd8 in execute (op_array=0xa65880) at ./ zend_execute.c:1559 #24 0x00eebcd8 in execute (op_array=0x69ac94) at ./ zend_execute.c:1559 #25 0x00eebcd8 in execute (op_array=0x9179b4) at ./ zend_execute.c:1559 #26 0x00eebcd8 in execute (op_array=0x916fc4) at ./ zend_execute.c:1559 #27 0x00eebcd8 in execute (op_array=0x6f8e84) at ./ zend_execute.c:1559 #28 0x00eebcd8 in execute (op_array=0xa65880) at ./ zend_execute.c:1559 #29 0x00eebcd8 in execute (op_array=0x69ac94) at ./ zend_execute.c:1559 #30 0x00eebcd8 in execute (op_array=0x9179b4) at ./ zend_execute.c:1559 #31 0x00eebcd8 in execute (op_array=0x916fc4) at ./ zend_execute.c:1559 #32 0x00eebcd8 in execute (op_array=0x6f8e84) at ./ zend_execute.c:1559 #33 0x00eebcd8 in execute (op_array=0xa65880) at ./ zend_execute.c:1559 #34 0x00eebcd8 in execute (op_array=0x69ac94) at ./ zend_execute.c:1559 #35 0x00eebcd8 in execute (op_array=0x9179b4) at ./ zend_execute.c:1559 #36 0x00eebcd8 in execute (op_array=0x916fc4) at ./ zend_execute.c:1559 #37 0x00eebcd8 in execute (op_array=0x6f8e84) at ./ zend_execute.c:1559 #38 0x00eebcd8 in
