Description:
------------
This simple code crash php.

This is the Debug diagnostic tool output:

In
php__PID__5128__Date__07_01_2009__Time_02_22_25PM__909__Second_Chance_Ex
ception_C0000005.dmp the assembly instruction at
php_mysql!zif_mysql_close+92 in C:\Program Files\PHP\ext\php_mysql.dll
from The PHP Group has caused an access violation exception (0xC0000005)
when trying to read from memory location 0x00000000 on thread 0

Report for
php__PID__5128__Date__07_01_2009__Time_02_22_25PM__909__Second_Chance_Ex
ception_C0000005.dmp
Type of Analysis Performed   Crash Analysis 
Machine Name   PC-UTENTE 
Operating System   Windows Vista Service Pack 1 
Number Of Processors   2 
Process ID   5128 
Process Image   C:\Program Files\PHP\php.exe 
System Up-Time   00:13:11 
Process Up-Time   00:00:02 

Thread 0 - System ID 5132
Entry point   php!mainCRTStartup 
Create time   01/07/2009 14.22.23 
Time spent in user mode   0 Days 0:0:0.31 
Time spent in kernel mode   0 Days 0:0:0.62 

Function     Arg 1     Arg 2     Arg 3   Source 
php_mysql!zif_mysql_close+92     00000000     02a0d350     00000000    
php5ts!zend_do_fcall_common_helper_SPEC+946     00000000     02a40070   
 00052fd0    
php5ts!ZEND_DO_FCALL_SPEC_CONST_HANDLER+130     00c0fbd4     00052fd0   
 00c0fe70    
php5ts!execute+29e     02a40070     00052f00     00000000    
php5ts!zend_execute_scripts+f6     00000008     00052fd0     00000000   

php5ts!php_execute_script+22d     00c0fe70     00052fd0     00000000   

php!main+bf1     00000002     00052f68     00051888    
php!mainCRTStartup+e3     7ffdb000     00c0ffd4     77bee4b6    
kernel32!BaseThreadInitThunk+e     7ffdb000     770bbeaf     00000000   

ntdll!__RtlUserThreadStart+23     00402d78     7ffdb000     00000000   

ntdll!_RtlUserThreadStart+1b     00402d78     7ffdb000     00000000    

PHP_MYSQL!ZIF_MYSQL_CLOSE+92In
php__PID__5128__Date__07_01_2009__Time_02_22_25PM__909__Second_Chance_Ex
ception_C0000005.dmp the assembly instruction at
php_mysql!zif_mysql_close+92 in C:\Program Files\PHP\ext\php_mysql.dll
from The PHP Group has caused an access violation exception (0xC0000005)
when trying to read from memory location 0x00000000 on thread 0

Module Information 
Image Name: C:\Program Files\PHP\ext\php_mysql.dll   Symbol Type:  PDB 
Base address: 0x01c30000   Time Stamp:  Mon Jun 29 22:24:49 2009  
Checksum: 0x00000000   Comments:  Thanks to Zeev Suraski, Zak Greant,
Georg Richter 
COM DLL: False   Company Name:  The PHP Group 
ISAPIExtension: False   File Description:  MySQL 
ISAPIFilter: False   File Version:  5.3.0 
Managed DLL: False   Internal Name:  MYSQL extension 
VB DLL: False   Legal Copyright:  Copyright © 1997-2009 The PHP Group 
Loaded Image Name:  php_mysql.dll   Legal Trademarks:  PHP 
Mapped Image Name:  C:\Program Files\PHP\ext\php_mysql.dll   Original
filename:  php_mysql.dll 
Module name:  php_mysql   Private Build:   
Single Threaded:  False   Product Name:  PHP 
Module Size:  44,00 KBytes   Product Version:  5.3.0 
Symbol File Name: 
C:\Users\utente\Desktop\php-debug-pack-5.3.0-Win32-VC6-x86\php_mysql.pdb
  Special Build:  & 

Reproduce code:
---------------
<?php
sleep(2);
mysql_connect('127.0.0.1', 'root', 'root');
mysql_close();
?>

Thank you for your bug report.

I have a couple of questions regarding your bug report:
1. Is the sleep(2) needed to reproduce the bug?
2. Does the database connection succeed? (i.e. what is the return value
of mysql_connect?)

1) The sleep function is not needed
2) The connection is successfull

An other information: if I save in $a the mysql_connect return value and
pass it to mysql_close php doesn't crash. In othe words this script
works well:
<?
$a=mysql_connect('127.0.0.1', 'root', 'root');
mysql_close($a);
?>

This instead crashes php:
<?
mysql_connect('127.0.0.1', 'root', 'root');
mysql_close();
?>

