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

The backtrace shows it happens somewhere in pcre functions.
Please try the snapshot, the bundled pcre lib was just updated to the most recent one.

Thanks for the quick response.  I tried your suggestion, but the CVS snapshot doesn't work at all on the machine.  I even tried a simple <?phpinfo()?> test file, but that failed to load.  If I go back to 4.2.3 everything works fine.  Any ideas about why it completely failed to load even a simple PHP file?  I used the exact same configure line that I used for 4.2.3.  Is there anything you suggest I change?  Or any other error logs that I should check?

Exactly WHAT doesn't work with the snapshot?
Did you restart apache after updating PHP? 
In apache error_log you should propably see something about it.. 

Sorry if I wasn't specific enough.  Here is what I did

* configure the snapshot with the following options

./configure --with-apxs=/usr/local/apache/bin/apxs --enable-track-vars --with-openssl=/usr/local/ssl --with-zlib --with-bz2 --with-pspell --with-db3=/usr/lib --enable-ftp --with-gd --with-imap=/usr/local/imap-2001a --with-imap-ssl=/usr/local/ssl --with-ldap --with-jpeg-dir=/usr/lib --with-xpm-dir=/usr/lib --with-png-dir=/usr/lib --with-freetype-dir=/usr/lib --enable-sigchild --with-gettext --with-mcrypt --with-xml --with-mysql=/usr/local/mysql --enable-cli --with-dom --with-dom-xslt --with-dom-exslt --with-mhash --with-mm --enable-debug

  
* shutdown the web server
* run "make install"
* start up the web server
* restart the web server again for good measure
* request a PHP file with <?phpinfo()?> in it

Basically what happens is that the browser hangs while trying to load the <?phpinfo()?> file.  It sits there trying  to load the file, and nothing happens.  Nothing gets printed to the error_log except the following:  

[Thu Sep 19 09:27:41 2002] [notice] Apache/1.3.26 (Unix) PHP/4.3.0-dev mod_ssl/2.8.10 OpenSSL/0.9.6g configured -- resuming normal operations
[Thu Sep 19 09:27:41 2002] [notice] Accept mutex: sysvsem (Default: sysvsem)

So after a minute, I shutdown the web server and now lots of stuff starts spitting out to the error_log

