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