On Mon, Jan 21, 2002 at 01:23:42PM +0100, Sebastian Bergmann wrote: > Here's a backtrace: > > ap_save_brigade(ap_filter_t * 0x10d57628, apr_bucket_brigade * * > 0x10d56004, apr_bucket_brigade * * 0x10a6fe74, apr_pool_t * 0x10d55b30) > line 418 + 49 bytes > php_output_filter(ap_filter_t * 0x10d57628, apr_bucket_brigade * > 0x10d57790) line 350 + 32 bytes > ap_pass_brigade(ap_filter_t * 0x10d57628, apr_bucket_brigade * 0x10d57790) > line 390 + 16 bytes > default_handler(request_rec * 0x10d55b68) line 2974 > ap_run_handler(request_rec * 0x10d55b68) line 186 + 78 bytes > ap_invoke_handler(request_rec * 0x10d55b68) line 359 + 9 bytes > ap_process_request(request_rec * 0x10d55b68) line 291 + 9 bytes > ap_process_http_connection(conn_rec * 0x10cdc140) line 280 + 9 bytes > ap_run_process_connection(conn_rec * 0x10cdc140) line 84 + 78 bytes > ap_process_connection(conn_rec * 0x10cdc140) line 232 > worker_main(int 248) line 934 > _threadstartex(void * 0x005f4688) line 212 + 13 bytes > > Latest CVS of both Apache2 and PHP 4.
FWIW, I see segfaults in PHP4 all of the time in Unix when it calls ap_save_brigade. I even filed a PHP bug report a month ago today. =) http://bugs.php.net/bug.php?id=14637 I think it is related to inproper use of ap_save_brigade, but I'm not familiar enough with PHP to determine more. I bet it is a boundary condition that it isn't handling. It *could* be something we're doing wrong in ap_save_brigade, but I didn't see that from my cursory examination. The context looks like it has been corrupted. -- justin