/usr/local/software/php4-200209181500/main/spprintf.c(143) :  Freeing 0x081804D4 (257 bytes), script=/usr/local/apache/htdocs/web/test.php
Last leak repeated 2 times
/usr/local/software/php4-200209181500/main/output.c(415) :  Freeing 0x081802AC (23 bytes), script=/usr/local/apache/htdocs/web/test.php
/usr/local/software/php4-200209181500/main/output.c(409) :  Freeing 0x0817EA74 (6145 bytes), script=/usr/local/apache/htdocs/web/test.php
Last leak repeated 1 time
/usr/local/software/php4-200209181500/Zend/zend_stack.c(27) :  Freeing 0x0817E6F4 (256 bytes), script=/usr/local/apache/htdocs/web/test.php
Last leak repeated 7 times
/usr/local/software/php4-200209181500/Zend/zend_opcode.c(295) :  Freeing 0x08182B44 (120 bytes), script=/usr/local/apache/htdocs/web/test.php
Zend/zend_language_scanner.c(4433) :  Freeing 0x08183A74 (8 bytes), script=/usr/local/apache/htdocs/web/test.php
/usr/local/software/php4-200209181500/Zend/zend_opcode.c(65) :  Freeing 0x08182B0C (4 bytes), script=/usr/local/apache/htdocs/web/test.php
/usr/local/software/php4-200209181500/Zend/zend_hash.c(262) :  Freeing 0x08182A7C (89 bytes), script=/usr/local/apache/htdocs/web/test.php
Last leak repeated 66 times
/usr/local/software/php4-200209181500/Zend/zend_compile.c(136) :  Freeing 0x0817E9BC (54 bytes), script=/usr/local/apache/htdocs/web/test.php
/usr/local/software/php4-200209181500/Zend/zend_execute.c(1597) :  Freeing 0x0817E864 (12 bytes), script=/usr/local/apache/htdocs/web/test.phpZend/zend_language_scanner.c(3054) :  Freeing 0x0817E604 (84 bytes), script=/usr/local/apache/htdocs/web/test.php
/usr/local/software/php4-200209181500/main/output.c(336) :  Freeing 0x0817E53C (1 bytes), script=/usr/local/apache/htdocs/web/test.php
/usr/local/software/php4-200209181500/main/output.c(340) :  Freeing 0x0817E4F4 (24 bytes), script=/usr/local/apache/htdocs/web/test.php
/usr/local/software/php4-200209181500/ext/mbstring/mbstring.c(773) :  Freeing 0x0817E474 (20 bytes), script=/usr/local/apache/htdocs/web/test.php
/usr/local/software/php4-200209181500/Zend/zend_hash.c(178) :  Freeing 0x0817E424 (32 bytes), script=/usr/local/apache/htdocs/web/test.php
Last leak repeated 10 times
/usr/local/software/php4-200209181500/main/main.c(1345) :  Freeing 0x0817E2C4 (44 bytes), script=/usr/local/apache/htdocs/web/test.php
/usr/local/software/php4-200209181500/Zend/zend_API.c(565) : Actual location (location was relayed)
/usr/local/software/php4-200209181500/main/main.c(1344) :  Freeing 0x0817E284 (12 bytes), script=/usr/local/apache/htdocs/web/test.php
/usr/local/software/php4-200209181500/main/main.c(1327) :  Freeing 0x0817DD34 (44 bytes), script=/usr/local/apache/htdocs/web/test.php
/usr/local/software/php4-200209181500/Zend/zend_API.c(565) : Actual location (location was relayed)
/usr/local/software/php4-200209181500/main/main.c(1326) :  Freeing 0x0817DCF4 (12 bytes), script=/usr/local/apache/htdocs/web/test.php
/usr/local/software/php4-200209181500/main/main.c(1429) :  Freeing 0x0817DC04 (12 bytes), script=/usr/local/apache/htdocs/web/test.php
/usr/local/software/php4-200209181500/main/main.c(1382) :  Freeing 0x0817DB54 (44 bytes), script=/usr/local/apache/htdocs/web/test.php
/usr/local/software/php4-200209181500/Zend/zend_API.c(565) : Actual location (location was relayed)
/usr/local/software/php4-200209181500/main/main.c(1381) :  Freeing 0x0817DB14 (12 bytes), script=/usr/local/apache/htdocs/web/test.php
/usr/local/software/php4-200209181500/main/php_variables.c(172) :  Freeing 0x0817DA74 (12 bytes), script=/usr/local/apache/htdocs/web/test.phpLast leak repeated 49 times
/usr/local/software/php4-200209181500/ext/standard/string.c(2387) :  Freeing 0x0817DA2C (19 bytes), script=/usr/local/apache/htdocs/web/test.php
Last leak repeated 49 times
/usr/local/software/php4-200209181500/Zend/zend_hash.c(440) :  Freeing 0x0817CD9C (128 bytes), script=/usr/local/apache/htdocs/web/test.php
Last leak repeated 1 time
/usr/local/software/php4-200209181500/main/main.c(1208) :  Freeing 0x0817B9FC (44 bytes), script=/usr/local/apache/htdocs/web/test.php
/usr/local/software/php4-200209181500/Zend/zend_API.c(565) : Actual location (location was relayed)
/usr/local/software/php4-200209181500/main/main.c(1207) :  Freeing 0x0817B9BC (12 bytes), script=/usr/local/apache/htdocs/web/test.php
/usr/local/software/php4-200209181500/main/php_variables.c(235) :  Freeing 0x0817B90C (44 bytes), script=/usr/local/apache/htdocs/web/test.php
/usr/local/software/php4-200209181500/Zend/zend_API.c(565) : Actual location (location was relayed)
Last leak repeated 1 time
/usr/local/software/php4-200209181500/main/php_variables.c(234) :  Freeing 0x
817B8CC (12 bytes), script=/usr/local/apache/htdocs/web/test.php
...
...
<lots more stuff>

However, static HTML files load up correctly without any problems.  But anything that is PHP related fails to display.  Any more help is appreciated.

Thanks

Forgot to mention in there I actually did compile the snapshot :)

Please try with a new snapshot from http://snaps.php.net/
as there were some fixes which might have fixed this too.

And please try with ONLY --with-apxs option first. If that works, then add your options..

Ok, did this with the new snapshot, however I've figured out what causes the PHP 4.3.0-dev to hang.  Basically if I use the --with-zlib configure option, a simple <?phpinfo()?> fails to load correctly.  If I take this option out, then the <?phpinfo()?> displays correctly.  I then tried to reinstall zlib (in case it was somehow messed up in RedHat) but that made no difference.  I tried different variations of --with-zlib such as:

