php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #22526 session_start/popen hang
Submitted: 2003-03-03 17:55 UTC Modified: 2004-03-05 02:34 UTC
Votes:122
Avg. Score:4.8 ± 0.6
Reproduced:108 of 108 (100.0%)
Same Version:89 (82.4%)
Same OS:97 (89.8%)
From: iberry at raxnet dot net Assigned:
Status: Closed Package: Session related
PHP Version: 4CVS, 5CVS OS: Windows 2000
Private report: No CVE-ID: None
 [2003-03-03 17:55 UTC] iberry at raxnet dot net
I think I have found some sort of race-like condition using session_start() and popen() functions, causing the web server to hang. The bug only seems to manifest when repeatedly initiating a page that requires session_start() and uses popen(). This is relevant for me because this page renders graphs and needs both of these functions to perform its job. Here is some example code to re-produce the problem:

----test.php----
<img src="img.php?rra_id=1">
<img src="img.php?rra_id=2">
<img src="img.php?rra_id=3">
<img src="img.php?rra_id=4">
----end----

----img.php----
<?php
session_start();

$fp = popen('test', "r");
print fpassthru($fp);
pclose($fp);
?>
----end----

Notice how I am passing different GET variables to each image page session, this seems to be necessary for the bug to manifest. This code has been tested on both IIS 5 and Apache 2.0.44 with the same results

The path I give popen() does not appear to make a difference. I have also have tried the popen 'r' and 'rb' file modes, which made no difference. The two triggers of this bug appear to be the combined use of session_start()/popen() and the varying GET variable values.

Thanks for taking time to look into this.

-Ian

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-03-04 15:46 UTC] iberry at raxnet dot net
I tried the latest CVS version with the same negative results. I then tried to duplicate the bug using the CGI/CLI binary with no luck (could not produce the sufficent code). After this however, I switched Apache from SAPI to CGI and the problem went away.

So for now, we can assume that the problem is related to PHP's SAPI support.

Were you able to reproduce this under a SAPI environment?

-Ian
 [2003-03-05 13:49 UTC] iliaa@php.net
Both of the SAPI's you've tried (IIS & Apache 2) are thread based, it is possible that this problem is specific to multi-threaded application, and that's why single-threaded SAPIs like CLI/CGI are not affected by it.
Could you try and see if the problem can be replicated using Apache 1.X?
 [2003-03-06 00:30 UTC] iberry at raxnet dot net
I tried Apache 1.3.27 with PHP's php4apache.dll and got the same negative results. The code I originally posted still causes the hang with this configuration.

-Ian
 [2003-03-06 12:51 UTC] sniper@php.net
Are you sure this isn't same as what we've verified in bug #22154 ?

Do you have session.use_trans_sid = 1 in your php.ini?

 [2003-03-06 21:42 UTC] iberry at raxnet dot net
I checked and 'session.use_trans_sid' was set to '0', so I changed it to '1', but got the same results.

I took a look at the bug you referenced to, but it is not the same. For one the file size is not really an issue. And secondly after adding debug code, I can see that PHP is blocking on the popen() call, not fpassthru().

-Ian
 [2003-03-07 02:14 UTC] sniper@php.net
What if you name that test.php to test.html..?

 [2003-03-12 17:05 UTC] iberry at raxnet dot net
I renamed test.php to test.html, and the same problem occurs.

-Ian
 [2003-09-24 21:35 UTC] iberry at raxnet dot net
I tried both php4-win32-STABLE-200309250030 and php5-win32-200309242230. Both still accuratly produce the same bug.
 [2003-11-30 21:58 UTC] php_bug at cklowe dot com
It would appear that this bug also afflicts exec().  

It seems the the function php_session_start hangs at some point within the function.

php_session_start only hangs after popen_ex has finished in the first thread.  I don't yet know if the status of the handle returned by popen_ex makes a difference.  (pclose makes a difference)

It appears not to occur in the debug_ts version, only release_ts.  I could not recreate the bug using iframes, but img (as described above) does the trick
 [2004-01-10 03:01 UTC] riskisadventure at yahoo dot com
