php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #16360 Segmentation fault in Array functions
Submitted: 2002-03-30 10:02 UTC Modified: 2004-12-24 01:00 UTC
Votes:24
Avg. Score:4.9 ± 0.4
Reproduced:22 of 22 (100.0%)
Same Version:5 (22.7%)
Same OS:12 (54.5%)
From: nohn@php.net Assigned:
Status: No Feedback Package: Scripting Engine problem
PHP Version: 4.0CVS-2002-07-09 OS: Linux, Windows, Tru64
Private report: No CVE-ID: None
 [2002-03-30 10:02 UTC] nohn@php.net
If the memory limit of a PHP-script gets exhausted, the PHP interpreter does'nt shut down cleanly and print an error regarding this issue; it segfaults. If the user enables following options in php.ini ([PHP]-section),
---
log_errors = On
error_log = syslog
---
PHP first shows an memory-limit error, after that Apache/PHP dies with an segmentation fault. If "error_log" is set to "/some/file", PHP is unable to log anything. The only logging facility that logs the segmentation fault is syslog.

Demonstration:
<?php
  $theline = "hello, i'm the line";
  for ($i = 0; $i < 1000000; $i++) $testarr[$i] = $theline;
?>

Following script does'nt cause a segmentation fault:
<?php
  for ($i = 0; $i < 1000000; $i++) $testarr[$i] = "hello, i'm the line";
?>

So far we could test following Versions:
PHP      Webserver     OS              console (sf/ml)  apachemod (sf/ml)
4.0.1    -             Linux ?                   X/-                -/-
4.0.2    Apache 1.3.?  Linux ?                   ?/?                ?/?
4.0.6    Apache 1.3.19 Linux 2.2.19              X/X                X/X
4.0.6    Apache 1.3.22 Linux 2.4.18              X/X                X/X
4.1.2    Apache 1.3.22 Linux ?                   X/X                X/X
4.1.2    -             Linux 2.4.17              X/X                -/-
4.1.2    Apache 1.2.24 Windows 2000              X/-                X/-
4.2.0rc1 Apache 1.3.24 Linux 2.4.18              -/X                X/X

* sf = Segmentation fault
* ml = Memory limit error

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-03-30 10:24 UTC] nohn@php.net
fixed the summary
 [2002-03-30 10:36 UTC] nohn@php.net
found two machines that are not affected by this bug:
http://phpzone.de/info/
http://angela.nettrade.de/info.php
 [2002-03-31 03:26 UTC] max at home-werner dot de
I did the same test on my machine (Linux 2.4.18, PHP 4.1.2 CGI-Version).
My php.ini looks like this:

memory_limit = 8M
log_errors = On
error_log = syslog

When I run the test routine nothing appears in my syslog and I get the segfault.
 [2002-03-31 05:06 UTC] yohgaki@php.net
This should be refcount issue.
Change _zval_struct's refcount data type from unsingned short to unsinged int, then PHP should be fine upto 4G.
Without patch refcount can be upto 64K and no error check 
is done -> segfualts.

ZE2 is changed to use unsinged int already. IIRC.

Index: Zend/zend.h
===================================================================
RCS file: /repository/Zend/zend.h,v
retrieving revision 1.152
diff -u -r1.152 zend.h
--- Zend/zend.h 15 Mar 2002 04:33:05 -0000      1.152
+++ Zend/zend.h 31 Mar 2002 10:03:41 -0000
@@ -209,9 +209,9 @@
 struct _zval_struct {
        /* Variable information */
        zvalue_value value;             /* value */
+       zend_uint refcount;
        zend_uchar type;        /* active type */
        zend_uchar is_ref;
-       zend_ushort refcount;
 };
 
 

 [2002-03-31 12:21 UTC] joerg at infolinux dot de
Increasing the refcount width from short to long doesn't 
solve the issue. A strict upper limit test is badly needed 
to check whether the refcounter can be increased in the 
given limit or not.

