|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #33283 Apache segfaults when attempting to use PDO
Submitted: 2005-06-09 17:56 UTC Modified: 2005-06-24 18:07 UTC
From: david dot prusak at copart dot com Assigned:
Status: Not a bug Package: PDO related
PHP Version: 5.1-b2 OS: *
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Bug Type:
From: david dot prusak at copart dot com
New email:
PHP Version: OS:


 [2005-06-09 17:56 UTC] david dot prusak at copart dot com
When attempting to use the PDO class, Apache GPF's.

My PHP.ini reads as follows:

extension_dir = "C:\php\ext"

Apache/PHP doesn't alert me that the libraries couldn't be loaded.

The code provided is 100% reproducable on my system.  

Removing all the code except the database connection doesn't crash.  The code does say that the connection was established.

I'm not 100% sure if it's php or my php.ini file.  The backtrace tells me that the class doesn't exist.  That leaves me with a suspicion that it could be config related.

Reproduce code:

try	{
	$dbh = new PDO('odbc:IBMDB2', 'USER', 'PASS', 
		array(PDO_ATTR_PERSISTENT => true));
		echo "Connected\n";
	} catch (Exception $e) {
		echo "Failed: " . $e->getMessage();

	$email = "";
	$stmt = $dbh->prepare("CALL SPROC(?, ?)");
	$stmt->bindParam(1, $email);
	$stmt->bindParam(2, $return_value, PDO_PARAM_STR, 80);
	print "procedure returned $return_value\n";

Expected result:
Results from the database without error

Actual result:
(gdb) target exec C:\php\php.exe
(gdb) run test.php
Starting program: /cygdrive/c/php/php.exe test.php

PHP Fatal error:  Class 'PDO' not found in c:\Documents and Settings\dmprusak1\My Documents\htdocs_80\pages\project_manager\test.php on line 17

Fatal error: Class 'PDO' not found in c:\Documents and Settings\dmprusak1\My Documents\htdocs_80\pages\project_manager\test.php on line 17

Program received signal SIGSEGV, Segmentation fault.
0x77ea3c00 in RpcRaiseException ()
   from /cygdrive/c/WINDOWS/system32/rpcrt4.dll


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2005-06-09 19:10 UTC] david dot prusak at copart dot com
Might want to ingore the gdb information I provided.  It's not correct on the windows system.  I more than happy to help debug.  Just let me know what you need and how I can get it to you.

 [2005-06-09 19:39 UTC]
Sounds like two different issues, neither of which is PDO specific ;-)

Check that you were modifying the right php.ini file, and that you restarted apache after changing it. (phpinfo() will help you to figure that out).

Your script is broken, btw. You catch the exception, effectively ignoring the error, and then continue to use the $dbh even though you "know" it isn't there.  You should move that code inside the try {} block, just after you echo  "Connected";

The GPF concerns me, but I suspect it will go away once you load PDO correctly.  If you're feeling motivated, can you try pruning down your script to the smallest possible test case that reproduces the GPF?  I'm hoping you can cut it down to something like this:

