Thanks for the report.

Do you retrieve your password from any dynamic way or is it static?

As I said, seems like password retrieval makes no difference. I have connectdb() function which look like this:
function connectdb() {
        global $mysql_host, $mysql_user, $mysql_pass, $dbid;
       	$dbid = mysql_connect( $mysql_host, $mysql_user, $mysql_pass);
        if(!$dbid) {
        $file = fopen("/tmp/mysql-err", "a+");
        $line  = $_SERVER['PHP_SELF'] . ":" . date("Y-m-d H:i:s");
        $line .= ":$mysql_host:$mysql_user:$mysql_pass - $dbid:" . mysql_error() . "\n";
	fputs($file, $line);
	fclose($file);
        }
        return $dbid;
}

and here is what gets logged into /tmp/mysql-err:
/index.php:2003-05-05 14:30:53:db1.m-1.lan:public:secret - :Access denied for user: 'public@10.10.12.254' (Using password: NO)

so function retrieves the password fine.

What makes you think it's PHP bug, and not bug in the 
fairly new Mysql4 ?? Did this happen with Mysql 3.23.xx ?

Are you using the bundled mysql library or did you compile 
PHP with the mysql4 client library? Check your phpinfo() 
output for mysql section for the API version.

Does this happen with CLI or with some server module?

here is snip from phpinfo() about mysql:
MySQL Support enabled 
Active Persistent Links  0  
Active Links  0  
Client API version  4.0.12  
MYSQL_MODULE_TYPE  external  
MYSQL_SOCKET  /tmp/mysql.sock  
MYSQL_INCLUDE  -I/usr/local/include/mysql  
MYSQL_LIBS  -L/usr/local/lib/mysql -lmysqlclient  

mysql servers lives not in the same place webserver does. earlier php was compiled with 3.23.55 client library, then I decided to compile it with 4.0.12. it didn't make sense. I'm not sure it's PHP bug natively, but I'm mainly curious about why it "fails to use password" ?

one more thing to say - these systems are loaded enough, i.e. mysqladmin reports 15.968 queries per second, so I said before, it's hard to repeat this error in, to say, normal conditions.

Under what webserver are you getting this?
Does it make any difference if you use the bundled mysql library instead? (don't pass any path to --with-mysql)

And did the 'earlier php version (?)' have this problem when it was using the 3.23.55 mysql??

thanks for the comments. we are using Apache/1.3.27. actually, I can't asure that this problem was with earlier versions of PHP, i.e. < 4.3.1, because only from version 4.3.0 I started to write every warning/error to the file. 

I will try to find time to recompile php with bundled version of mysql, because I can't do this during the peak hours. Futhermore, I'm building php from FreeBSD mod_php4's port and "by default" it tries to find installed mysql-client.  

One more thing which needs to be mentioned - this issue occurs in "web portals" which are build from different files, i.e. using include/require functions. 

I'm still concerned about the error of not using password (Using password: NO), because AFAIK this error is being produced by mysql library as well as the whole possible mysql_error() output. maybe this error could mean something different?

Today I recompiled PHP with bundled mysql library as you recommended but the problem still persists:
[08-May-2003 16:09:48] PHP Warning:  mysql_connect() [<a href='http://www.php.net/function.mysql-connect'>function.mysql-connect</a>]: Access denied for user: 'public@10.10.12.254' (Using password: NO) in /my/web/space/lib/mysql.php on line 10

here is info from "my error log":
/index.php:2003-05-08 16:09:48:db1.m-1.lan:public:secret - :Access denied for user: 'public@10.10.12.254' (Using password: NO)

here "public" is the username and "secret" is the password.

current phpinfo() about mysql:
Active Persistent Links  0  
Active Links  0  
Client API version  3.23.49  
MYSQL_MODULE_TYPE  builtin  
MYSQL_SOCKET  /tmp/mysql.sock  
MYSQL_INCLUDE  no value  
MYSQL_LIBS  no value

one more thing I've figured out:

372 Connect     Access denied for user: 'public@10.10.12.254' (Using password: YES)
373 Connect     public@10.10.12.254 on

these are lines from mysql.log on the same time when php reported:

[08-May-2003 16:53:28] PHP Warning:  mysql_connect() [<a href='http://www.php.net/function.mysql-connect'>functi
on.mysql-connect</a>]: Access denied for user: 'public@10.10.12.254' (Using password: NO) in /my/web/place/edit/config-global.php on line 232

Sorry for this long story. I just realized that it's mysql bug itself:

<menulis@sala: menulis>$ while true; do mysql -hdb1 -upublic -psecret -e'quit'; done
ERROR 1045: Access denied for user: 'public@10.10.12.254' (Using password: NO)
ERROR 1045: Access denied for user: 'public@10.10.12.254' (Using password: NO)
ERROR 1045: Access denied for user: 'public@10.10.12.254' (Using password: NO)
ERROR 1045: Access denied for user: 'public@10.10.12.254' (Using password: NO)
ERROR 1045: Access denied for user: 'public@10.10.12.254' (Using password: NO)
ERROR 1045: Access denied for user: 'public@10.10.12.254' (Using password: NO)
ERROR 1045: Access denied for user: 'public@10.10.12.254' (Using password: NO)
ERROR 1045: Access denied for user: 'public@10.10.12.254' (Using password: NO)

these errors appear occasionaly, each after 10-20 seconds. 

thank you guys anyway, I will try to report it to MySQL.

Not a PHP bug then.

I have the same situation. But i use 3.23.56 mysql and 'mysql -p<blah-blah-blah>' command works perfectly. Also... I get this bug after upgrading from 4.3.2 to 4.3.3RC1 version. So i think this is a PHP bug.

Thanks for comment, nefer. I still think that this bug is *more* related with MySQL, if you're intersted, here is my report's thread: http://bugs.mysql.com/?id=398
This bug is becoming a bottleneck for me, so your help in debugging mysql and php itself would be *very* appreciate.

Maybe. But i get it after upgrade from 4.3.2 to 4.3.3RC1... Alse when i'm downgrade to 4.3.2 all works fine! MySQL stay untouched... Maybe this is a sly bug in MySQL, but i like principe of Okkam blade.

I would like to announce that this issue has been solved recompiling MySQL (4.0.13) together with LinuxThreads. Futhermore, this alteration has raised another problem - wait_timeout parameter is weakless (tried setting both in configuration file and manually using SET GLOBAL wait_timeout).