ID: 20988
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: Session related
Operating System: Linux 2.4.19 (Debian)
PHP Version: 4.3.0RC3
New Comment:
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same. Because of this, we hope you add your comments
to the existing bug instead.
Thank you for your interest in PHP.
This is a known issue with the 'mm' session handler that is described
in report #20358. In the interest of keeping the discussion about this
bug in one place I am closing this report.
Previous Comments:
------------------------------------------------------------------------
[2002-12-13 08:33:44] [EMAIL PROTECTED]
#0 0x48287655 in ps_sd_destroy (data=0x811b0a0, sd=0x4c6c2354) at
mod_mm.c:168
168 for (prev = data->hash[slot]; prev->next != sd;
prev = prev->next);
print data:
$1 = (ps_mm *) 0x811b0a0
print sd:
$2 = (ps_sd *) 0x4c6c2354
------------------------------------------------------------------------
[2002-12-13 08:23:33] [EMAIL PROTECTED]
Before this backtrace, GDB should have spit out an error too with a
source line, can you please paste that one in the form, and also the
result of:
print data
and
print sd
(at the same place as were you typed 'bt').
thanks!
Derick
------------------------------------------------------------------------
[2002-12-13 08:20:18] [EMAIL PROTECTED]
Managed to get backtrace on FreeBSD box:
#0 0x48287655 in ps_sd_destroy (data=0x811b0a0, sd=0x4c6c2354) at
mod_mm.c:168
#1 0x4828784f in ps_mm_destroy (data=0x811b0a0) at mod_mm.c:242
#2 0x48287a25 in zm_shutdown_ps_mm (type=1, module_number=11) at
mod_mm.c:293
#3 0x48231e93 in module_destructor (module=0x811c500) at
zend_API.c:1127
#4 0x482338d3 in zend_hash_destroy (ht=0x48333b80) at zend_hash.c:541
#5 0x4822ef3f in zend_shutdown () at zend.c:492
#6 0x4823c107 in php_module_shutdown () at main.c:1052
#7 0x4823c0d4 in php_module_shutdown_wrapper
(sapi_globals=0x48311880)
at main.c:1029
#8 0x48239abc in apache_php_module_shutdown_wrapper () at
mod_php4.c:800
#9 0x805003a in run_cleanups ()
#10 0x804f09f in ap_clear_pool ()
#11 0x804f100 in ap_destroy_pool ()
#12 0x804f08b in ap_clear_pool ()
#13 0x804f100 in ap_destroy_pool ()
#14 0x8059460 in clean_parent_exit ()
#15 0x805b925 in standalone_main ()
#16 0x805bd6b in main ()
#17 0x804eb0d in _start ()
------------------------------------------------------------------------
[2002-12-13 07:57:20] [EMAIL PROTECTED]
While trying to backtrace a particular forked child it would not
segfault until i detach gdb from it - then it segfaults with:
[Sat Dec 14 05:02:19 2002] [notice] child pid 4858 exit signal
Segmentation fault (11)
------------------------------------------------------------------------
[2002-12-13 07:34:33] [EMAIL PROTECTED]
I know it's not a backtrace. I have just forgot to paste apache log
segfault line example in my original posting.
However. When trying to backtrace I cannot reproduce this
behavior. It's happening under constant heavy load that
can be simulated using ab -n 10000 and the example script
I have supplied. Only after about 3000-4000 request this
one happens. I cannot execute 3000 request because httpd -X
exits after several hundred requests (normal exit - no backtrace) and I
don't know why.
------------------------------------------------------------------------
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/20988
--
Edit this bug report at http://bugs.php.net/?id=20988&edit=1
