php 4 smp problem - stalled by SIGSEGV in zend_hash_index_find()

> Our code has at least one problem. It calls php_error() from > a signal handler. This function is definitively not > reentrant (i.e. it manipulates hashes without locking etc. > The obvious worst-case is that SIGPROF is delivered to the > process while it is already in php_error()). > > So, please try the attached patch. Sascha, I patched, compiled and ran it. The problem is that I can't leave it running since there is such a bad SIGSEGV on mysql_connect(). See backtrace below. I'm depending on MySQL support, and can't try your patch without MySQL working. I've reported this twice to php4beta-list and php-dev, but there has been no visible reaction from anyone at all, so far. Unfortunately, I've been forced to roll back to PHP beta 2 because of this MySQL-thing. What shall I do? Whom shall I contact? The SIGSEGV is in zend_hash_index_find() = is this an issue for Zeev? All the best, /Johan Ekenberg 1) Offending code: <?php $site = 'localhost'; $username = 'press'; $password = 'xxxxxxxx'; // I replaced this $db = 'press_3'; mysql_connect($site, $username, $password) || die ("noop"); ?> 2) Backtrace: Starting program: /usr/local/apache/bin/httpd -X Program received signal SIGSEGV, Segmentation fault. 0x80ee439 in zend_hash_index_find (ht=0x832e9ac, h=1, pData=0xbffff840) at zend_hash.c:989 989 if ((p->h == h) && (p->nKeyLength == 0)) { (gdb) bt #0 0x80ee439 in zend_hash_index_find (ht=0x832e9ac, h=1, pData=0xbffff840) at zend_hash.c:989 #1 0x80ef29d in zend_list_do_delete (list=0x832e9ac, id=1) at zend_list.c:51 #2 0x80eed41 in zend_list_delete (id=1) at zend_list.c:113 #3 0x80e732b in _zval_dtor (zvalue=0x8de9008, __zend_filename=0x829a655 "zend_execute_API.c", __zend_lineno=147) at zend_variables.c:80 #4 0x80de2cc in shutdown_executor () at zend_execute_API.c:147 #5 0x80e820f in zend_deactivate () at zend.c:454 #6 0x80cedd2 in php_request_shutdown (dummy=0x0) at main.c:782 #7 0x8168f1e in run_cleanups (c=0x863b794) at alloc.c:1940 #8 0x816732c in ap_clear_pool (a=0x85a4d24) at alloc.c:683 #9 0x81673b1 in ap_destroy_pool (a=0x85a4d24) at alloc.c:713 #10 0x817951b in child_main (child_num_arg=0) at http_main.c:4133 #11 0x8179688 in make_child (s=0x8333f94, slot=0, now=947028337) at http_main.c:4238 #12 0x8179813 in startup_children (number_to_start=200) at http_main.c:4320 #13 0x8179e94 in standalone_main (argc=2, argv=0xbffff9b4) at http_main.c:4608 #14 0x817a803 in main (argc=2, argv=0xbffff9b4) at http_main.c:4944 (gdb)