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

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

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?

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

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?

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

What if you name that test.php to test.html..?

I renamed test.php to test.html, and the same problem occurs.

-Ian

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip

I tried both php4-win32-STABLE-200309250030 and php5-win32-200309242230.
Both still accuratly produce the same bug.

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

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

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.

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.

I had experienced the same issue, php4&5, winXP, apache2. Workaround is
fixing the problem.

Thanks,
Andi

The workaround has shown to be effective in eliminating this issue.
Closing the bug.

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.

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

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

forget my last entry.. the servers are behind loadbalancers in a NAT
network.. duh :)

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?

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