#41350 [Com]: Error in my_thread_global_end()
ID: 41350 Comment by: brandonkahre at charter dot net Reported By: graham at directhostinguk dot com Status: No Feedback Bug Type: MySQL related Operating System: Windows 2003 PHP Version: 5.2.3 New Comment: I am still experiencing this bug as of Feb-20-2008. I am running PHP 5.2.4 in a Windows XP environment with MySQL 4.2.20. To leave no room for confusion, the problems and steps I am using to recreate this bug are described in Bug #44009 (http://bugs.php.net/bug.php?id=44009). I have tried the following PHP versions: PHP 5.2.4 PHP 5.2.5 PHP 5.2.6-latest I have tried patching the Windows php_mysql.dll extension using the following sources: PHP 5.2.1: http://www.php.net/releases/#5.2.1 [copy /ext/php_mysql.dll only] - this did not fix any problems MySQL: http://dev.mysql.com/downloads/connector/php/ [mysql extension (PHP 5.2.0) for MySQL Server 4.1.21] - could not connect to MySQL server. Please note that the extension is for PHP 5.1.6.6 MySQL: http://dev.mysql.com/downloads/connector/php/ [mysql extension (PHP 5.2.0) for MySQL Server 5.0.27] - this did not fix any problems IT-Guys (mentioned in this bug tracker): http://www.it-etc.com/2007/10/25/php-error-524-getting-error-error-in-my_thread_global_end-1-threads-didnt-exit/ - this did not fix any problems. The extensions provided seem to be for PHP 5.2.0.0 Previous Comments: [2008-02-13 17:25:20] byerly0503 at gmail dot com This bug caused me to spend an hour on the issue. I kept ignoring all of the help related to MySQL since the script I was trying to run, didn't use MySQL. Please fix this by including the right DLL or adjust the installer to give a warning message: "Despite downloading this package, you will need to download an older package, replace the mysql dll, in order to use PHP." [2008-02-08 06:56:04] OPunWide at hotmail dot com I'm a newbie at this, and am installing php for the first time. Very basic setup, running WinXP, using IIS 5.1 and PHP 5.2.5, installed using the Windows installer. When I first installed I included support for MySQL in the options, but had not installed MySQL. The error happened with a psp script consisting only of pspinfo(). I went back to the installer and removed support for MySQL and the problem went away. I don't think the folks at MySQL can be blamed for this one. [2008-02-07 22:27:08] WS6TA at txlanes dot com I have to agree about the impression this makes on potential LAMP adopters. I am a long-time Windows/MSSQL person looking at the LAMP stack as an alternative to MS. However, I download PHP 5.2.5 and start reading the manual only to get the error "Error in my_thread_global_end()" the first time I used the CLI. So, I go searching and find all kinds of references to dll swaps for PHP side AND the MySQL side. I don't even have MySQL installed yet... I was looking at PHP's ability to be a standalone scripting tool as well as a web-database tool. Anyway, I then find this thread where it appears the bug has been around since approximately May 2007 and PHP version 5.2.3. I commented out "extension=php_mysql.dll" in the php.ini to stop the error, but I think I will want this extension once I install MySQL. My hat's off to the people that started and have contributed to the PHP codebase. Please understand that I am not trying to bash anyone. I simply want to reiterate the PHP is crucial component to the LAMP stack and having to search for a bug fix on the very first run discourages potential new adopters. I'm very impressed with what I know about PHP thus far and would hate to think a potential adopter could be discouraged at square one in their evaluation. [2008-01-22 20:30:48] codeslinger at compsalot dot com Ping, Can we get php updated please? This problem is now one year old. Everyone who updates to the latest Windows php = 5.2.5 encounters this bug, it results in total breakage of loading the mysql dll. This bug has cost thousands upon thousands of man-hours to be expended/wasted by site admins in trying to locate the cause of the problem and the fix for it. In some cases it has also caused people to abandon the use of php-mysql programs altogether. According to MySQL Bug: http://bugs.mysql.com/bug.php?id=25621 The final resolution is that the problem was with mysql not php and that the problem was fixed awhile ago, and that all that is needed is for php to update to the latest mysql library. Given the fundamental importance of the php mysql interface, as in LAMP, it is inexplicable that it has taken an ent
#44009 [Fbk->Csd]: fopen hangs with recent upgrade
ID: 44009 User updated by: brandonkahre at charter dot net Reported By: brandonkahre at charter dot net -Status: Feedback +Status: Closed Bug Type: HTTP related Operating System: Windows PHP Version: 5.2.5 New Comment: You are, of course, correct. It looks like this has been a long outstanding bug. After digging through a very long (and seemingly unresolved) bug ticket, I was able to use the mysql and mysqli extensions from PHP 5.1.2 with the 5.2.X branch and have no problems. I will mark this ticket resolved since it overlaps bug #41350. http://bugs.php.net/bug.php?id=41350 Previous Comments: [2008-02-14 22:54:12] [EMAIL PROTECTED] Let me guess: there's an error in some log with this in it 'my_thread_global_end' ?? (Try search for that in the bug db too..) [2008-02-14 18:26:58] brandonkahre at charter dot net A correction to the post above: It is not the "extension_dir" directive causing problems, but actually the extensions themselves. If I change the directive to what was listed initially, but disable all of the extensions, the scripts execute quickly. However, once a single extension is loaded (eg. php_mysql.dll or php_mysqli.dll), the script hangs as stated previously. ---- [2008-02-14 18:09:59] brandonkahre at charter dot net Thank you for the response. I have upgraded my server using the latest PHP build and I have found that the test script above runs quickly, but only when using the recommended-ini configuration. I have compared my existing configuration to the recommended configuration and I have found that the problem lies with the "extension_dir" directive. My existing configuration (experiencing the bug) uses: extension_dir = "C:\Program Files\PHP\ext" The recommended configuration uses: extension_dir = "./" Prior to PHP 5.2.X (tested with 5.1.2), I did not experience this bug, but making this simple change to PHP 5.2.X fixes the bug. [2008-02-13 18:30:16] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi ---------------- [2008-02-01 00:34:53] brandonkahre at charter dot net Description: When opening a file using fopen and a network wrapper (HTTP), the page will lag before finishing. The response from fopen is fast (determined by echo'ing the return, and any code that is to be processed after the fopen function is processed without delay. It is only when the page is ready to finish loading that the lag becomes noticeable. The lag takes 3-6 seconds and does not seem to be affected by any timeout settings in the php.ini file. This problem does not exist in PHP 5.1.2, and started immediately after upgrading to PHP 5.2.4 and 5.2.5. This problem also seems to only exist on my Windows server. Reproduce code: --- http://www.google.com";)); ?> -- Edit this bug report at http://bugs.php.net/?id=44009&edit=1
#44009 [Csd->Opn]: fopen hangs with recent upgrade
ID: 44009 User updated by: brandonkahre at charter dot net Reported By: brandonkahre at charter dot net -Status: Closed +Status: Open Bug Type: HTTP related Operating System: Windows PHP Version: 5.2.5 New Comment: A correction to the post above: It is not the "extension_dir" directive causing problems, but actually the extensions themselves. If I change the directive to what was listed initially, but disable all of the extensions, the scripts execute quickly. However, once a single extension is loaded (eg. php_mysql.dll or php_mysqli.dll), the script hangs as stated previously. Previous Comments: [2008-02-14 18:09:59] brandonkahre at charter dot net Thank you for the response. I have upgraded my server using the latest PHP build and I have found that the test script above runs quickly, but only when using the recommended-ini configuration. I have compared my existing configuration to the recommended configuration and I have found that the problem lies with the "extension_dir" directive. My existing configuration (experiencing the bug) uses: extension_dir = "C:\Program Files\PHP\ext" The recommended configuration uses: extension_dir = "./" Prior to PHP 5.2.X (tested with 5.1.2), I did not experience this bug, but making this simple change to PHP 5.2.X fixes the bug. [2008-02-13 18:30:16] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi ---- [2008-02-01 00:34:53] brandonkahre at charter dot net Description: When opening a file using fopen and a network wrapper (HTTP), the page will lag before finishing. The response from fopen is fast (determined by echo'ing the return, and any code that is to be processed after the fopen function is processed without delay. It is only when the page is ready to finish loading that the lag becomes noticeable. The lag takes 3-6 seconds and does not seem to be affected by any timeout settings in the php.ini file. This problem does not exist in PHP 5.1.2, and started immediately after upgrading to PHP 5.2.4 and 5.2.5. This problem also seems to only exist on my Windows server. Reproduce code: --- http://www.google.com";)); ?> -- Edit this bug report at http://bugs.php.net/?id=44009&edit=1
#44009 [Fbk->Csd]: fopen hangs with recent upgrade
ID: 44009 User updated by: brandonkahre at charter dot net Reported By: brandonkahre at charter dot net -Status: Feedback +Status: Closed Bug Type: HTTP related Operating System: Windows PHP Version: 5.2.5 New Comment: Thank you for the response. I have upgraded my server using the latest PHP build and I have found that the test script above runs quickly, but only when using the recommended-ini configuration. I have compared my existing configuration to the recommended configuration and I have found that the problem lies with the "extension_dir" directive. My existing configuration (experiencing the bug) uses: extension_dir = "C:\Program Files\PHP\ext" The recommended configuration uses: extension_dir = "./" Prior to PHP 5.2.X (tested with 5.1.2), I did not experience this bug, but making this simple change to PHP 5.2.X fixes the bug. Previous Comments: [2008-02-13 18:30:16] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi ---- [2008-02-01 00:34:53] brandonkahre at charter dot net Description: When opening a file using fopen and a network wrapper (HTTP), the page will lag before finishing. The response from fopen is fast (determined by echo'ing the return, and any code that is to be processed after the fopen function is processed without delay. It is only when the page is ready to finish loading that the lag becomes noticeable. The lag takes 3-6 seconds and does not seem to be affected by any timeout settings in the php.ini file. This problem does not exist in PHP 5.1.2, and started immediately after upgrading to PHP 5.2.4 and 5.2.5. This problem also seems to only exist on my Windows server. Reproduce code: --- http://www.google.com";)); ?> -- Edit this bug report at http://bugs.php.net/?id=44009&edit=1
#44009 [NEW]: fopen hangs with recent upgrade
From: brandonkahre at charter dot net Operating system: Windows PHP version: 5.2.5 PHP Bug Type: HTTP related Bug description: fopen hangs with recent upgrade Description: When opening a file using fopen and a network wrapper (HTTP), the page will lag before finishing. The response from fopen is fast (determined by echo'ing the return, and any code that is to be processed after the fopen function is processed without delay. It is only when the page is ready to finish loading that the lag becomes noticeable. The lag takes 3-6 seconds and does not seem to be affected by any timeout settings in the php.ini file. This problem does not exist in PHP 5.1.2, and started immediately after upgrading to PHP 5.2.4 and 5.2.5. This problem also seems to only exist on my Windows server. Reproduce code: --- http://www.google.com";)); ?> -- Edit bug report at http://bugs.php.net/?id=44009&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=44009&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44009&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44009&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44009&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44009&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44009&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44009&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44009&r=needscript Try newer version:http://bugs.php.net/fix.php?id=44009&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44009&r=support Expected behavior:http://bugs.php.net/fix.php?id=44009&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44009&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44009&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44009&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=44009&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=44009&r=dst IIS Stability:http://bugs.php.net/fix.php?id=44009&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44009&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44009&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44009&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44009&r=mysqlcfg
