Description:
------------
Using a persistent connection with PDO (mysql tested) and then executing
a query with an unknown column will crash PHP 5.1.1, and take Apache
with it.

This has been reproduced on two seperate systems here at the office
already.  Both systems use Apache 2.0.54 as a module, with PHP 5.1.1

Reproduce code:
---------------
<?php 
$pdo = new PDO('mysql:host=HOST;dbname=mysql',
       USER, PASSWORD, array(PDO::ATTR_PERSISTENT => TRUE));
$pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_WARNING);
$pdo->query('SELECT frank FROM mysql.user LIMIT 20');
?>

Expected result:
----------------
Expect a warning, such as Warning: PDO::query() [function.query]:
SQLSTATE[42S22]: Column not found: 1054 Unknown column 'frank' in 'field
list' in C:\Documents and Settings\Tim\workspace\hxpa SVN\temp.php on
line 5

Actual result:
--------------
PHP (Apache is reported) crashes.

And what MySQL version?

Oops, sorry about that, it's MySQL 5.0.15

Georg, this seems to be the same issue caused by protocol binary
incompatibility.

tim, can you provide a backtrace?

Please try using this CVS snapshot:

  http://snaps.php.net/php5.1-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5.1-win32-latest.zip

With the snapshot linked by Sniper, the problem is still there.

Wez, I think I'm misunderstanding what you're asking...The method of
getting a backtrace that I know of (debug_backtrace()) requires PHP to
be running.  The script crashes in such a way that no output ever goes
to the user agent, in spite of no output buffering.

Is there something else I should be doing?

- Tim

Hi guys, theese are two result files generated by APD for PHP 5.1.1 ...
are theese usefull ?

First crash: 
#Pprof [APD] v1.0.1
caller=C:\Programmi\Apache Group\Apache2\htdocs\test.php

END_HEADER
! 2 C:\Programmi\Apache Group\Apache2\htdocs\test.php
& 3 main 2
+ 3 2 2
& 4 apd_set_pprof_trace 2
+ 4 2 2
@ 2 2 0 10014 7978
- 3
& 6 PDO->__construct 1
+ 6 2 9
@ 2 9 0 0 271419
- 6
& 7 PDO->prepare 1
+ 7 2 14
@ 2 14 0 0 106
- 7
& 8 PDOStatement->execute 1
+ 8 2 15
@ 2 15 0 0 1164
- 8
@ 2 19 0 0 27
- 2

Second crash, script launched 1 time ... but two crashes:
#Pprof [APD] v1.0.1
caller=C:\Programmi\Apache Group\Apache2\htdocs\test.php

END_HEADER
! 1 C:\Programmi\Apache Group\Apache2\htdocs\test.php
& 1 main 2
+ 1 1 2
& 2 apd_set_pprof_trace 2
+ 2 1 2
@ 0 2 0 10014 3020
- 2
& 4 PDO->__construct 1
+ 4 1 9
@ 1 9 0 0 7835
- 4
& 5 PDO->prepare 1
+ 5 1 14
@ 1 14 0 0 77
- 5
& 6 PDOStatement->execute 1
+ 6 1 15
@ 1 15 0 0 435
- 6
@ 1 19 0 0 22
- 1

Code used is the same of gm with apd starded:
<?php
apd_set_pprof_trace();
try {
    $dbo = new PDO(
                        'mysql:host=localhost;dbname=test',
                        'user',
                        'pass',
                        array(PDO::ATTR_PERSISTENT => true)
                    );
} catch(PDOException $e) {
    echo 'Errore di connessione: '.$e->getMessage();
}

$pdostatement = $dbo->prepare('SELECT * FROM fake_table');
$pdostatement->execute();

echo 'print something';

?>

Regards .

P.S. Windows XP SP2 full updated with Apache 2.0.52 and PHP 5.1.1 as
module

Hi guys, it's me again :-)

MySQL used version for over debug was MySQL 4.1.9-nt ... but maybe the
problem is for the constant PDO::ATTR_PERSISTENT that creates some
problems on windows and Apache ... 

in sqlite, 2 or 3 default version, is the same .. in a different way, if
I try to connect with PDO::ATTR_PERSISTENT => true the database will be
undeletable and I need to stop Apache (with a crash) ... and then I can
delete my files.

It doesn't happen without PDO::ATTR_PERSISTENT during connection ... but
I wonder in a :memory: connection what should happen ... fear !!!!!
:oVVoVe:

Now this is the code:
<?php
$dbfile1 = 'sqlite2.sql';
$dbfile2 = 'sqlite3.sql';
$sqlite = new PDO('sqlite2:'.$dbfile1, '', '',
array(PDO::ATTR_PERSISTENT => true));
unset($sqlite);
$sqlite = new PDO('sqlite:'.$dbfile2, '', '', array(PDO::ATTR_PERSISTENT
=> true));
unset($sqlite);
unlink($dbfile1);
unlink($dbfile2);
?>

Regards

Please try using this CVS snapshot:

  http://snaps.php.net/php5.1-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5.1-win32-latest.zip

I meant a gdb backtrace for the crash.
However, I think this problem has now been resolved; please try the next
5.1 snapshot dated after this report.

Yup, that seems to have fixed it, at least for MySQL.

Thanks!

Tim

This bug has been fixed in CVS.

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.