Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:6120 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 67515 invoked by uid 1010); 3 Dec 2003 17:06:38 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 67449 invoked from network); 3 Dec 2003 17:06:38 -0000 Received: from unknown (HELO max6.rrze.uni-erlangen.de) (131.188.3.214) by pb1.pair.com with SMTP; 3 Dec 2003 17:06:38 -0000 Received: from [131.188.163.104] by max6.rrze.uni-erlangen.de with ESMTP; Wed, 3 Dec 2003 18:06:30 +0100 Message-ID: <6.0.1.1.0.20031203175354.039cac08@127.0.0.1> X-Sender: snuwschi@pop.rrze.uni-erlangen.de X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Wed, 03 Dec 2003 18:06:13 +0100 To: jay@php.net, internals@lists.php.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60-rrze_05 (1.212-2003-09-23-exp) on spamela2.rrze.uni-erlangen.de X-Spam-RRZE-Info: Diese Mail wurde einer automatischen Spam-Analyse unterzogen, siehe: http://www.rrze.uni-erlangen.de/SPAM-Analyse/ Subject: browscap and nesting level too deep (bug #25916) From: uwe@thetaphi.de (Uwe Schindler) Today I got the error from bug #25916 several times on our webserver. Looking through the code I found out the following: * It depends NOT on the fact if there is a parameter to get_browser() or not * It happens sometimes when server is very heavy loaded, the homepage of the domain uses the get_browser() function and is the most visited page. So it must be a multithreading issue (NSAPI is a multithreading webserver). And I have an idea: Line 257 uses: zend_hash_apply_with_arguments(&browser_hash, (apply_func_args_t) browser_reg_compare, 2, lookup_browser_name, &found_browser_entry); This is the only function in this context in zend_hash.c which uses the Recursion protection with #define HASH_PROTECT_RECURSION(ht) \ if ((ht)->bApplyProtection) { \ if ((ht)->nApplyCount++ >= 3) { \ zend_error(E_ERROR, "Nesting level too deep - recursive dependency?"); \ } \ } The browser hashtable is a global variable in browscap.c and can be used by more than one call to get_browser() even at the same time. So if one zend_hash_apply_with_arguments() locks the hashtable and a second and third thread tries to do that you will get the error, because (ht)->nApplyCount++ raises and raises... This evening I will try to put a mutex at the beginning of get_browser to prevent more threads running at the same time there. But as I see this, this zend_hash_apply function is used very often could there be other effects if a global variable is a hashtable? Only one question: Is there a special PHP way to use mutexes? I am not familar in Zend programming (I do only SAPI...) ----- Uwe Schindler thetaphi@php.net - http://www.php.net NSAPI SAPI developer Erlangen, Germany