Hi,

This is a patch - no bug report. The bug occures with various PHP
versions (mod_php), i.e. 4.0.5 and 4.0.6 and older ones, various
PHP-4.0.4pl1 (at least I found different tarballs with that equal
version number!). I cannot deliver a small script which
reproduces the seg fault (which is a kill after failed malloc of > 1GB
mem :)). It does not happens always, I guess 0.5% of the accesses
(according to apache's server log), around 10% of accesses to two
special scripts. Only a few scripts crash (on different
locations, i.e on "returns" and others).

I found that the add_string_to_string tries to get memory for a
string with value.str.val == NULL and value.str.len == 1.5GB. To
workaround this, I set len to zero when val == NULL; I know this
is a dirty hack but I cannot understand your code and I have no
time to debug it, sorry.

The patch is against PHP-4.0.5:
----------[ php-4.0.5.dif.take4 ]---------------
diff -Nur ../php-4.0.5.dist/Zend/zend_operators.c
./Zend/zend_operators.c
--- ../php-4.0.5.dist/Zend/zend_operators.c     Mon Feb 26
06:43:27 2001
+++ ./Zend/zend_operators.c     Thu Jul 19 22:04:13 2001
@@ -960,7 +960,21 @@
 /* must support result==op1 */
 ZEND_API int add_string_to_string(zval *result, zval *op1, zval *op2)
 {
-       int length = op1->value.str.len + op2->value.str.len;
        +       /* sdettmer@ingenico.de begin */
+       int length;
+
+       /* null strings haven't a useful length */
+       if (op1->value.str.val == NULL) {
+               op1->value.str.len = 0;
+       }
+
+       if (op2->value.str.val == NULL) {
+               op2->value.str.len = 0;
+       }
+
+       length = op1->value.str.len + op2->value.str.len;
+       /* sdettmer@ingenico.de end */
+
        result->value.str.val = (char *) erealloc(op1->value.str.val, length+1);
     memcpy(result->value.str.val+op1->value.str.len, op2->value.str.val,
+op2->value.str.len);
     result->value.str.val[length] = 0;
----------[ php-4.0.5.dif.take4 end ]---------------

If you want a copy of my source RPM, just drop me a note, I can
mail it to you.

Some infos from our internal bug report system. Please note, the
backtrace may be from a different bug if it's look strange :)

>    segfault when trying to load bugs, func=browse 
>    (clicking on Bug in Sourceforge Project). 
> 
>    backtrace: 
> 
>    (gdb) bt 
>    #0 0x40378c1a in zend_binary_strcmp () from /usr/lib/apache/libphp4.so 
>    #1 0x40378dac in zend_binary_zval_strcmp () from /usr/lib/apache/libphp4.so 
>    #2 0x403790d1 in zendi_smart_strcmp () from /usr/lib/apache/libphp4.so 
>    #3 0x40377e1a in compare_function () from /usr/lib/apache/libphp4.so 
>    #4 0x40378688 in is_not_equal_function () from /usr/lib/apache/libphp4.so 
>    #5 0x40362f8f in execute () from /usr/lib/apache/libphp4.so 
>    #6 0x4036f4b2 in execute () from /usr/lib/apache/libphp4.so 
>    #7 0x4037ae86 in zend_execute_scripts () from /usr/lib/apache/libphp4.so 
>    #8 0x4038db94 in php_execute_script () from /usr/lib/apache/libphp4.so 
>    #9 0x40389de0 in apache_php_module_main () from /usr/lib/apache/libphp4.so 
>    #10 0x4038a841 in send_php () from /usr/lib/apache/libphp4.so 
>    #11 0x4038a883 in send_parsed_php () from /usr/lib/apache/libphp4.so 
>    #12 0x8055160 in ap_invoke_handler () 
>    #13 0x806760c in ap_some_auth_required () 
>    #14 0x806796c in ap_internal_redirect () 
>    #15 0x40a8fdae in _init () from /usr/lib/apache/mod_dir.so 
>    #16 0x8055160 in ap_invoke_handler () 
> 
[cut]
>     the segfault is an explicit kill (getpid, 11) done when
>     realloc fails. realloc shall get 1.5GB :) The PHP stuff uses
>     "Zend Engine" which is some very cryptic and risky
>     code. I see no chance to debug it with useful results.


You may contact me via mail (sdettmer@ingenico.de).

oki,

Steffen