class foo {
  function __construct() {
     throw new Exception("bang");

try {
  $foo = new foo;
} catch (Exception $e) {
  echo "Failed " . $e->getMessage();

 [2005-06-09 21:26 UTC] david dot prusak at copart dot com
Oops sorry about that.

This fails with a gpf:
try {
$dbh = new PDO('odbc:DATABASE', 'USER', 'PASS')
	$stmt = $dbh->prepare("SELECT * FROM TABLE");
} catch (Exception $e) {
	echo "Failed: " . $e->getMessage();

While this works just fine and prints "Connected",
try {
$dbh = new PDO('odbc:DATABASE', 'USER', 'PASS')
	print "Connected\n";
} catch (Exception $e) {
	echo "Failed: " . $e->getMessage();

When I use exec, I don't get the GPF, but I'm also not getting the correct results.  When trying to query a fake table, I don't get an error.  When I query the correct table, I don't get a count.

When I put in an incorrect database, user or password, I do get the correct error.  So that tells me that I can connect to the database.

try {
$dbh = new PDO('odbc:DATABASE', 'USER', 'PASS')
	print "Connected<br>";
	$count = $dbh->exec("SELECT * FROM FAKETABLE");
	print "Count: $count";
} catch (Exception $e) {
	echo "Failed: " . $e->getMessage();

I did verify the php.ini is correct.  I put in a typo in the ini file to see if Apache will err on start up and it did.  (brute force method :) )

Hope that's not too much information.

 [2005-06-09 23:59 UTC]
If you add:

$stmt = null;
$dbh = null;

to the end of your script, does the segfault go away?
 [2005-06-10 17:22 UTC] david dot prusak at copart dot com
No, adding that didn't stop the GPF, sorry.
 [2005-06-10 18:39 UTC] david dot prusak at copart dot com
Well, I installed all this on my solaris box. Accessing the same page, I get this in my apache error.log

[Fri Jun 10 09:29:03 2005] [notice] child pid 19516 exit signal Segmentation fault (11)

Removing the "prepare" doesn't segfault apache.  The behavior is identical to the windows version.
 [2005-06-14 02:06 UTC] david dot prusak at copart dot com
When I installed the link you provided on my Windows machine, php/apache starts, but I get an error "Unable to load dynamic library 'C:\php\ext\php_pdo.dll' - the specified procedure could not be found.  This also occurs with php_pdo_odbc.dll

On my solaris machine, configure doesn't work.  It's informing me that the IBM_DB2 environment wasn't set, but I did run it and it is set.

./configure --with-apache2=../httpd-2.0.53 --prefix=/www/php --with-mysql=/usr/local/mysql --with-gd=/usr/local --with-apxs2=/www/apache/bin/apxs --with-config-file-path=/www/php/etc --with-ibm-db2=/export/home/db2inst1/sqllib/
checking for Adabas support... no
checking for SAP DB support... no
checking for Solid support... no
checking for IBM DB2 support... ./configure: !: not found
configure: error:
build test failed. Please check the config.log for details.
You need to source your DB2 environment before running PHP configure:
# . $IBM_DB2/db2profile

configure:63159: checking for IBM DB2 support
configure:63230: gcc -o conftest -g -O2  -D_POSIX_PTHREAD_SEMANTICS  -R/usr/ucbl
ib -L/usr/ucblib -R/usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.2 -L/usr/local/li
b/gcc/sparc-sun-solaris2.9/3.4.2 -R/usr/local/lib -L/usr/local/lib -R/usr/local/
mysql/lib/mysql -L/usr/local/mysql/lib/mysql conftest.c
      -L/export/home/db2inst1/sqllib//lib -ldb2
     -lmysqlclient -lgd -lresolv -lm -ldl -lnsl -lsocket  -lgcc -lxml2 -lz -lico
nv -lm -lsocket -lnsl -lxml2 -lz -liconv -lm -lsocket -lnsl 1>&5
configure: failed program was:
#line 63219 "configure"
#include "confdefs.h"

    char SQLExecute();
    int main() {
      return 0;

 [2005-06-16 18:12 UTC]
That is not the correct configure line to get PDO ODBC driver enabled, try reading the ./configure --help output..

 [2005-06-16 20:11 UTC] david dot prusak at copart dot com
Ahh communication :)  I'm using 5.0.x using for the PECL extensions and the PHP builds. For Windows, I'm simply download and installing.  Loading the files via php.ini extensions.

For Solaris, I was using 5.0.x, Compiling PHP, then wget-ing the PDO libraries from Compiling them and simply loading them in the php.ini as libraries.  The configure for that version of PHP doesn't allow compiling PDO into php itself

I did download 5.1 for both Windows and Solaris.  

On Windows, PDO loads fine, but the PDO_ODBC fails to load.  Tells me the module can't be found, but is is there.

On Solaris, I issued the following (reading 2 documents to use PDO_ODBC with IBM_DB2 database and came up with the following configure:

./configure --with-apache2=../httpd-2.0.53 --prefix=/www/php --with-gd=/usr/local --with-apxs2=/www/apache/bin/apxs --with-config-file-path=/www/php/etc --with-ibm-db2=/export/home/db2inst1/sqllib --with-pdo-odbc=ibm-db2

I get the same as before error when I try to issue the --with-ibm-db2=/export/home/db2inst1/sqllib  Without it, it compiles and runs just fine, but without DB2 database connectivity.

--with-ibm-db2=/export/home/db2inst1/sqllib works just fine with 5.0.4 on
 [2005-06-17 00:56 UTC]
First of all: You're reporting bug in 5.1-beta1, but you still talk about using 5.0.x. Let's close this one as bogus.
Ask further support questions about how to compile/configure PHP elsewhere.

 [2005-06-17 18:25 UTC] david dot prusak at copart dot com
First off, I have no idea when the php version changed to 5.1.  I reported it as 5.0.4. (had to check my email thread to verify)  I had assumed you wanted me to test this using 5.1 to see if that version had a fix.  I have no desire to actually use 5.1 at this time, (unless it did work).  I was hoping for a workaround in 5.0.4, but it looks like there is no workaround.  I do know the PECL libraries are experiemental.  I had only posted here to see if anyone knew of a workaround or if it was a known issue.

Lastly, I'm learning this isn't the place to report such issues, so I'm wondering where is the correct place to ask.
 [2005-06-24 18:07 UTC] david dot prusak at copart dot com
Just for an update, 5.1-b2 works on solaris.  I had to "hack" the configure script to stop trying to work with my db2connect environment check.  I wanted to be able to use the regular ODBC and play with the PDO_ODBC at the same time.  PDO_ODBC had no issues compiling.  It was trying to get the standard ODBC to compile with IBM-DB2.  It has some extra checks that would fail to configure.  Removing that "check" and having the code assume it's there, compiles and runs perfectly.

I'm trying to get PDO/ODBC to work on windows, but I can't find a pdo_odbc.dll that will work with 5.1-b2.  It didn't come with the either the php or pecl package.  Trying to find documentation on this.  No luck so far.  When assuming it's compiled in, I get a "Failed: could not find driver"

Lastly, again, sorry for the confusion on the bug report.  The PDO libs (Stable 5.0) at for windows does still cause Apache to GPF when trying to use them.
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Jun 20 19:01:30 2024 UTC