This one is funny. It may have existed since more than one year now and
nobody has ever found it.

Really a great one.

The bug exists since 21-07-2008. That is 11 months and 1 week ago.
Sometimes I which users would try non-GA versions just in case test
suites don't catch issues...

This is when the bug was introduced:
http://cvs.php.net/viewvc.cgi/php-src/ext/mysql/php_mysql.c?r1=1.213.2.6
.2.16.2.22&r2=1.213.2.6.2.16.2.23&

mysql_link points to NULL and that's causing a crash. 

Possible workaround (as suggested by Johannes):

nixnutz@linux-en61:~/src/login/php5> cvs diff ext/mysql/tests/
cvs diff: Diffing .
cvs diff: Diffing ext
cvs diff: Diffing ext/mysql
cvs diff: Diffing ext/mysql/tests
nixnutz@linux-en61:~/src/login/php5> cvs diff ext/mysql/
cvs diff: Diffing ext/mysql
Index: ext/mysql/php_mysql.c
===================================================================
RCS file: /repository/php-src/ext/mysql/php_mysql.c,v
retrieving revision 1.213.2.6.2.16.2.37
diff -r1.213.2.6.2.16.2.37 php_mysql.c
372a373,376
> #ifdef MYSQL_USE_MYSQLND
>       mysqlnd_end_psession(link->conn);
> #endif
>
987,995c991
< #ifdef MYSQL_USE_MYSQLND
<       {
<               int tmp;
<               if ((mysql = zend_list_find(Z_RESVAL_P(mysql_link),
&tmp)) && tmp == le_plink) {
<                       mysqlnd_end_psession(mysql->conn);
<               }
<       }
< #endif
<       if (mysql_link) { /* explicit resource number */
---
>       if (mysql_link) {
cvs diff: Diffing ext/mysql/tests

Someone may want to review that.

Description:
------
I can confirm this, I'm having the same issue with php 5.3 and apache2
when calling mysql_close without a mysql_link as parameter.

Reproduce code: 
------
<?php

mysql_connect('localhost','root','password');
mysql_close(); // win32 uncaught exception catched by MSVS

?>

Workaround/not crashing:
------
<?php
$link = mysql_connect('localhost','root','password');
mysql_close($link);
?>

Exception :
------
Not handled Exception in 0x006e2072 in httpd.exe: 0xC0000005:
Access violation when reading location 0x00000000.

Note : The Exception has been translated so it is not literal

my development evioronment is 
   windows xp sp2
   apache 2.2
   php 5.3.0
   mysql 5.1.36

I write some code in test.php
<?php
   $conn = mysql_connect('ip','user','password');
   mysql_close();
?>
then ,I Will be catched a error by apache 2.2,it is:
"...
0x006e2072 in httpd.exe: 0xC0000005:
Access violation when reading location 0x00000000.
..."

but when check the mysql_close function like this for test.php
<?php
   $conn = mysql_connect('ip','user','password');
   mysql_close($conn);
?>
it will work no any error.
so ,i want to know its reason of the mysql_close(),please mail to me
Thanks!

Still in the release, I really think lot's of people are having the same

problem with their sctripts!!

I filled a bug report hours ago to later accidentally find that it was a

very simple problem. Once I found the problem I looked for mysql_close 
and version 5.3 to find this bug report.

Uff finnally after the whole day!!!

Regards,

Guillermo

I get this as well. I had avoided upgrading my ancient PHP code (some of
it was from PHP4); turns out it being that ancient also means it uses
old patterns, like not using handles. :)

Likely that newer code will not encounter this, so it'll be folks
upgrading slowly and cautiously.

WinXP SP3, PHP 5.3.0 VC9 TS, Apache 2.2.13 (apachelounge) + mod_fcgid
2.2b, MySQL 5.1.37 == same bug (php-cgi.exe crash)

/*
* php-cgi.exe OK
*/
$a=mysql_connect('127.0.0.1:3306', 'root', 'fdgdfgd'));
mysql_close($a);

/*
* php-cgi.exe CRASH
*/
mysql_connect('127.0.0.1:3306', 'root', 'fdgdfgd'));
mysql_close();

repro on 5.3.0 on Win2003 using php.exe in command shell.  didn't have
this problem with 5.2.10

Automatic comment from SVN on behalf of andrey
Revision: http://svn.php.net/viewvc/?view=revision&revision=288436
Log: Fix for bug#48754 mysql_close() crash php when no handle specified

Automatic comment from SVN on behalf of andrey
Revision: http://svn.php.net/viewvc/?view=revision&revision=288437
Log: MFH:Fix for bug#48754 mysql_close() crash php when no handle
specified

This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.

Fix should be part of 5.3.1