I am having the simillar problem but with FreeBSD 4.7
All the page with session_strat() hang, if the one of the page with session_start() start hangging
 [2004-02-02 10:59 UTC] php_bug at cklowe dot com
Workaround:  use session_write_close() before the exec.  

You can use session_start() after the call if you still need to write session values.  Reading doesn't require an open session.

I've tested this somewhat, so please post how you get on.
 [2004-02-02 16:36 UTC] iberry at raxnet dot net
My initial tests show that the workaround is doing the trick! I will send out a message to have more users test this and report back. Thanks for pointing this out.
 [2004-02-23 10:46 UTC] cpuidle at gmx dot de
I had experienced the same issue, php4&5, winXP, apache2. Workaround is fixing the problem.

Thanks,
Andi
 [2004-03-05 02:34 UTC] iberry at raxnet dot net
The workaround has shown to be effective in eliminating this issue. Closing the bug.
 [2004-07-06 21:41 UTC] kalvinb602 at hotmail dot com
Just posting to suggest that it would be nice to have this workaround posted in the manual for popen and other system command issuing functions.  I resorted to blanking out the page to keep users from clicking a second link before the first finished loading to avoid a server hang.

This workaround eliminates the need for that very clunky "fix" but it took me quite awhile to find it because I was digging through the manual.  It might be a good idea to link the manual entries to the related bug reports.

I'm using Apache 2.0.49 PHP 4.3.6 (upgrading soon) and Windows 2000 Pro.
 [2004-08-19 17:25 UTC] pubnelle at megaphone dot ch
Hi,
I have written already about apache hanging, in bug number 28856.
I think that the problem is not only session related, and that it appeared after PHP 4.3.2.
You may not agree with the fact that including, requiring or "virtual"ing pages that are on the same server need to be included using the full http domain name. But there, we do it a lot, and it's working very well on our old servers, with php 4.3.2.
Here is a very simple example where the server is hanging.

file1.php :
<?
include("http://thisdomain.com/file2.php");
?>
file2.php :
<?
//anything, for example 
phpinfo();
?>

On a Debian Box, PHP Version 5.0.1-dotdeb, Apache/1.3.26, the server is hanging .

No session started, session.auto_start set to Off.

I agree that this is a stupid example and that here I would use simply include("file2.php"); believe me the situations where we use the include("http ...) are a lot more complex and we cannot avoid to do this.
Please, don't answer that nobody uses the include, or require, or anthing, with the http to be able to use some Apache Vhost related features : we do a lot, and I am in a despair, here ...  

Thanks for your attention,

        Estelle
 [2004-08-19 18:56 UTC] jaccoh at infogateway dot org
pubnelle is right.

I tried this:

----file1.php----
<?
include("http://www.infogateway.org/file2.php?foo=test");
?>
----end----

----file2.php----
<?
echo $_GET['foo'];
?>
----end----

And it crashes! Don't go tell us it is not a bug or problem,  the php manual says it should work:

----
If "URL fopen wrappers" are enabled in PHP (which they are in the default configuration), you can specify the file to be included using a URL (via HTTP or other supported wrapper - see Appendix L for a list of protocols) instead of a local pathname. If the target server interprets the target file as PHP code, variables may be passed to the included file using a URL request string as used with HTTP GET. This is not strictly speaking the same thing as including the file and having it inherit the parent file's variable scope; the script is actually being run on the remote server and the result is then being included into the local script.
----

-Jacco
 [2004-08-19 20:25 UTC] jaccoh at infogateway dot org
forget my last entry.. the servers are behind loadbalancers in a NAT network.. duh :)
 [2004-09-19 16:16 UTC] jules at acris dot co dot uk
I've experience what appears to be the same bug when using file("http://blah") to retrieve the contents of a particular URL.  The workaround suggested does do the job.  FWIW, I'm on Linux, not Win2K, using Apache 1.x SAPI.

Has this bug been fixed properly (i.e., not just the workaround suggested)?  And if so, in which release?
 [2004-10-08 16:21 UTC] cpuidle at gmx dot de
This bug is marked closed- is it fixed in any version? The issue is quite ugly and not every user should be forced to find out the is a workaround...

Thanks,
Andi
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Mar 28 12:01:27 2024 UTC