* --with-zlib
* --with-zlib=/usr/local
* --with-zlib=/usr
* --with-zlib=/usr/local --with-zlib-dir=/usr/local
* --with-zlib=/usr --with-zlib-dir=/usr

If I use any of these, PHP scripts fail to load with the new dev snapshot.  However, I am using this option with 4.2.3 with no problems.  Maybe its a bug in the dev snapshot?  If you need any more information let me know.

Thanks

unfortunately, this does not fix the original problem, I still get seg faults when viewing messages (no particular message).  I'll try to post a backtrace a little later

sorry, i forgot to mention that I tried running the snapshot without zlib support (and png and dom xml support) and got IMP to somewhat work under that environment.  However, like I said previously the snapshot did not fix the seg fault problem I am having.  Please let me know what you want to do next

Thanks

I guess the zlib issue is with the output buffering.
Check your php.ini settings. (and try using the php.ini-dist as base for your new one..)

And the original problem, if the backtrace you get now is
about the same as the one you already pasted here, don't add another one. Reclassified as PCRE related.

Using php.ini-recommended fixed the zlib problem.  So now I am able to use the snapshot normally.  However, I ran apache within gdb and I got pretty much the exact same backtrace as I got with 4.2.3.  I guess it looks like a PCRE problem.  Please let me know what I need to do next and thanks for the quick response

I'm encounting this same bug using Horde/IMP/Turba (2.1/3.1/1.1) on Red Hat 7.3 with all updates (except mm-1.1.3-8 which seems to cause problems with  Apache restarts) and here's what i've tried:

- compiling Apache (1.3.26), PHP (4.2.3), and mod_ssl (2.8.10) without mm support
- compiling PHP 4.2.3 without mm support and using the pcre library packaged with Red Hat 
- downloading a fresh pcre library (v3.9) and compiling PHP against that.
- compiling everything with mm support and external pcre library (3.9)

In each case the same segfault occurs.
If i compile the software (Apache, mod_ssl, PHP) with debugging symbols i can't get the segfault to occur.  Been through about 300 test messages and it still hasn't segfaulted.
This is driving me nuts.

I upgraded from 4.1.2 to 4.2.3 yesterday and have seen many seg faults in the error_log when I came in this morning.

I am using Apache 1.3.26, mod_ssl 2.8.10, Openssl 0.9.6g, Compaq Tru64 4.0G.

My PHP configure is pretty basic:
./configure --with-mysql --with-imap --with-curl --quiet --with-apxs=(path_to_apxs)

We, also, are using IMP (2.2.7).  I have not tried to produce the seg-faults

hello!

i have nearly the same problem...

i've wondered, that sometimes are segfaults in the error_log. i have installed 
the newest php (4.2.3) & apache (1.3.26) version.

now i have found a cause:

if this in the mail header:
From: ()

imp shows   as sender. with the attempt to open the email, the apache-
process segfaulted. after some try, i could fetch a strace-log from the process.

you can found it here: http://dpits.de/segfault.log

thank you!

bye
daniel prior

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

Still getting the segfault at almost the same place.  Seems a lot easier to reproduce now.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 8821)]
0x4207fb88 in strcmp () from /lib/i686/libc.so.6
(gdb) bt
#0  0x4207fb88 in strcmp () from /lib/i686/libc.so.6
#1  0x40304db2 in pcre_get_compiled_regex (
    regex=0x819925c "|Internet Explorer/([0-9.]+)|", extra=0xbfff8ebc,
    preg_options=0xbfff8eb4) at /tmp/php4-200210060000/ext/pcre/php_pcre.c:158
#2  0x40305827 in php_pcre_match (ht=3, return_value=0x81353cc, this_ptr=0x0,
    return_value_used=1, global=0) at /tmp/php4-200210060000/ext/pcre/php_pcre.c:408
#3  0x40305e74 in zif_preg_match (ht=3, return_value=0x81353cc, this_ptr=0x0,
    return_value_used=1) at /tmp/php4-200210060000/ext/pcre/php_pcre.c:559
#4  0x403eafa3 in execute (op_array=0x81e5dfc)
    at /tmp/php4-200210060000/Zend/zend_execute.c:1597
#5  0x403eb1d6 in execute (op_array=0x8198e24)
    at /tmp/php4-200210060000/Zend/zend_execute.c:1641
#6  0x403eb1d6 in execute (op_array=0x8223314)
    at /tmp/php4-200210060000/Zend/zend_execute.c:1641
