ID: 19655 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Session related Operating System: 2.2.20 PHP Version: 4.2.3 New Comment:
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 ... Previous Comments: ------------------------------------------------------------------------ [2002-09-29 14:23:28] [EMAIL PROTECTED] 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) ------------------------------------------------------------------------ [2002-09-29 08:26:12] [EMAIL PROTECTED] Please recompile PHP with --enable-debug and provide a new backtrace. ------------------------------------------------------------------------ [2002-09-29 07:03:06] [EMAIL PROTECTED] 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 ? ------------------------------------------------------------------------ [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 ... ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/19655 -- Edit this bug report at http://bugs.php.net/?id=19655&edit=1
