Thom and I already spoke about this bug, and I'm going to
try to reproduce it locally as soon as possible, but
at this point I'm not sure if it's Apache's fault or
something in the apache2filter. I'm leaning toward
a problem in the latter. I'm also going to try to reproduce
this under the prefork MPM, but if someone beats me to
it, please submit your results here.

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 am unable to duplicate the problem using PHP 4.3-dev and Apache 2.0.43. Could you try and see if the problem you've mentioned is still there on your machine, thanks.

I can't reproduce this exact problem.
However, Apache2 now segfaults on restart whenever PHP4 is loaded. (current CVS for both.)
This uses the following apache2 config:

"./configure" \
"--with-mpm=worker" \
"--prefix=/usr/local/apache2-php/" \
"--enable-modules=max" \
"--enable-maintainer-mode" \
"$@"

and the following PHP config.
'./configure' \
'--with-mysql' \
'--with-gd=/usr' \
'--with-curl=/usr' \
'--with-ttf=/usr' \
'--with-png-dir=/usr' \
'--with-jpeg-dir=/usr' \
'--with-openssl=/usr' \
'--with-zlib=/usr' \
'--with-freetype-dir=/usr' \
'--enable-debug' \
'--with-apxs2=/usr/local/apache2-php/bin/apxs' \
"$@"

Does the crash occur if you limit the PHP configure line to:

./configure --with-apxs2=/usr/local/apache2-php/bin/apxs --enable-debug

Yes.
Here's the backtrace:
#0  0x4015e973 in free () from /lib/libc.so.6
#1  0x4015f081 in realloc () from /lib/libc.so.6
#2  0x4015ebe4 in realloc () from /lib/libc.so.6
#3  0x402fcf77 in ts_allocate_id (rsrc_id=0x403c372c, size=88, 
    ctor=0x4030fae0 <php_output_init_globals>, dtor=0)
    at /home/thom/php4/TSRM/TSRM.c:206
#4  0x4030fb69 in php_output_startup () at /home/thom/php4/main/output.c:73
#5  0x40300698 in php_module_startup (sf=0x403b0b00, 
    additional_modules=0x403b0cc0, num_additional_modules=1)
    at /home/thom/php4/main/main.c:1017
#6  0x4034eafe in php_apache2_startup (sapi_module=0x403b0b00)
    at /home/thom/php4/sapi/apache2filter/sapi_apache2.c:267
#7  0x4034f25d in php_apache_server_startup (pconf=0x80b5cb0, plog=0x80edd90, 
    ptemp=0x80b7cb8, s=0x80f4648)
    at /home/thom/php4/sapi/apache2filter/sapi_apache2.c:543
#8  0x0807c371 in ap_run_post_config (pconf=0x80b5cb0, plog=0x80edd90, 
    ptemp=0x80b7cb8, s=0x80f4648) at config.c:130
#9  0x08080afc in main (argc=3, argv=0xbffff914) at main.c:640

(gdb) frame 0
#0  0x4015e973 in free () from /lib/libc.so.6
(gdb) frame 1
#1  0x4015f081 in realloc () from /lib/libc.so.6
(gdb) frame 2
#2  0x4015ebe4 in realloc () from /lib/libc.so.6
(gdb) frame 3
#3  0x402fcf77 in ts_allocate_id (rsrc_id=0x403c372c, size=88, 
    ctor=0x4030fae0 <php_output_init_globals>, dtor=0)
    at /home/thom/php4/TSRM/TSRM.c:206
206                     resource_types_table = (tsrm_resource_type *) realloc(resource_types_table, sizeof(tsrm_resource_type)*id_count);
(gdb) frame 4
#4  0x4030fb69 in php_output_startup () at /home/thom/php4/main/output.c:73
73              ts_allocate_id(&output_globals_id, sizeof(php_output_globals), (ts_allocate_ctor) php_output_init_globals, NULL);

Is this a dup of 19639 or are they different?

It doesn't appear to be a dup of 19639; the backtrace is pretty different to my untrained eye.

(This still occurs with HEAD now, with an identical backtrace)

correct version.

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. 

Thank you for your interest in PHP.

