Can you try with -X added to the flags passed to run in gdb, to try a single-process startup.

Yes, you're right. There is a Segmentation Violation: 
 
(gdb) run -DSSL -e debug -k start -X 
Starting program: /uxd/apache-server2/bin/httpd -DSSL -e 
debug -k start -X 
[Tue Oct 26 15:03:42 2004] [debug] mod_so.c(247): loaded 
module include_module 
[Tue Oct 26 15:03:42 2004] [debug] mod_so.c(247): loaded 
module deflate_module 
[Tue Oct 26 15:03:42 2004] [debug] mod_so.c(247): loaded 
module log_config_module 
[Tue Oct 26 15:03:42 2004] [debug] mod_so.c(247): loaded 
module env_module 
[Tue Oct 26 15:03:42 2004] [debug] mod_so.c(247): loaded 
module ssl_module 
[Tue Oct 26 15:03:42 2004] [debug] mod_so.c(247): loaded 
module status_module 
[Tue Oct 26 15:03:42 2004] [debug] mod_so.c(247): loaded 
module info_module 
[Tue Oct 26 15:03:43 2004] [debug] mod_so.c(247): loaded 
module negotiation_module 
[Tue Oct 26 15:03:43 2004] [debug] mod_so.c(247): loaded 
module dir_module 
[Tue Oct 26 15:03:43 2004] [debug] mod_so.c(247): loaded 
module alias_module 
[Tue Oct 26 15:03:43 2004] [debug] mod_so.c(247): loaded 
module php4_module 
 
Program received signal SIGSEGV, Segmentation fault. 
0x00000000 in ?? () 
(gdb) bt 
#0  0x00000000 in ?? () 
#1  0x407f9cec in db_open () from /lib/libnss_db.so.2 
#2  0x407f9dac in internal_setent () from /lib/libnss_db.so.2 
#3  0x407f85dd in _nss_db_endprotoent () from 
/lib/libnss_db.so.2 
#4  0x407f8887 in _nss_db_getprotobyname_r () from 
/lib/libnss_db.so.2 
#5  0x403fd080 in getprotobyname_r () from /lib/libc.so.6 
#6  0x403fcf31 in getprotobyname () from /lib/libc.so.6 
#7  0x40551484 in zm_startup_sockets (type=1, 
module_number=4) at 
/uxd/temp/php-4.3.9/ext/sockets/sockets.c:461 
#8  0x405f59b3 in zend_startup_module (module=0x406fa040) 
at /uxd/temp/php-4.3.9/Zend/zend_API.c:1005 
#9  0x405c9294 in php_startup_extensions (ptr=0x40705908, 
count=19) at /uxd/temp/php-4.3.9/main/main.c:1044 
#10 0x4060e54f in php_startup_internal_extensions () at 
main/internal_functions.c:81 
#11 0x405c9845 in php_module_startup (sf=0x407055e0, 
additional_modules=0x407058c0, num_additional_modules=1) 
at /uxd/temp/php-4.3.9/main/main.c:1216 
#12 0x4060c1e6 in php_apache2_startup 
(sapi_module=0x407055e0) at 
/uxd/temp/php-4.3.9/sapi/apache2handler/sapi_apache2.c:289 
#13 0x4060c34d in php_apache_server_startup 
(pconf=0x80a5090, plog=0x80d9160, ptemp=0x80f7958, 
s=0x80a9198) at 
/uxd/temp/php-4.3.9/sapi/apache2handler/sapi_apache2.c:388 
#14 0x0806eaa1 in ap_run_post_config (pconf=0x80a5090, 
plog=0x80d9160, ptemp=0x80f7958, s=0x80a9198) at 
config.c:87 
#15 0x0807364c in main (argc=7, argv=0xbffff854) at 
main.c:606 
#16 0x4033117d in __libc_start_main () from /lib/libc.so.6

This looks suspiciously like a bad glibc installation:

#0  0x00000000 in ?? () 
#1  0x407f9cec in db_open () from /lib/libnss_db.so.2 

I doubt there is a PHP or Apache bug here.  Try a simple program calling getprotobyname("tcp") to see if that segfaults; try it again when linked against -ldb.

It doesn't break. Test program is: 
 
#include <netdb.h> 
#include <stdio.h> 
 
int main(int argc, char *argv) 
{ 
  struct protoent *pe; 
  pe=getprotobyname("tcp"); 
  printf("Name: %s, Number: %u\n",pe->p_name,pe->p_proto); 
} 
 
Tests are: 
-Test 1: 
gcc tst-libc6.c -o tst-libc6 
ldd tst-libc6 
        libc.so.6 => /lib/libc.so.6 (0x40024000) 
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) 
./tst-libc6 
Name: tcp, Number: 6 
-Test 2: 
gcc tst-libc6.c -o tst-libc6 -ldb 
ldd tst-libc6 
        libc.so.6 => /lib/libc.so.6 (0x40024000) 
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) 
./tst-libc6 
Name: tcp, Number: 6 
-Test 3: 
gcc tst-libc6.c -o tst-libc6 -lnss_db 
ldd tst-libc6 
        libnss_db.so.2 => /lib/libnss_db.so.2 (0x40024000) 
        libc.so.6 => /lib/libc.so.6 (0x4002b000) 
        libnss_files.so.2 => /lib/libnss_files.so.2 (0x4014e000) 
        libdb-3.1.so => /lib/libdb-3.1.so (0x40157000) 
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) 
./tst-libc6 
Name: tcp, Number: 6 
 
So it works and doesn't segfault. Compared to a machine that 
works, I notice that the working one has a glibc 2.3.1 against 
the glibc 2.2.5 that drives the failing one. I will try to upgrade 
glibc, although it worked well for slightly older Apache+PHP 
versions and I have to evaluate posible collateral effects on 
other applications before upgrading glibc from 2.2 to 2.3... 
 
On the working machine, test 2 shows different libraries: 
-Test 2: 
gcc tst-libc6.c -o tst-libc6 -ldb 
ldd tst-libc6 
        libdb-3.3.so => /lib/libdb-3.3.so (0x40025000) 
        libc.so.6 => /lib/libc.so.6 (0x400af000) 
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) 
./tst-libc6 
Name: tcp, Number: 6 
 
Here it includes libdb (as you may expect), while on the first case 
Test2 just links against the same libraries as Test1 (both 
working). Maybe some dependencies in php make libraries to 
behave bogus and make that call to fail... I will try to upgrade 
libraries, but if you know a better method to avoid failure 
without changing them, will be of help (it is a production server, I 
can test new versions of Apache and PHP in parallel with the 
production daemons, but upgrading system libraries is a little 
more dangerous and painful as it is 24/7 service...) 
 
Thank you anyway for your time :-)

The fact that your test:

gcc tst-libc6.c -o tst-libc6 -ldb 

doesn't show up in ldd is dubious on the first machine.  It may be necessary to add:

extern int db_open(void);

to force the db_open symbol to be resolved at initial link time to trigger the same conditions as in PHP.

To debug the PHP issue further you could use LD_DEBUG and LD_DEBUG_OUTPUT (see "man ld.so") and work out where the db_open() is getting resolved to from nss_db.  All the copies of the nss_db library I have use a statically linked copy of Berkeley DB.