fixed the summary

found two machines that are not affected by this bug:
http://phpzone.de/info/
http://angela.nettrade.de/info.php

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.

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;
 };
 
 

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.

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.

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?

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.

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().

Ok, ZendOptimizer disabled, patch works as expected.
Any patch like the one Joerg suggested in sight?

My personaly preference is "result must be correct always, if not raise error", but it's not the case under PHP, unfortunately.

why not?

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?

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

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.

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.

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.

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

Verified with 4.3.9. Could not verify with 5.0.3. Could anyone test with 4.3.10?

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".