|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #46289 PDO execute causes apache.exe to crash
Submitted: 2008-10-14 09:39 UTC Modified: 2009-09-02 09:45 UTC
Avg. Score:4.5 ± 0.9
Reproduced:20 of 20 (100.0%)
Same Version:8 (40.0%)
Same OS:13 (65.0%)
From: asylow at free dot fr Assigned:
Status: Not a bug Package: PDO related
PHP Version: 5.2.9 OS: Windows XP SP3
Private report: No CVE-ID: None
 [2008-10-14 09:39 UTC] asylow at free dot fr

I get an apache crash when executing the "execute" on a prepared query.
"L'instruction ? "0x0096ac76" emploie l'adresse m?moire "0X07a0a410". La m?moire ne peut pas ?tre "read"

PHP 5.2.6
Apache 2.2.9
The problem also happened using  Aug 06, 2008 04:30 UTC Snapshot.

Reproduce code:
The minimal code that causes the crash is :

class myclass {
function __construct() {
			$this->db = new PDO ("mssql:host=localhost\SQLEXPRESS;dbname=test","sa","toto");
	function foo() {
		$sql = 'SELECT oidObject FROM otIncidentspec WHERE oidObject=:ndossier AND oidArticle=277247835';
		$sth_activiteincident = $this->db->prepare($sql);
		$extract[] = array("abc"=>29);
		$extract[] = array("def"=>20);
$erp = new myclass();

Actual result:
Strangely minimal changes to the code avoids the problem. 
ie : removing the $extract[] definitions OR removing "AND oidArticle=277247835" in the query OR defining $this->db in the foo function instead of in the __construct.

I made a backtrace :

PHP5TS! 0096ac76()
PHP5TS! 0096bd79()
php_pdo_stmt_delref(_pdo_stmt_t * 0x064621c8, void * * * 0x01e67d18) line 2426 + 13 bytes
pdo_dbstmt_free_storage(_pdo_stmt_t * 0x064621c8, void * * * 0x01e67d18) line 2432 + 13 bytes
PHP5TS! 00a0cb9f()
PHP5TS! 00a0ca59()

Thank you.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2008-10-14 13:13 UTC] asylow at free dot fr
The same happens with PHP Version 5.2.7RC2-dev - Oct 14 2008 01:38:31 

The Call Stack debug is :

PHP5TS! 0096c9a3()
PHP5TS! 0096d28b()
free_statement(_pdo_stmt_t * 0x062d21d0, void * * * 0x01ec7d58) line 2396 + 19 bytes
php_pdo_stmt_delref(_pdo_stmt_t * 0x062d21d0, void * * * 0x01ec7d58) line 2426 + 13 bytes
pdo_dbstmt_free_storage(_pdo_stmt_t * 0x062d21d0, void * * * 0x01ec7d58) line 2432 + 13 bytes
PHP5TS! 009f3253()
PHP5TS! 009f3061()
PHP5TS! 009ff42d()
PHP5TS! 009d75df()
PHP5TS! 009d6d59()
PHP5TS! 009dc53c()
PHP5TS! 00982176()
PHP5TS! 00981a4f()
PHP5TS! 009819a0()
PHP5TS! 00963651()
PHP5TS! 00a06b2d()
PHP5APACHE2! 003e34fd()
LIBHTTPD! 6ff0268e()
LIBHTTPD! 6ff02b6e()
LIBHTTPD! 6ff138a0()
LIBHTTPD! 6ff0e317()
LIBHTTPD! 6ff060fe()
LIBHTTPD! 6ff064ec()
LIBHTTPD! 6ff27e4c()
MSVCR71! 7c349565()
KERNEL32! 7c80b713()
 [2009-02-20 03:23 UTC] michael dot cordover+php at gmail dot com
I also get this issue on WinXP SP2 (5.1 build 2600) running Apache (from xampplite 1.7.0).

Interestingly this occurs with executing a PDO::prepare()d SELECT statement but not on UPDATE or INSERT. This happens even when PDOStatement::bindValue / bindParam is not used.

I cannot reproduce the "subtle change makes it work" described by asylow.

I am unable to provide a backtrace.

// Connection is definitely valid
$q = $dbConn->prepare('SELECT * FROM people');

--Crash report--
AppName: apache.exe
ModName: php_pdo_mysql.dll
Offset: 0000249a

--PHP Version--  [per phpinfo()]
Was occurring on 5.2.8 and also on snapshot:
PHP Version 5.2.9RC3-dev
System 	Windows NT 18315XP 5.1 build 2600
Build Date 	Feb 18 2009 23:39:16
Configure Command 	cscript /nologo configure.js "--enable-snapshot-build" "--enable-debug-pack" "--with-snapshot-template=d:\php-sdk\bin\\..\snap_5_2\vc6\x86\template" "--with-php-build=d:\php-sdk\bin\\..\snap_5_2\vc6\x86\php_build" "--with-pdo-oci=D:\php-sdk\oracle\instantclient10\sdk,shared" "--with-oci8=D:\php-sdk\oracle\instantclient10\sdk,shared"

--PDO Version--  [per phpinfo()]
pdo_mysql PDO Driver for MySQL, client library version	5.1.30

--MySQL Version--
C:\xampplite\mysql\bin>mysqld.exe --version
mysqld.exe  Ver 5.1.30-community for Win32 on ia32 (MySQL Community Server (GPL))
 [2009-05-03 17:43 UTC] oddvibes at gmail dot com
I'm having the same issue on Windows Vista. The following Windows crash information might be useful:

Windows error-reporting creates the following error-messages:

    Faulting application apache.exe, version, time stamp 0x493f5d44, faulting module php_pdo_mysql.dll, version, time stamp 0x493d7650, exception code 0xc0000005, fault offset 0x0000250a, process id 0xf10, application start time 0x01c9c677df857f87.


    Faulting application apache.exe, version, time stamp 0x493f5d44, faulting module ntdll.dll, version 6.0.6001.18000, time stamp 0x4791a7a6, exception code 0xc0000005, fault offset 0x0006814c, process id 0x10d8, application start time 0x01c9c677ded2aa47.

And after that, the following information:

    Fault bucket 1062083465, type 1
    Event Name: APPCRASH
    Response: None
    Cab Id: 0

    Problem signature:
    P1: apache.exe
    P3: 493f5d44
    P4: php_pdo_mysql.dll
    P6: 493d7650
    P7: c0000005
    P8: 0000250a

    Attached files:

    These files may be available here:


    * Windows Vista Home Edition
    * Apache 2.2
    * MySQL 5.1.30
    * PHP 5.2.8
 [2009-05-03 19:01 UTC] oddvibes at gmail dot com
I fixed this problem on my computer. In my case it seems to have to do something with the Xammp installation. It probably would be interesting to know if the other people who were experiencing this problem were also running on xammp.

I found this sollution by searching the web and found it on the Magento-forum:

The solution is simple:

- Download:
- Unzip & copy libmysql.dll into xampp\apache\bin & xampp\php.
- Restart apache.
 [2009-05-08 19:10 UTC] mattgrdinic at yahoo dot com
I can confirm this bug as well. The solution was similar to above, I replaced the php_pdo_mysql.dll and php_pdo.dll which were version with ones from my 5.2.8 install (which were version, and all works as expected.
 [2009-05-24 18:04 UTC] dave at abo dot co dot uk
I have a similar occurrence when running through apache2.2 and mysql 5

When running a page via apache with mysql query it crashes 

szAppName : httpd.exe     szAppVer :     
szModName : php5ts.dll     
szModVer :     offset : 0000ac7a   

however when running the same page through php cli it works fine

Running PHP 5.2.9-2 (cli) (built: Apr  9 2009 08:23:19)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies

Here is my example code 

It crashes frequently on the mysql_connect line other times it appears to get as far (compiling) as the mysql query

  $cMysqlDatabase = 'develop';
  $cMysqlUsername = 'develop';
  $cMysqlPassword = 'develop';
  $cMysqlDatabase = 'develop_dev';

  $mysql_link = mysql_connect($gcMysqlHost1, $cMysqlUsername, $cMysqlPassword);
  $bDatabaseSelected = mysql_select_db($cMysqlDatabase, $mysql_link);

  print "hello\n";
  $nTestLevel = 1;

  if ($nTestLevel > 0)
    print " nTestLevel > 0";
    $query = "show tables\n";

    print "Query = $query";

    $mysql_result = mysql_query($query, $mysql_link);
    if ($mysql_result)
      while ($arTables = mysql_fetch_assoc($mysql_result))
      print "error ". mysql_error($mysql_link) . "\n";
  print "end\n";

 [2009-06-22 03:53 UTC] ramin dot farmani at gmail dot com
similarly my httpd.exe crashed when i runnig a site wroten by Yii framework it's seem we have a big problem in php_pdo_mysql library I using php 5.2.10
 [2009-09-02 03:07 UTC] Parad0X dot UA at gmail dot com
I was able to fix this by removing MYSQL from Windows' PATH env setting. Looks like when PHP is looking for libmysql.dll it uses the first one it finds in mysql\bin and it's not quite compatible. 
Or you can try to add php to the path before mysql.

I hope that helps.
 [2009-09-02 09:45 UTC]
Ok, it was then the classic case where MySql's libmysql DLL was used instead of the version bundled with PHP. We already have many bogus reports about this issue and your solution is the right one (as explain in the other reports).
PHP Copyright © 2001-2023 The PHP Group
All rights reserved.
Last updated: Wed Dec 06 09:01:28 2023 UTC