#7  0x403ed202 in execute (op_array=0x817d5e4)
    at /tmp/php4-200210060000/Zend/zend_execute.c:2163
#8  0x403d9128 in zend_execute_scripts (type=8, retval=0x0, file_count=3)
    at /tmp/php4-200210060000/Zend/zend.c:834
#9  0x403a2b92 in php_execute_script (primary_file=0xbffff6f0)
    at /tmp/php4-200210060000/main/main.c:1542
#10 0x403eff12 in apache_php_module_main (r=0x808cf18, display_source_mode=0)
    at /tmp/php4-200210060000/sapi/apache/sapi_apache.c:55
#11 0x403f0e0c in send_php (r=0x808cf18, display_source_mode=0,
    filename=0x808ec10 "/var/www/modesmail/horde/imp/redirect.php")
    at /tmp/php4-200210060000/sapi/apache/mod_php4.c:564
#12 0x403f0e79 in send_parsed_php (r=0x808cf18)
---Type <return> to continue, or q <return> to quit---
    at /tmp/php4-200210060000/sapi/apache/mod_php4.c:579
#13 0x0805475d in ap_invoke_handler ()
#14 0x080672dc in process_request_internal ()
#15 0x08067353 in ap_process_request ()
#16 0x0805f587 in child_main ()
#17 0x0805f72a in make_child ()
#18 0x0805f86d in startup_children ()
#19 0x0805fec0 in standalone_main ()
#20 0x080607c3 in main ()
#21 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6

speedfreak50@netscape.net :
Can you try that again, but when you hit the segfault,
type the following commands into gdb:

up
print locale
print pce
print pce->locale

(gdb) up
#1  0x40304db2 in pcre_get_compiled_regex (regex=0x8201704 "|MSIE ([0-9.]+)|",
    extra=0xbfff7cac, preg_options=0xbfff7ca4)
    at /tmp/php4-200210060000/ext/pcre/php_pcre.c:158
158                     if (!strcmp(pce->locale, locale)) {
(gdb) print locale
$1 = 0x8156760 "en_US.iso885915"
(gdb) print pce
$2 = (pcre_cache_entry *) 0x8133668
(gdb) print pce->locale
$3 = 0x826bde8 <Address 0x826bde8 out of bounds>

Note sure if this will be useful, but if i edit main/php_config.h (after running ./configure) and remove all LOCALE defines, here's a backtrace of the segfault:

------------------

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 6702)]
0x403d6c67 in _zval_dtor (zvalue=0x82ad344,
    __zend_filename=0x40432520 "/tmp/php-debug/Zend/zend_execute_API.c",
    __zend_lineno=291) at /tmp/php-debug/Zend/zend_variables.c:43
43                              CHECK_ZVAL_STRING_REL(zvalue);
(gdb) bt
#0  0x403d6c67 in _zval_dtor (zvalue=0x82ad344,
    __zend_filename=0x40432520 "/tmp/php-debug/Zend/zend_execute_API.c",
    __zend_lineno=291) at /tmp/php-debug/Zend/zend_variables.c:43
#1  0x403cd471 in _zval_ptr_dtor (zval_ptr=0x40463b80,
    __zend_filename=0x40434300 "/tmp/php-debug/Zend/zend_execute_locks.h",
    __zend_lineno=26) at /tmp/php-debug/Zend/zend_execute_API.c:291
#2  0x403ee0b4 in zend_clean_garbage () at /tmp/php-debug/Zend/zend_execute_locks.h:26
#3  0x403e7bd5 in execute (op_array=0x82ae564) at /tmp/php-debug/Zend/zend_execute.c:1050
#4  0x403eab86 in execute (op_array=0x81e95c4) at /tmp/php-debug/Zend/zend_execute.c:1641
#5  0x403eab86 in execute (op_array=0x8241b2c) at /tmp/php-debug/Zend/zend_execute.c:1641
#6  0x403d8ad8 in zend_execute_scripts (type=8, retval=0x0, file_count=3)
    at /tmp/php-debug/Zend/zend.c:834
#7  0x403a2542 in php_execute_script (primary_file=0xbffff700)
    at /tmp/php-debug/main/main.c:1542
#8  0x403ef8c2 in apache_php_module_main (r=0x808cf18, display_source_mode=0)
    at /tmp/php-debug/sapi/apache/sapi_apache.c:55
#9  0x403f07bc in send_php (r=0x808cf18, display_source_mode=0,
    filename=0x808ebe0 "/var/www/modesmail/horde/imp/redirect.php")
    at /tmp/php-debug/sapi/apache/mod_php4.c:564
