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