php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #25394 Segfault and Crash on long scripts.
Submitted: 2003-09-06 03:50 UTC Modified: 2003-09-07 11:28 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:0 (0.0%)
Same OS:0 (0.0%)
From: mark dot meredith at shaw dot ca Assigned:
Status: Not a bug Package: Reproducible crash
PHP Version: 4CVS-2003-09-06 (stable) OS: MAC OS 10.2.6
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: mark dot meredith at shaw dot ca
New email:
PHP Version: OS:

 

 [2003-09-06 03:50 UTC] mark dot meredith at shaw dot ca
Description:
------------
I have tested this with the 4.3.2 and 
4.3.3 official releases as well. I have not tried any 
earlier releases. I have tried with the command line or 
as an Apache 1 or Apache 2 module all with the same result.

I used no extensions or modules for the builds in all 
cases.

Apparently the bug does not occur for Windows XP Pro and 
likely 
some other operating systems. I was told this by some users 
of a PHP forum who tried their own test scripts.

The result of memory_get_usage() placed on a script one 
line shorter than the crash length returned around 1MB.

Thank you.

Reproduce code:
---------------
<?php

/*presumably any long script that consumes enough memory will cause the problem*/

/*this assignment done about 10000 times*/
$x = 1;

?>

Expected result:
----------------
Nothing but a clean run through.

Actual result:
--------------
The backtrace from the STABLE snapshot cli was...

(gdb) bt
#0  0x00183b9c in execute (op_array=0x4e7c58) at /Users/
markmere/Sources/php4-snapshot/Zend/zend_execute.c:1027
#1  0x0016e334 in zend_execute_scripts (type=8, retval=0x0, 
file_count=3) at /Users/markmere/Sources/php4-snapshot/
Zend/zend.c:885
#2  0x001208e0 in php_execute_script 
(primary_file=0xbffff7c0) at /Users/markmere/Sources/php4-
snapshot/main/main.c:1723
#3  0x0018ea84 in main (argc=2, argv=0xbffffd24) at /Users/
markmere/Sources/php4-snapshot/sapi/cli/php_cli.c:819
#4  0x00002564 in _start (argc=2, argv=0xbffffd24, 
envp=0xbffffd30) at /SourceCache/Csu/Csu-45/crt.c:267
#5  0x000023e4 in start ()

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-09-06 19:14 UTC] sniper@php.net
Can not reproduce with a script that has $x=1 about 500'000 times. Only thing I get is: 

Allowed memory size of 8388608 bytes exhausted at /usr/src/web/php/php4_3/Zend/zend_opcode.c:48 (tried to allocate 11796480 bytes)

I suggest you use '--enable-memory-limit' configure option and set the 'memory_limit' directive in php.ini to a reasonable amount. This will prevent any stupid scripts like this from crashing.


 [2003-09-07 01:29 UTC] mark dot meredith at shaw dot ca
Are you sure you were running this on a Apple Mac OS X box? 
I have tried the memory_limit directive and corresponding 
configure option. Even when set to allow 64MB the script 
still crashes at exactly the same length. I also used no 
memory directive and a memory limit of -1. Everything 
produces the same result at the same point in the script. 
After the report was labeled "Bogus" I got my hands on a 
brand new iBook. Same thing. I have also tried the 
www.serverlogistics.com and www.entropy.ch builds with the 
same crash at the same line.

Thanks again for your time and efforts. I hope this is 
squashable.
 [2003-09-07 11:28 UTC] sniper@php.net
[xserver:~/jani/php4] admin% uname -v
Darwin Kernel Version 6.6: Thu May  1 21:48:54 PDT 2003

[xserver:~/jani/php4] admin% sapi/cli/php ../t.php
Allowed memory size of 8388608 bytes exhausted (tried to allocate 14155776 bytes)


 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Apr 25 00:01:41 2024 UTC