ID: 19655 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Session related Operating System: 2.2.20 PHP Version: 4.2.3 New Comment:
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 ? Previous Comments: ------------------------------------------------------------------------ [2002-09-29 06:55:37] [EMAIL PROTECTED] 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 ... ------------------------------------------------------------------------ [2002-09-29 06:39:42] [EMAIL PROTECTED] 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 ... ------------------------------------------------------------------------ [2002-09-29 06:16:05] [EMAIL PROTECTED] Hi there, I have a strange problem : when my apache childs are exiting, they crashs in a very strange way. --- 8< --- ./configure --prefix=/usr/local/php --with-apache=[1.2.26] --with-mysql=/usr/local/mysql --enable-memory-limit=yes --enable-debug=no --with-gettext=[path_to_gettext] --with-imap=[imap-2002.RC6] --with-xml --with-mcrypt=[2.5.3] --with-mm=[1.2.1] --- 8< --- First, the behaviour is the same with mm-1.1.3 ... My PHP is using mm as sessions handler (session.save_handler = mm) but the gdb back trace is _VERY_ strange : (gdb) bt #0 0x80e5100 in ps_gc_files () #1 0x80e5286 in zm_shutdown_ps_mm () #2 0x81425bf in module_destructor () #3 0x8143ae9 in zend_hash_destroy () #4 0x81400bc in zend_shutdown () #5 0x80bfbe7 in php_module_shutdown () #6 0x80bfbc8 in php_module_shutdown_wrapper () #7 0x80bdd60 in php_xbithack_handler () #8 0x815f8ce in ap_run_cleanup () #9 0x815dfb4 in ap_clear_pool () #10 0x815e029 in ap_destroy_pool () #11 0x815df8c in ap_clear_pool () #12 0x815e029 in ap_destroy_pool () #13 0x816cac2 in ap_exists_scoreboard_image () #14 0x816f793 in ap_child_terminate () #15 0x816fc93 in main () #16 0x400d99cb in __libc_start_main () at hash/hash_rec.c:724 #1 is sayung that zm_shutdown_ps_mm is being called, which is normal, but #0 says that zm_shutdown_ps_mm calls ps_gc_files, and this is not normal : ps_gc_files is a "files sessions" handler and not a mm handler ... Any idea ? ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=19655&edit=1
