I forgot to talk about the environment : PHP 4.2.3 is compiled with Apache 1.3.26, mod_ssl 2.8.10, openssl 0.9.6g ...
I have logs relating that the Apache/mod_ssl worm (see http://www.cert.org/advisories/CA-2002-27.html) tried to infect the server ... Anyway, and according to CERT, it can only infect "<= openssl 0.9.6.d" ... But the hit of this worm could may be rewrite some parts of the memory (and addressing tables) ? This is just an idea, not the solution of my problem ...

More infos :
According to the symbols table (objdump), we have :
080e4d30 g     F .text  00000024              ps_gc_files
080e50d4 l     F .text  00000067              ps_mm_destroy

According to gdb, the problem is at 0x80e5100, meaning that is occurs into ps_mm_destroy ... Let say that gdb reporting is wrong ...But I still have the problem, I suppose ...

ps_mm_destroy() says :

/* This function is called during each module 
   shutdown, but we must not release the shared 
   memory pool, when an Apache child dies! */
   if (data->owner != getpid()) return;

Every child seems to try to free data, meaning that every child feel like data->owner == getpid()) ... How is this possible ?

Please recompile PHP with --enable-debug and provide a new backtrace.

Is your configure line REALLY like that? I think it's just
that you haven't got MM support. Check phpinfo() output for 'Additional Modules' list. There should be 'session mm' entry if you have it.

(I can't reproduce that segfault with 4.2.3 or 4.3.0-dev)

Well, the braces values indicate the release version I used to compiled ... The configure script is called by a shell script rebuilding automatically everything, in order to upgrade easilly the packages when new releases are availables ... Yes, the "session mm" appears under "Additional Modules" section ... And the handler is correct (session.save_handler -> mm) ... 

It seems that this trouble only occurs when the Apache server is hit by the OpenSSL/Worm Slapper (see http://www.cert.org/advisories/CA-2002-27.html) ... My apache is build with a 0.9.6g OpenSSL so that the worm can't infect the server, but it could may be corrupt the memory ? I rebuilt Apache+mod_php with --enable-debug=yes and re-opened the https port, waiting for the trouble to reapper, creating a core file ... Right now, the problem stopped like everytime I stop and restart the httpd process. 

Strange strange strange ...

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I feel like sure ( :-) ) that Apache/OpenSSL 0.9.6g is still
vulnerable to a Slapper worm attack ... 

I downloaded "Slapper worm like" code - available "for testing
prupose only" - from somewhere on the Internet, modified it to ensure
it will only attack my server when launched, and then launched it ...
Everything occured normally, the virus didn't infect my computer, the
same behaviour as the very first attacks. I used my httpd server and
segfaulted it by doing it ... I have gdb'ed my httpd+core, and
arrived on the same place in source code as mentioned in first first
gdb log. The
worm-like had crashed my apache. I checked logged and was the only
one to attack the computer. That means that OpenSSL 0.9.6g is not
safe right now ... I retried several times again but failed to
reproduce the crash ... That's why I "feel like sure" :-)

Anyway - and perhaps because of my parano. :) - I have closed my 443
window and wait for a better weather outside ;-)
openssl-0.9.6h.tar.gz ? :) An advice ...

My apache logs are showing tonight :
Unknown(0) : Notice - Login failed: authentication failure (errflg=1)
Unknown(0) : Notice - Login failed: authentication failure (errflg=1)
Unknown(0) : Notice - Login failed: authentication failure (errflg=1)
Unknown(0) : Notice - Too many login failures (errflg=2)

-----BEGIN PGP SIGNATURE-----
Version: PGP 7.0.1

iQA/AwUBPZdy0BTEKqrwXlPeEQKg2ACeM+Lm5/S4PyhWykqbJYdVJaH2S1YAn3F8
XZBoIUmzRJ71rEgPRzoEm6/6
=fJ52
-----END PGP SIGNATURE-----

Please, don't sign your comments..and are you 100% sure 
you're really compiling with 0.9.6g ? And that ALL your
software is linked with it?

Best way to be sure about it is to first remove all binaries
compiled with openssl and all old openssl libraries from your system and compile the latest from scratch.

> and are you 100% sure you're really compiling with 0.9.6g ? 

Yes, Apache+mod_ssl are linked with a just "untagzip'ed and compiled" openssl-0.9.6g ...

> And that ALL your software is linked with it?

Why would other software be linked with it ? We're only takking about a httpd process, not the whole of the system.

> Best way to be sure about it is to first remove all binaries
> compiled with openssl and all old openssl libraries from your system
> and compile the latest from scratch.

Why would I do that ? I am sure the steps I made : it is an Apache+0.9.6g (as shown in headers) and it is crashed by the worm code :(

Georges

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 meant all the libraries you link with PHP and apache with.
But please try the snapshot, it's more likely not related to SSL anyway and there were some fixes in CVS just today which should prevent this.

I tested the php4-200209300600 snap. I still have apache segfaulting :

#0  ps_mm_destroy (data=0x83f26a8) at /space/build/apache/php4-200209300600/ext/session/mod_mm.c:241
241                             next = sd->next;
(gdb) bt
#0  ps_mm_destroy (data=0x83f26a8) at /space/build/apache/php4-200209300600/ext/session/mod_mm.c:241
#1  0x8135606 in zm_shutdown_ps_mm (type=1, module_number=18) at /space/build/apache/php4-200209300600/ext/session/mod_mm.c:293
#2  0x81348c4 in zm_shutdown_session (type=1, module_number=18)
    at /space/build/apache/php4-200209300600/ext/session/session.c:1511
#3  0x80e880f in module_destructor (module=0x83e2518) at /space/build/apache/php4-200209300600/Zend/zend_API.c:1128
#4  0x80e9e47 in zend_hash_apply_deleter (ht=0x839d460, p=0x83e24e8) at /space/build/apache/php4-200209300600/Zend/zend_hash.c:598
#5  0x80e9f59 in zend_hash_graceful_reverse_destroy (ht=0x839d460) at /space/build/apache/php4-200209300600/Zend/zend_hash.c:664
#6  0x80e62dc in zend_shutdown () at /space/build/apache/php4-200209300600/Zend/zend.c:512
#7  0x80cae93 in php_module_shutdown () at /space/build/apache/php4-200209300600/main/main.c:1193
#8  0x80cae74 in php_module_shutdown_wrapper (sapi_globals=0x835b520) at /space/build/apache/php4-200209300600/main/main.c:1170
#9  0x80c1540 in apache_php_module_shutdown_wrapper ()
#10 0x81966ce in run_cleanups ()
#11 0x8194db4 in ap_clear_pool ()
#12 0x8194e29 in ap_destroy_pool ()
#13 0x8194d8c in ap_clear_pool ()
#14 0x8194e29 in ap_destroy_pool ()
#15 0x81a38c2 in clean_parent_exit ()
#16 0x81a6593 in standalone_main ()
#17 0x81a6a93 in main ()

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

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.