To properly diagnose this bug, 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".

gdb bt is:
#0  0x40074c5d in zend_hash_del_key_or_index ()
   from /usr/lib/libphp_common-4.0.6.so.0
#1  0x40071856 in module_destructor () from /usr/lib/libphp_common-4.0.6.so.0
#2  0x40075848 in zend_hash_destroy () from /usr/lib/libphp_common-4.0.6.so.0
#3  0x4006fe86 in zend_shutdown () from /usr/lib/libphp_common-4.0.6.so.0
#4  0x4007cc1b in php_module_shutdown () from /usr/lib/libphp_common-4.0.6.so.0
#5  0x0804a4d7 in main ()
#6  0x40220370 in __libc_start_main () from /lib/libc.so.6

Is libphp_common-4.0.6.so.o the right lib for
PHP 4.1.1? This was in rpm php-common-4.1.1-3mdk.

I guess it could be a mistake of deleting a key where
an index is excepted or the other way around
(zend_hash_del_key_or_index).

Frerk

Reproduced in latest CVS:

Starting program: /home/mfischer/php4/bin/php -f sem.php
[Fri Mar 22 02:05:13 2002]  Script:  '-'
---------------------------------------
/home/mfischer/isrc/cvs/php4/Zend/zend_execute.h(62) : Block 0x081CCB10 status:
Beginning:      Overrun (magic=0xC07A9F32, expected=0x7312F8DC)
      End:      Unknown
---------------------------------------

Program received signal SIGSEGV, Segmentation fault.
0x400fbeb3 in free () from /lib/libc.so.6
(gdb) bt full
#0  0x400fbeb3 in free () from /lib/libc.so.6
No symbol table info available.
#1  0x400fbc13 in free () from /lib/libc.so.6
No symbol table info available.
#2  0x08124ca3 in shutdown_memory_manager (silent=0, clean_cache=0) at /home/mfischer/isrc/cvs/php4/Zend/zend_alloc.c:484
        ptr = (zend_mem_header *) 0x81cd780
        p = (zend_mem_header *) 0xbffffb14
        t = (zend_mem_header *) 0x40014b2c
        fci = 4
        i = 1
        j = 0
        had_leaks = 0
        fast_cache_list_entry = (zend_fast_cache_list_entry *) 0x0
        next_fast_cache_list_entry = (zend_fast_cache_list_entry *) 0xbffff50c
#3  0x08109555 in php_request_shutdown (dummy=0x0) at /home/mfischer/isrc/cvs/php4/main/main.c:792
        orig_bailout = {{__jmpbuf = {1075470440, 1073826604, -1073743084, -1073743188, -1073743500, 135573829}, __mask_was_saved = 0, __saved_mask = {__val = {
        0 <repeats 32 times>}}}}
        orig_bailout_set = 1 '\001'
#4  0x0814b921 in main (argc=3, argv=0xbffffb14) at /home/mfischer/isrc/cvs/php4/sapi/cli/php_cli.c:635
        orig_bailout = {{__jmpbuf = {0, 0, 0, 0, 0, 0}, __mask_was_saved = 0, __saved_mask = {__val = {0 <repeats 32 times>}}}}
        orig_bailout_set = 0 '\000'
        exit_status = 0
        c = 60
        file_handle = {type = 2 '\002', filename = 0xbffffc15 "sem.php", opened_path = 0x0, handle = {fd = 136086216, fp = 0x81c82c8}, free_filename = 0 '\000'}
        behavior = 1
        no_headers = 1
        orig_optind = 1
        orig_optarg = 0x0
        arg_free = 0xbffffc15 "sem.php"
        arg_excp = (char **) 0xbffffb1c
        script_file = 0xbffffc15 "sem.php"
        global_vars = {head = 0x0, tail = 0x0, size = 4, count = 0, dtor = 0, persistent = 0 '\000', traverse_ptr = 0x818ba58}
        interactive = 0
        exec_direct = 0x0
#5  0x400a66cf in __libc_start_main () from /lib/libc.so.6
No symbol table info available.
(gdb) 

Tracked it down to line 406 in ext/sysvsem/sysvsem.c:
  if(semctl(sem_ptr->semid,NULL,IPC_STAT,un)<0) {
if this line is uncommented, no segfault but a leak:

Starting program: /home/mfischer/php4/bin/php -f sem.php
/home/mfischer/isrc/cvs/php4/ext/sysvsem/sysvsem.c(297) :  Freeing 0x081C82AC (16 bytes), script=-

which may be due release_sysvsem_sem() not freeeing sem_ptr if count == -1 .. ?

someone else take this :-)

I'm not familiar with the code, but this
patch fixes things for me.

Could you give it a try?

http://www.edin.dk/php/sysvsem.c.patch

Solaris test would be very welcome too.

The patch surely removes the symptom, but is it the right fix?

It still leaks because if count == -1 then the emalloc() is not freed in the *release function().

Anyway I'ld like to get someone his hands on this who is more familiar with the code and semaphores.

Doesn't seem to crash nowadays. (clearing out bug reports forgotten because of a stupid bug in our bug system..)