I suggest to throw a memory exhausted error with a hint 
that no more reference counters could be allocated.
 [2002-03-31 12:42 UTC] wolfram at schlich dot org
After applying the patch above, my Apache segfaults on scripts which ran fine before or just prints "Unsupported operand types in Unknown on line 0". Using PHP 4.2.0RC1.
 [2002-03-31 20:56 UTC] yohgaki@php.net
wolfram,
Could you locate which line is causing following error?
"Unsupported operand types in Unknown on line 0"
I don't get this error message with my applicatins.

Are you using any cache products?



 [2002-03-31 21:44 UTC] wolfram at schlich dot org
Please give me a hint how to locate the line, for I don't know :-)
I'm using the Zend Optimizer in addition, nothing else.
 [2002-04-01 01:32 UTC] yohgaki@php.net
When you report error. Disable Zend Optimizer _ALWAYS_. We don't support ZendOptimizer and it's waste of time for both of us. Zend optimizer probably does not work with the patch.

To locate line, use die().
 [2002-04-01 09:00 UTC] wolfram at schlich dot org
Ok, ZendOptimizer disabled, patch works as expected.
Any patch like the one Joerg suggested in sight?
 [2002-04-01 21:58 UTC] yohgaki@php.net
My personaly preference is "result must be correct always, if not raise error", but it's not the case under PHP, unfortunately.
 [2002-04-02 10:24 UTC] wolfram at schlich dot org
why not?
 [2002-04-03 20:48 UTC] chris at dvdplaza dot com dot au
I'm not sure if this is the same problem, but I get something extremely similar.

Install PHP 4.1.x (whether .1 or .2) and suddenly Apache begins growing, and growing, and GROWING in memory use.  Eventually a malloc/segfault occurs and Apache either restarts or simply fails outright.

Reverting to 4.0.6 resolves the issue, placing 4.1.x back on reintroduces it.  No Zend, no nothing other than GZIP and MySQL.

Since numerous malloc/segfaults end up leaving Apache unable to restart itself, and PHP 4.1.2 was a security fix and thus HAD to upgrade to it (previously just stuck with 4.0.6 due to this), I have had to configure Apache to auto-restart itself every few hundred hits - this seems to prevent the fault occurring.

Mind you PHP still fills up the error log with sh#tloads of parse errors - out of say several hundred executions of a simple 1 line script for example it'll suddenly decide on the next excution to suffer a parse error.  Again specific to PHP 4.1.x

Sorry if this isn't the same fault?
 [2002-07-09 05:42 UTC] nohn@php.net
This happens on Tru64 with current CSV-Snapshot php4-200207090000

> php-test/bin/php theline.php 
Unaligned access pid=10795 <php> va=0x140062b7c pc=0x1201ab460 ra=0x1201ab454 inst=0xb4010000

FATAL:  emalloc():  Unable to allocate 71 bytes
 [2002-08-28 19:56 UTC] iliaa@php.net
Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip

The problem no longer seems to happen with the latest CVS on Linux & Windows.
 [2002-09-23 07:28 UTC] sniper@php.net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.


 [2002-12-08 09:25 UTC] hawk at yooo dot cc
After upgrading from PHP 4.0.6 to 4.2.3 (stable) I experience the same problem - using the demonstration script 1 Apache/PHP dies with Segmentation fault (11).

Using demonstration script 2 I only get an error indicating that the memory limit (8MB) has been exhausted.
 [2004-12-16 17:29 UTC] marius dot lessiak at oewa dot at
same problem here.
demonstration script 1 just throws a seg fault.
demonstration script 2 works (memory settings:200M)
php version is 4.3.4 running on apache2
 [2004-12-16 19:14 UTC] nohn@php.net
Verified with 4.3.9. Could not verify with 5.0.3. Could anyone test with 4.3.10?
 [2004-12-24 01:00 UTC] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Wed Dec 04 07:01:31 2024 UTC