Prev: Call two class object failed
Next: File Downloads
From: prometheus on 24 May 2010 15:05
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!
From: Chris on 24 May 2010 19:39

> 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:

Probably best to ask on the php-internals list, they write the C code
behind php so will be best able to help you.

--
Postgresql & php tutorials
http://www.designmagick.com/

 | 
Pages: 1
Prev: Call two class object failed
Next: File Downloads