#10 0x403f0829 in send_parsed_php (r=0x808cf18)
    at /tmp/php-debug/sapi/apache/mod_php4.c:579
#11 0x0805475d in ap_invoke_handler ()
#12 0x080672dc in process_request_internal ()
#13 0x08067353 in ap_process_request ()
#14 0x0805f587 in child_main ()
#15 0x0805f72a in make_child ()
---Type <return> to continue, or q <return> to quit---
#16 0x0805f86d in startup_children ()
#17 0x0805fec0 in standalone_main ()
#18 0x080607c3 in main ()
#19 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6

I tried with the newest snapshot but I get the following backtrace

(gdb) run -X -DSSL -f /usr/local/apache/conf/httpd.conf
Starting program: /usr/local/apache/bin/httpd -X -DSSL -f /usr/local/apache/conf/httpd.conf

Program received signal SIGSEGV, Segmentation fault.
0x403d2e94 in _efree (ptr=0x0)
    at /usr/local/software/php4-200210061800/Zend/zend_alloc.c:211
211		CALCULATE_REAL_SIZE_AND_CACHE_INDEX(p->size);
(gdb) bt
#0  0x403d2e94 in _efree (ptr=0x0)
    at /usr/local/software/php4-200210061800/Zend/zend_alloc.c:211
#1  0x403e5b8e in zend_hash_destroy (ht=0x82ea824)
    at /usr/local/software/php4-200210061800/Zend/zend_hash.c:550
#2  0x403e063a in _zval_dtor (zvalue=0x81802ec)
    at /usr/local/software/php4-200210061800/Zend/zend_variables.c:51
#3  0x403f1206 in execute (op_array=0x82d130c)
    at /usr/local/software/php4-200210061800/Zend/zend_execute.c:449
#4  0x403f411a in execute (op_array=0x82182e4)
    at /usr/local/software/php4-200210061800/Zend/zend_execute.c:1641
#5  0x403e1adc in zend_execute_scripts (type=8, retval=0x0, file_count=3)
    at /usr/local/software/php4-200210061800/Zend/zend.c:834
#6  0x403bbfed in php_execute_script (primary_file=0xbffff6d0)
    at /usr/local/software/php4-200210061800/main/main.c:1542
#7  0x403fb4b6 in apache_php_module_main (r=0x816c9e0, display_source_mode=0)
    at /usr/local/software/php4-200210061800/sapi/apache/sapi_apache.c:55
#8  0x403fbfd6 in send_php (r=0x816c9e0, display_source_mode=0, filename=0x0)
    at /usr/local/software/php4-200210061800/sapi/apache/mod_php4.c:564
#9  0x403fc02a in send_parsed_php (r=0x816c9e0)
    at /usr/local/software/php4-200210061800/sapi/apache/mod_php4.c:579
#10 0x0806bdcf in ap_invoke_handler ()
#11 0x08080e53 in process_request_internal ()
#12 0x08080eb4 in ap_process_request ()
---Type <return> to continue, or q <return> to quit---
#13 0x08077df1 in child_main ()
#14 0x08077fc0 in make_child ()
#15 0x08078134 in startup_children ()
#16 0x080787ac in standalone_main ()
#17 0x0807902b in main ()
#18 0x42017499 in __libc_start_main () from /lib/i686/libc.so.6

Please try this patch and report back:

RCS file: /repository/php4/ext/pcre/php_pcre.c,v
retrieving revision 1.128
diff -u -2 -b -w -B -r1.128 php_pcre.c
--- ext/pcre/php_pcre.c 11 Sep 2002 14:41:25 -0000  1.128
+++ ext/pcre/php_pcre.c 7 Oct 2002 16:05:59 -0000
@@ -67,4 +67,5 @@
 #if HAVE_SETLOCALE
    if ((void*)pce->tables) pefree((void*)pce->tables, 1);
+   pefree(pce->locale, 1);
 #endif
 }
@@ -303,5 +304,5 @@
    new_entry.preg_options = poptions;
 #if HAVE_SETLOCALE
-   new_entry.locale = locale;
+   new_entry.locale = pestrdup(locale, 1);
    new_entry.tables = tables;
 #endif

I applied the patch to php4-200209191800 (the newest snapshot died with some other unrelated problem) and ran my normal tests.  Looked like this fixed it!  I went through 174 emails with IE and had no segfaults.  Thanks for everyone's help in solving this problem and continue with the good work.

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.