GD & freetype libraries are not thread-safe, which means they'll cause problems in the worker mpm. Use the prefork mpm if you want to use GD inside your PHP.

How else do you explain the fact that all current versions of apache2 segfault reproducibly with no options to php barring --enable-debug and --with-apxs2?
And the *exact* same install functions *perfectly* when php is not loaded.
I've been told this is producible with prefork, too. 
*Please* reread the back traces i've put on this bug. I'm happy to help in anyway, just don't close valid bugs as bogus.

If you are compiling Apache 2.0 with worker model you should've used the --enable-experimental-zts, which enables threading support in PHP, you didn't do that.
Did you personally see it crash with prefork? I did not and I am running Apache 2.0.43 (prefork) with PHP 4.3.0-dev and surprisingly it served some 10,000 requests to PHP script doing GD image manipulations without a single crash.

That?s pure luck as GD is not threadsafe.

4.3.0 RC2 configured with:
'./configure' '--enable-experimental-zts' '--with-apxs2=/usr/local/apache2-php/bin/apxs' '--enable-debug'

the phpinfo() function generates the page that is dumped to:
http://samizdat.positive-internet.com/~thom/phpinfo.html

the sequence is:
in ServerRoot:
bin/apachectl start
make connection to verify the server is running, resulting in the above page.
bin/apachectl restart
apache dies at this point.

this is the error log:
[Tue Dec 10 21:40:23 2002] [notice] Apache/2.0.44-dev (Unix) PHP/4.3.0RC2 configured -- resuming normal operations
[Tue Dec 10 21:41:51 2002] [notice] SIGHUP received.  Attempting to restart
[Tue Dec 10 21:41:54 2002] [notice] seg fault or similar nasty error detected in the parent process

(gdb) where
#0  0x4031e2d9 in php_output_activate (tsrm_ls=0x813c0c0)
    at /home/thom/php-4.3.0RC2/main/output.c:85
#1  0x4030e86a in php_module_startup (sf=0x4039c460, 
    additional_modules=0x4039c640, num_additional_modules=1)
    at /home/thom/php-4.3.0RC2/main/main.c:1021
#2  0x4035d65e in php_apache2_startup (sapi_module=0x4039c460)
    at /home/thom/php-4.3.0RC2/sapi/apache2filter/sapi_apache2.c:269
#3  0x4035dded in php_apache_server_startup (pconf=0x80b60c8, plog=0x80ee1a8, 
    ptemp=0x80b80d0, s=0x80f4a60)
    at /home/thom/php-4.3.0RC2/sapi/apache2filter/sapi_apache2.c:551
#4  0x0807c381 in ap_run_post_config (pconf=0x80b60c8, plog=0x80ee1a8, 
    ptemp=0x80b80d0, s=0x80f4a60) at config.c:130
#5  0x08080bbc in main (argc=3, argv=0xbffffd54) at main.c:640

(gdb) frame 0
#0  0x4031e2d9 in php_output_activate (tsrm_ls=0x813c0c0)
    at /home/thom/php-4.3.0RC2/main/output.c:85
85              OG(php_body_write) = php_ub_body_write;
(gdb) frame 1
#1  0x4030e86a in php_module_startup (sf=0x4039c460, 
    additional_modules=0x4039c640, num_additional_modules=1)
    at /home/thom/php-4.3.0RC2/main/main.c:1021
1021            php_output_activate(TSRMLS_C);
(gdb) frame 2
#2  0x4035d65e in php_apache2_startup (sapi_module=0x4039c460)
    at /home/thom/php-4.3.0RC2/sapi/apache2filter/sapi_apache2.c:269
269             if (php_module_startup(sapi_module, &php_apache_module, 1)==FAILURE) {
(gdb) frame 3
#3  0x4035dded in php_apache_server_startup (pconf=0x80b60c8, plog=0x80ee1a8, 
    ptemp=0x80b80d0, s=0x80f4a60)
    at /home/thom/php-4.3.0RC2/sapi/apache2filter/sapi_apache2.c:551
551             apache2_sapi_module.startup(&apache2_sapi_module);

Still occurs in 4.3.0

