I should say that by disabling, I meant that I commented out the line

  ob_start ('ob_gzhandler');

in our auto-prepend file.

Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.

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

Unfortunately, this occurs statistically on a production server. To do a backtrace would require a debug version and to use CVS would be to use 4.3. Neither will work with the Zend Accelerator or Performance Suite. The site is inoperable without one of them. Maybe I can try a beta of one of those software packages to use with the current CVS. I'll ask. If I can not then I'll report the results after everything is released.

One other note that may be of interest to people search the bug the list. This bug has the net result of pushing the load average up to 150 from 6 in a series of spikes (more dense as traffic increases).

One thing I forgot to add: I tried backporting all the fixes from CVS that referenced crashes/segfaults from zlib.c, output.c, and streams.c with no improvement.

In the middle of the night, I'm going to temporarily install 4.3RC1 which will disable the accelerator and kick the load average to the roof, but hopefully I'll be able to check the error log for segfaults.

We recommend using zlib.outputcompression instead of ob_gzhandler; maybe this will solve your issues, without
the need to upgrade PHP.

The problem with setting it system wide is that it will try to compress images and javascripts. No browser likes compressed images and Netscape dies on compressed javascripts.

Or are you suggesting that I use:
  ini_set ( "zlib.output_compression", 1);
instead of:
  ob_start ('ob_gzhandler');
??

Does this work in PHP 4.2.3?

Using
  ini_set ( "zlib.output_compression", 1);// or "On" or 4096 ...
instead of:
  ob_start ('ob_gzhandler');

does not actually compress pages...

zlib.output_compression is PHP_INI_SYSTEM|PHP_INI_PERDIR so it can't be set in a script according to the manual (ini_set). Is this correct? Does this change in 4.3?

In 4.3 zlib.output_compression will be PHP_INI_ALL and you can change the value if the headers are not sent.

Also images won't be compressed automatically.

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

I tried with 4.3RC2. Bug still exists, crashing at least 13 times in the couple of minutes the server was able to run with Zend accelerator...

I HATE this bug. Grr. I case I can take the time to do a walkthrough since it still exists...

Does the crash still occur when you disable Zend Accelerator?

Derick

Yes, the problem occurs without the Zend addon. Zend Accelerator won't work with PHP 4.3 anyhow, so I turned it off. In the other message I proved myself to be a bad typist. :( I meant to say _without_ Zend Accelerator...

status -> open, updated version.

(please, don't use 'Add Comment' when you edit your own submission..use 'Edit Submission')

OK, I was able to have gbb attach to one of the 500 children and wait for a segault. This is version 4.2.3, as this is from our production site (late at night I'll try and do the same for a full debug version of 4.3RC2):

Program received signal SIGSEGV, Segmentation fault.
0x080a9b2c in sapi_apache_header_handler ()
(gdb) bt
#0  0x080a9b2c in sapi_apache_header_handler ()
#1  0x080af403 in sapi_add_header_ex ()
#2  0x080b5700 in zif_ob_gzhandler ()
#3  0x08124392 in call_user_function_ex ()
#4  0x080b20f9 in php_end_ob_buffer ()
#5  0x080b23bb in php_end_ob_buffers ()
#6  0x080ac0a7 in php_request_shutdown ()
#7  0x081530d8 in run_cleanups ()
#8  0x08151ec8 in ap_clear_pool ()
#9  0x08151f28 in ap_destroy_pool ()
#10 0x08151e9b in ap_clear_pool ()
#11 0x0815e92b in child_main ()
#12 0x0815ef0b in make_child ()
#13 0x0815f1e9 in perform_idle_server_maintenance ()
#14 0x0815f69a in standalone_main ()
#15 0x0815fc2c in main ()

Finally.

In file:
sapi/apache/mod_php4.c

The crash is in sapi_apache_header_handler(). This line is apparently not guaranteed:

    request_rec *r = (request_rec *) SG(server_context);

As r is dereferenced and not valid some small percent of the time. It may be indicative of some other error. Further investigation as to why needs to be done.

I added a few other checks while tracking this bug down. Here is the function as I have it now. No more segfaults in the error_log. The line to note is the check for !r. Also, I don't think it hurts to check for null in other places (!sapi_header || !sapi_header->header).



/* {{{ sapi_apache_header_handler
 */
int sapi_apache_header_handler(sapi_header_struct *sapi_header, sapi_headers_struct *sapi_headers TSRMLS_DC)
{
        char *header_name, *header_content, *p;
        request_rec *r = (request_rec *) SG(server_context);

        if (!sapi_header) {
                return 0;
        }

        if (!sapi_header->header) {
                return 0;
        }

        header_name = sapi_header->header;

        header_content = strchr(header_name, ':');
        if (!header_content || !r) {
                efree(sapi_header->header);
                return 0;
        }

        header_name = estrndup(header_name,header_content-header_name);
        if (!header_name){
                return 0;
        }

        do {
                header_content++;
        } while (*header_content==' ');


        if (!strcasecmp(header_name, "Content-Type")) {
                r->content_type = pstrdup(r->pool, header_content);
        } else if (!strcasecmp(header_name, "Set-Cookie")) {
                table_add(r->headers_out, header_name, header_content);
        } else if (sapi_header->replace) {
                table_set(r->headers_out, header_name, header_content);
        } else {
                table_add(r->headers_out, header_name, header_content);
        efree(header_name);
        efree(sapi_header->header);

        return 0;  /* don't use the default SAPI mechanism, Apache duplicates this functionality */
}
/* }}} */

Reclassifying since it is the Apache module code where the actual segfaults occur. 

Short version: SG(server_context) is not checked for null before dereferencing it in sapi_apache_header_handler() while it is checked in other functions.

I now have verified that the bug remains into the release version of 4.3.0. I'll check the php4-STABLE-latest.tar.gz version this weekend.

(Note that with this patch upgrading to v4.3 I no longer see segfaults in the Apache log!! Sweet!)

Please try using this CVS snapshot:

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

There was a fix for a possible crash in sapi_apache_header_handler() so please try the latest  snapshot.

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.