Description:
------------
The current working directory seems to set to random values  under
certain circumstances. e.g. getcwd() returns inconsistent values (as
shown in the sample code) and attempts to reference files by relative
paths work intermittently or not at all (which is how I discovered this
bug..). 

Other variations on this code (eg calling getcwd() from an ob_start()
callback) appear to give similar results.

The code works fine from the command line (ie produces the expected
result).

I've configured PHP with the following, and still been able to reproduce
the result:
./configure --prefix=/usr/local/packages/php-4.3.2
--with-apxs=/usr/local/packages/apache-1.3.27/bin/apxs

I've also reproduced this problem on a Solaris box, also running Apache
1.3.27.

Reproduce code:
---------------
<?PHP
print "current time is '".strftime("%D %T")."'<br>\n";
print "(in main) cwd is '".getcwd()."'<br>\n";
register_shutdown_function("atexit");

function atexit()
{
    print "(in callback) cwd is '".getcwd()."'<br>\n";
}
?>

Expected result:
----------------
Something like:
current time is '06/30/03 18:39:24'
(in main) cwd is '/home/steveb/public_html/callbacktest'
(in callback) cwd is '/home/steveb/public_html/callbacktest'

Actual result:
--------------
actual results vary, here's two. All I did in between them was press
'reload'...

output 1:
---------
current time is '06/30/03 18:59:24'
(in main) cwd is '/home/steveb/public_html/callbacktest'
(in callback) cwd is '/home/www/vhosts/nutter.spoo.org/htdocs'

output 2:
---------
current time is '06/30/03 18:59:34'
(in main) cwd is '/home/steveb/public_html/callbacktest'
(in callback) cwd is '/home/steveb/public_html'

The values returned by getcwd() appear to be related to previous pages
that have been served by apache (not necessarily ones that have been
processed by PHP).

I think I'm experiencing this or a related bug:

I've a page that most of the time works fine, but about 10% of the time,
the require() statement at the top doesn't find the file, which is in
the same directory as the script and referenced with a simple relative
path -- require('filename.inc')

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

Tested this against the latest snapshot (200308190730, which describes
itself as 4.3.3RC5-dev) it's still behaving as I described.

I can not reproduce this. Do you possibly have some php ini-settings set
in your virtualhosts/some .htaccess file?
(using php_value or php_admin_value)

I did have some stuff in php.ini, but removing the file has made no
difference (it was only stuff like "max_execution_time = 5" anyway...)

I don't see how this can fail to work for you, it's clear from the code
that this will happen - php_execute_script() does something like:
    old_cwd=getcwd();
    chdir(DIR_OF_SCRIPT);
    EXECUTE_SCRIPT
    chdir(old_cwd);
but all the shutdown functions are called outside of this (from
php_request_shutdown()).

Maybe it should be up to the SAPI module to do the chdir() stuff - some
SAPI modules might not care (I'd guess that apache wouldn't care) in
which case there might be a (tiny) performance gain in not doing
chdir(old_cwd) at the end of a request...

I didn't ask about your php.ini, I asked about any possible php settings
in your httpd.conf / .htaccess files..

This is on a minimal apache/PHP installation that I've set up
specifically to reproduce this problem.

There are no .htaccess files in the path to my test script.

The only PHP-related entries in httpd.conf are:
   LoadModule php4_module libexec/libphp4.so
   DirectoryIndex index.html index.php
   AddType application/x-httpd-php .php
   AddType application/x-httpd-php-source .phps

What other apache modules do you have enabled?
Have you tried this with some default config?
(sidenote: What linux / gcc / glibc versions do you have..?)

This is on a minimal apache/PHP installation that I've set up
specifically to reproduce this problem. Apache is configured as:
./configure --prefix=/usr/local/packages/apache-1.3.27
--enable-module=so

Linux kernel is 2.4.20-ac2
gcc version is 2.96
glibc is 2.2.4

I've successfully reproduced this problem on a Solaris 7 system (gcc
version is 2.96) and on a Solaris 9 system (gcc version is 3.2.2). I
don't see how it can be dependent on compiler version or platform...

Well, there is something fishy going on what you do since I'm still
unable to reproduce this..and btw. The gcc 2.96 is bogus:
http://gcc.gnu.org/gcc-2.96.html

Also, if you were using default configuration of apache, you wouldn't
have any virtualhosts..

Yes, I know 2.96 is bogus - it's a RedHat7 box. The problem also occurs
when compiled with GCC3.2.2 on a Solaris system, so I don't really think
it's relevant.

I don't have any vhosts on this install of apache - I normally use
--enable-module=vhost_alias but it's disabled on this install.
httpd.conf contains:
  DocumentRoot "/home/www/nutter.spoo.org/htdocs"

If you're unable to reproduce this there must be *something* different
between your system and mine - what are you testing this on?

current time is '08/20/03 08:26:09'
(in main) cwd is '/home/elmicha/public_html/php'
(in callback) cwd is '/'

In the callback it's always '/'.

I'm still running 4.3.3RC3 though (will try tonight with a current
snapshot and pristine php.ini). Linux 2.4.21, gcc-2.95.3, libc-2.1.3,
Apache-1.3.28, no vhosts.

I also see "(in callback) cwd is '/'" (no random values) on Solaris with
PHP-4.2.1/Apache-1.3.26, so this doesn't seem to be a recent
regression.

And the expected return value is '/' when run under Apache.
(It's apache thing..)

Nothing was verified here, just was proved that this is one of those
ghost bugs..

Please check your systems, there is something in common to them how you
configure/compile/etc.

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.

reproduced in 5.2.8 and 5.2.6, iis 6, windows, official build
#  PHP 5.2.8 installer [17,662Kb] - 08 December 2008
md5: 159def484800411060a9eacccafd2253 

reproduced with *.php in document_root but not in sub directories

file: C:\web\example.com\phpinfo.php
<?php
echo (dirname(__FILE__));
chdir(dirname(__FILE__));
chdir($_SERVER['DOCUMENT_ROOT']);
echo getcwd();
phpinfo();
?>

C:\web\example.com
Warning: chdir() [function.chdir]: No error (errno 0) in
C:\web\example.com\phpinfo.php on line 3

Warning: chdir() [function.chdir]: No error (errno 0) in
C:\web\example.com\phpinfo.php on line 4
C:\web\example.com\a

chdir() failed and getcwd() is the cwd of last success php request which
was C:\web\example.com\a\phpinfo.php

btw, it's not random, and there's no other php requests to the server. i
can reproduce it consistently

everytime a *.php got requested, getcwd "was" the old one and php gonna
chdir() to the dirname(__FILE__) before the file is executed, but chdir
to document root failed due to some reason i dunno. so getcwd() returns
the value from previous request (in the same thread?)

i cannot trace it with filemon.exe because in php threadsafe version
it's a "Virtual Directory Support". directory permission is not a
problem