I am also experiencing this bug.  It is annoying because it causes apache to silently die every night when the logrotate script runs (installed from the "apache2-common 2.0.43-1" debian package)

install details:
Apache/2.0.43 (Debian GNU/Linux)
PHP/4.3.0RC4
php configure: ./configure  --with-mysql=/usr --with-imap --with-imap-ssl --with-apxs2=/usr/bin/apxs2 --with-gettext --with-xml
running mpm-prefork

error log:

[Fri Jan 10 11:59:41 2003] [notice] seg fault or similar nasty error detected in the parent proces

"apache2ctl restart" doesn't crash when php module isn't loaded

If I can help, let me know!

FWIW, I can reproduce this every time on MPM-prefork Apache 2.0.43 and PHP 4.3.0.  No threads involved.  This occurs after an 'apache2ctl graceful' with gdb attached to the parent process (gdb stops on the SIGUSR1, is continued, segv ensues).  The server was started with StartServers=1 and MinSpareServers=1, then the restart immediately attempted, though it happens regardless of these.

This is linux 2.4.19 (Debian Woody/Sid hybrid), glibc 2.3.

Program received signal SIGSEGV, Segmentation fault.
0x40585181 in sapi_initialize_empty_request (tsrm_ls=0x8108740)
    at /usr/src/apache/php/php-4.3.0/main/SAPI.c:399
399		SG(server_context) = NULL;
(gdb) bt
#0  0x40585181 in sapi_initialize_empty_request (tsrm_ls=0x8108740)
    at /usr/src/apache/php/php-4.3.0/main/SAPI.c:399
#1  0x4057f8ec in php_module_startup (sf=0x40605360, 
    additional_modules=0x40605540, num_additional_modules=1)
    at /usr/src/apache/php/php-4.3.0/main/main.c:1035
#2  0x405c820e in php_apache2_startup (sapi_module=0x40605360)
    at /usr/src/apache/php/php-4.3.0/sapi/apache2filter/sapi_apache2.c:269
#3  0x405c89cd in php_apache_server_startup (pconf=0x80c3c30, plog=0x80fbd10, 
    ptemp=0x8101d28, s=0x80c6298)
    at /usr/src/apache/php/php-4.3.0/sapi/apache2filter/sapi_apache2.c:556
#4  0x0807fe59 in ap_run_post_config ()
#5  0x08085e11 in main ()
#6  0x402409f1 in __libc_start_main () from /lib/libc.so.6

Reproducible also under Apache 2.0.44 with mpm-prefork; same conditions, same trace.

Reproducible on Linux 2.4.18 (Debian Woody) with Apache 2.0.44 and the latest CVS snapshot of PHP.

My workaround: comment extension= directives in php.ini

I'v got same errors after upgrading php (seg fault after SIGHUP)

Redhat 8.0 / httpd-2.0.40-20 / php-4.2.2-16

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

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.

Nope, that makes precisely zero difference. Reviewing the commits on apache2filter recently I'm not quite sure which commit you expected to fix this?
Reproducible with 2.1-dev and 2.0-dev (what will be 2.0.46).
Same old backtrace:
(gdb) bt
#0  0x403a678d in sapi_initialize_empty_request (tsrm_ls=0x80f98f0)
    at /home/thom/php4-STABLE-200305190930/main/SAPI.c:434
#1  0x403a1000 in php_module_startup (sf=0x4041cf00, 
    additional_modules=0x4041d0e0, num_additional_modules=1)
    at /home/thom/php4-STABLE-200305190930/main/main.c:1094
#2  0x403defbb in php_apache2_startup (sapi_module=0x4041cf00)
    at /home/thom/php4-STABLE-200305190930/sapi/apache2filter/sapi_apache2.c:287
#3  0x403df797 in php_apache_server_startup (pconf=0x80b90c8, plog=0x80f11a8, 
    ptemp=0x80bb0d0, s=0x4041cf00)
    at /home/thom/php4-STABLE-200305190930/sapi/apache2filter/sapi_apache2.c:577
#4  0x0807e651 in ap_run_post_config (pconf=0x80b90c8, plog=0x80f11a8, 
    ptemp=0x80bb0d0, s=0x80f5af0) at config.c:130
