Please provide a short and self-contained script which reproduces this crash. A backtrace would also help (but better compile with --enable-debug first).

I can verify this bug.  It is happening with my server (check out http://ged.dynodns.net/band/).  I am using mod_layout in conjunction with apache, but the bug appears exactly as is described above, and it looks to be a PHP problem (other pages seem to load fine - but not this one).

The server executes http://ged.dynodns.net/band/header.phps (source) before executing http://ged.dynodns.net/band/index.phps (source also).  But after executing the header (successfully, or so it seems, but i cannot tell where the problem lies - at the end of header.php or at the beginning of index.php).  However, i was running apache 1.3.22 with mod_layout and PHP 4.1.0 and everything worked just fine, until I had another problem and recompiled everything with PHP 4.1.1, so it appears that this is a PHP 4.1.1 bug.

(Note, that the require()'ed files, web.php and news.php are both files that are only function declaractions, and don't crash scripts like events.php)

Apache Config:
--with-layout=Apache
--prefix=/usr/apache
--activate-module=src/modules/php4/libphp4.a
--enable-module=so
--enable-module=speling
--enable-module=vhost_alias

PHP 4.1.1 Config:
--with-apache=/usr/src/apache-1.3.22 \
--disable-short-tags \
--without-mysql \
--with-pgsql=/usr/pgsql


I hope the source helps - I'm working on building a debugging version so I can obtain a backtrace.  Just confirming for now.

OK, here's the backtrace:

#0  0x4012eb1e in memcpy () from /lib/libc.so.6
#1  0x8146ba0 in ap_bwrite ()
#2  0x8158be2 in ap_send_mmap ()
#3  0x402bbb13 in _init () from /usr/apache/libexec/mod_layout.so
#4  0x8147ccf in ap_invoke_handler ()
#5  0x815becf in process_request_internal ()
#6  0x815c2f3 in ap_internal_redirect ()
#7  0x8073178 in handle_dir ()
#8  0x8147ccf in ap_invoke_handler ()
#9  0x815becf in process_request_internal ()
#10 0x815bf30 in ap_process_request ()
#11 0x8153379 in child_main ()
#12 0x8153524 in make_child ()
#13 0x8153698 in startup_children ()
#14 0x8153d10 in standalone_main ()
#15 0x8154563 in main ()
#16 0x400c7b65 in __libc_start_main (main=0x81541cc <main>, argc=4, ubp_av=0xbffffb1c, init=0x8060dcc <_init>, fini=0x8182100 <_fini>, rtld_fini=0x4000df24 <_dl_fini>, 
    stack_end=0xbffffb14) at ../sysdeps/generic/libc-start.c:111


I can't hardly tell, but I'm guessing its in PHP, as it was called from mod_layout, in which case the problem lies at the end of header.php, I think.

Hrm, but there is no sign of anything PHP in that backtrace.  You are saying PHP sent something that caused mod_layout to crash?  That would indicate a problem in mod_layout as far as I am concerned.

OK, This may actually not be a bug (In my case at least).  Just reinstalled PHP 4.1.0 and it still happened.  Not sure about the first submission, but it may still be a PHP bug but not for my case, at least.  Sorry for all the bother.

2 x Apache 1.3.20 + MySQL 3.23.39 + Linux 2.4.17 (one with grsec patch). Pattern: logs full of messages mentioned in first report. Crash seems to happen on first load of the page in a freshly started browser (there's a session init on the page (two actually, on both same thing)), on reload things work ok.

Session stuff done via mysql.

PHP 4.1.1, loaded with extensions.

See also http://bugs.php.net/bug.php?id=15096

Reopening.

See also http://bugs.php.net/bug.php?id=14529

The original reporter of this bug said it works for him now.
Those other bugs are different issues.