Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.

of course there should be:

<?
session_start();
$_SESSION['temp'] = 'test';
?>

semicolon missing

Apache segfault log entry:

[Sat Dec 14 03:41:39 2002] [notice] child pid 3613 exit signal Segmentation fault (11)

That is not a back trace, please follow the instructions as described here:
http://bugs.php.net/bugs-generating-backtrace.php

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.

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)

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 ()

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

#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

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.

Sorry, I meant "print *data" and "print *sd" so that we see the contents of the arguments. Can you also do "print slot", "print data->hash", "print *(data->hash)" and "print *prev" for me?

My comments moved to #20358.