#5  0x08082e9c in main (argc=3, argv=0xbffff864) at main.c:640
(gdb) frame 0
#0  0x403a678d in sapi_initialize_empty_request (tsrm_ls=0x80f98f0)
    at /home/thom/php4-STABLE-200305190930/main/SAPI.c:434
434             SG(server_context) = NULL;

it still looks like a pool lifetime problem

HOW did you configure the latest snapshot??
The default Apache2 module IS NOT apache2filter.
(when using --with-apxs2 option)

from config.nice:

'./configure' \
'--with-apxs2filter=/usr/local/apache2-worker/bin/apxs' \
"$@"

I'm well aware that apache2filter is not the default, this doesn't mean it shouldn't be fixed.

Does this happen with apache2handler then??
That's what I'm interested to know, as it's been reported
to work much better..

Only difference in the backtrace when trying with apache2handler is the different SAPI directory:
#0  0x403a6941 in sapi_initialize_empty_request (tsrm_ls=0x80f98f0)
    at /home/thom/php4-STABLE-200305190930/main/SAPI.c:434
434             SG(server_context) = NULL;
(gdb) bt
#0  0x403a6941 in sapi_initialize_empty_request (tsrm_ls=0x80f98f0)
    at /home/thom/php4-STABLE-200305190930/main/SAPI.c:434
#1  0x403a11b4 in php_module_startup (sf=0x4041cba0, 
    additional_modules=0x4041ce80, num_additional_modules=1)
    at /home/thom/php4-STABLE-200305190930/main/main.c:1094
#2  0x403df187 in php_apache2_startup (sapi_module=0x4041cba0)
    at /home/thom/php4-STABLE-200305190930/sapi/apache2handler/sapi_apache2.c:290
#3  0x403df2b3 in php_apache_server_startup (pconf=0x80b90c8, plog=0x80f11a8, 
    ptemp=0x80bb0d0, s=0x4041cba0)
    at /home/thom/php4-STABLE-200305190930/sapi/apache2handler/sapi_apache2.c:389
#4  0x0807e651 in ap_run_post_config (pconf=0x80b90c8, plog=0x80f11a8, 
    ptemp=0x80bb0d0, s=0x80f5af0) at config.c:130
#5  0x08082e9c in main (argc=3, argv=0xbffff874) at main.c:640
(gdb)

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

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.

This bug is still present...

Program received signal SIGSEGV, Segmentation fault.
0x405e8dc9 in sapi_initialize_empty_request (tsrm_ls=0x20) at /usr/src/php4-STABLE-200307151130/main/SAPI.c:424
424             SG(server_context) = NULL;
(gdb) where
#0  0x405e8dc9 in sapi_initialize_empty_request (tsrm_ls=0x20) at /usr/src/php4-STABLE-200307151130/main/SAPI.c:424
#1  0x405e3009 in php_module_startup (sf=0x40689b00, additional_modules=0x40689de0, num_additional_modules=1) at /usr/src/php4-STABLE-200307151130/main/main.c:1093
#2  0x406281b7 in php_apache2_startup (sapi_module=0x40689b00) at /usr/src/php4-STABLE-200307151130/sapi/apache2handler/sapi_apache2.c:297
#3  0x406282e3 in php_apache_server_startup (pconf=0x80aa9d0, plog=0x80e2ab0, ptemp=0x80e6ac0, s=0x40689b00) at /usr/src/php4-STABLE-200307151130/sapi/apache2handler/sapi_apache2.c:396
#4  0x08073618 in ap_run_post_config ()
#5  0x08077afa in main ()
#6  0x4035ea51 in __libc_start_main () from /lib/libc.so.6
#7  0x080603ad in _start ()

Seems to be actually a bug in glibc. I've made a patch that should workaround this problem. See: http://marc.theaimsgroup.com/?l=php-dev&m=105878953712765&w=2

Maybe someone could verify that this works.

Applying the patch seems to fix the problem for me.

I'm using Apache 2.0.47 (prefork), PHP 4.3.2 (compiled with imap, gettext), glibc 2.2.5 on Debian 3.0.

Thanks!

This bug has been fixed in CVS.

In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.