php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #32027 Using concurrent sessions and processes causes Apache to lock up
Submitted: 2005-02-19 15:36 UTC Modified: 2005-02-22 06:15 UTC
From: nickk at att dot net Assigned:
Status: Not a bug Package: Session related
PHP Version: 4.3.10 OS: Windows
Private report: No CVE-ID: None
 [2005-02-19 15:36 UTC] nickk at att dot net
Description:
------------
If you enable sessions on a page that runs any program execution command and do two or more concurrent requests for the page, Apache immediately stops responding and sits doing nothing (using 0% of the CPU) until you close it.

I'm using a clean install of both Apache and PHP for windows; both are using their default configurations. This was tested under Windows 2000 and XP using Apache 1.3.33. The problem seems to be the same under Apache 2.x as well.

There is a workaround for this problem, and that is to call session_write_close before calling any program execution function.

Note: This seems to be a Windows specific problem. This was tested with a *NIX copy of PHP and it worked just fine.

Reproduce code:
---------------
http://www.cs.rit.edu/~ndk4275/multi.php.txt

Expected result:
----------------
When the page loads, click on "Test". It will open two small windows and will wait for 10 seconds before executing the actual test. It might seem like the browser is not responding for the ten seconds before the test, but this is due to the fact that the wait function is a greedy CPU function. When the test starts, the two small browser windows will load the test page with the program execution function at the same time and the main window will reload the current page. At this point, Apache should stop responding. Attempting to make any request to the server will result in an indefinite wait.

Actual result:
--------------
After the test executes, Apache stops responding.

Patches

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2005-02-20 12:15 UTC] derick@php.net
Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. 

Thank you for your interest in PHP.

see also http://php.net/session_write_close
 [2005-02-20 17:07 UTC] nickk at att dot net
Bogus? PHP is running as a module of Apache. If it messes something up, then Apache suffers. If it's not a bug in PHP then how come switching versions of Apache doesn't have any affect on this problem?
 [2005-02-21 19:42 UTC] sniper@php.net
I agree with Derick: This is not a bug. And to solve the locking problem with either multiple frames or windows (same thing actually) is to use session_write_close(), that's what it was added for. This locking propably will happen in *nix 
too, I'd guess that was remote coonection and with windows you do it locally..? So you actually just couldn't simulate the concurrent requests as fast as you can locally.




 [2005-02-22 06:15 UTC] nickk at att dot net
For clarification, this test script was run both locally and remotely. Both had the same results, the server running on Windows locked up when the test was executed. The same script was run on a *NIX system both locally and remotely, and nothing happened. I shouldn't have to close the session before running a process.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Aug 15 08:01:27 2024 UTC