Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:48466
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.161.42 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:date:message-id:subject:from:to:content-type;
        b=DVhpF6CFdCzsgrcCHWVB9f9cZgXnVcc/VuYU8aB7runrMxCK2DO4ze1jSNrl1F2+5B
         6jO++CyQCZIkLDTo9XwRjxkwDS/1xfvES9GXWTQJBpHkdX2XY+5pU8+g0mnw/cUTSEib
         7j8qKQd1q7u61f7k9GrFFLfo+y+Z7/KgjXP1M=
MIME-Version: 1.0
Date: Tue, 25 May 2010 20:16:30 +0200
Message-ID: <AANLkTikiXcNWnfhEVS4s1FAPp1QS2EIk6iLiMhJb70sL@mail.gmail.com>
To: internals@lists.php.net
Content-Type: text/plain; charset=ISO-8859-1
Subject: PHP / iODBC / PostGreSQL: running into a deadlock
From: prometheus.web@gmail.com (prometheus)

Hi,

I recently decided to setup my mac for some php developments.

OS X 10.5 already ships with Apache, PHP and I chose PostGreSQL as DB
server. I picked a package link from the official website and I installed
it. The DB server is running smoothly.

Now, as OS X's php module is not pgsql-enabled, I chose to take advantage of
libiodbc (which php can handle). I installed psqlODBC driver.
-> testing with `iodbctest': the program finds libiodbc which in turns uses
psqlODBC driver to connect to the database; I can issue SQL statements which
succeed => OK
-> connecting php to libiodbc (note that I get the same results whether I
use php module with Apache or the CLI): odbc_connect() works correctly, the
DSN is found and I get a connection on PostgreSQL server. The problem arises
when I try to use odbc_prepare(), odbc_exec(), etc. functions. I run into
some kind of a deadlock which causes those functions to never end. I
couldn't find any solution/description of this problem for Mac platform in
Google.

To try to solve this issue, I grabed the sources for PHP (5.3.2) and
libiodbc (3.52.7). When ran under GDB, I can observe the following:
odbc_exec() [PHP code] calls SQLAllocStmt() [libiodbc code], which calls
some internal function that tries to call SQLAllocStmt(), in some indirect
recursive way. As SQLAllocStmt() is protected by a mutex, there's a
deadlock.
The BT is as follows:
#0 0x90529d85 in pthread_mutex_lock ()
#1 0x00bd6cec in SQLAllocStmt (hdbc=0x1016200, phstmt=0x1828034) at
hstmt.c:427
#2 0x00bd667a in SQLAllocStmt_Internal (hdbc=0x1827940, phstmt=0xdc5cec) at
hstmt.c:241
#3 0x00bd6db6 in SQLAllocStmt (hdbc=0x1827940, phstmt=0xdc5cec) at
hstmt.c:430
#4 0x00238808 in zif_odbc_exec (ht=2, return_value=0xdc454c,
return_value_ptr=0x0, this_ptr=0x0, return_value_used=0) at
/usr/local/php/src/5.3.2/ext/odbc/php_odbc.c:1551
#5 0x004d020d in zend_do_fcall_common_helper_SPEC (execute_data=0xf28040) at
zend_vm_execute.h:313
#6 0x004d5815 in ZEND_DO_FCALL_SPEC_CONST_HANDLER (execute_data=0xf28040) at
zend_vm_execute.h:1603
#7 0x004cf346 in execute (op_array=0xdc5d38) at zend_vm_execute.h:104
#8 0x0049fec9 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at
/usr/local/php/src/5.3.2/Zend/zend.c:1194
#9 0x004231f5 in php_execute_script (primary_file=0xbffff98c) at
/usr/local/php/src/5.3.2/main/main.c:2260
#10 0x00578f7b in main (argc=2, argv=0xbffffa84) at
/usr/local/php/src/5.3.2/sapi/cli/php_cli.c:1192

Regarding why this doesn't occur with `iodbctest', the answer is that is
simply doesn't call SQLAllocStmt(). It replaces this call with
SQLAllocHandle().

Now, I'm wondering:
-> am I the only nut to try such setup on OS X (Apache, PHP, ODBC,
Postgres)?
-> is that some configuration issue?
-> is that a problem either in PHP or libiodbc code?

Thanks!
Clement