Bug #48614 [Com]: Loading "pdo_sqlite.so" fails: undefined symbol: sqlite3_libversion
Edit report at http://bugs.php.net/bug.php?id=48614&edit=1 ID: 48614 Comment by: ashoat at gmail dot com Reported by: kaspernj at gmail dot com Summary: Loading "pdo_sqlite.so" fails: undefined symbol: sqlite3_libversion Status: Assigned Type: Bug Package: PDO related Operating System: Ubuntu Jaunty PHP Version: 5.3.0RC4 Assigned To: scottmac New Comment: The problem is still occurring. There really ought to be a patch by now. Previous Comments: [2010-04-25 13:00:18] ovidio dot balan at gmail dot com lol .. :( [2010-04-05 15:41:51] koubel at volny dot cz Year will be gone, and problem is still here: tested on 5.3.2 debian stable [2010-02-23 03:54:27] l27n at yahoo dot com Same problem, PHP 5.3.1, CENTOS 5.4 [2010-02-02 09:40:03] marc dot bennewitz at giata dot de I have the same problem with suse 10.x 32/64 bit using php 5.3.0/1 stable. My configure is: cd "/home/worker/download/php-5.3.1" ./configure \ --with-apxs2=/usr/local/apache2/bin/apxs \ --with-mm \ --with-mysql=shared,/usr/local \ --with-mysqli=shared,/usr/local/bin/mysql_config \ --with-sqlite=shared \ --with-sqlite3=shared \ --enable-pdo=shared \ --with-pdo-mysql=shared,/usr/local \ --with-pdo-sqlite=shared \ --with-libxml-dir=/usr/local/lib \ --enable-soap \ --with-zlib \ --disable-cgi \ --with-gd=shared \ --with-freetype-dir \ --with-jpeg-dir=/usr/lib \ --enable-gd-native-ttf \ --enable-exif \ --with-xsl \ --with-mcrypt \ --with-openssl \ --enable-mbstring \ --enable-mbregex \ --enable-ftp=shared \ --with-kerberos \ --enable-zip And extension order: extension=pdo.so extension=sqlite.so extension=sqlite3.so extension=mysql.so extension=mysqli.so extension=pdo_mysql.so extension=pdo_sqlite.so Additionally if I load sqlite.so before pdo.so than I get 1 more error: PHP Warning: PHP Startup: Unable to load dynamic library '/usr/local/lib/php/extensions/no-debug-non-zts-20090626/sqlite.so' - /usr/local/lib/php/extensions/no-debug-non-zts-20090626/sqlite.so: undefined symbol: php_pdo_unregister_driver in Unknown on line 0 Warning: PHP Startup: Unable to load dynamic library '/usr/local/lib/php/extensions/no-debug-non-zts-20090626/sqlite.so' - /usr/local/lib/php/extensions/no-debug-non-zts-20090626/sqlite.so: undefined symbol: php_pdo_unregister_driver in Unknown on line 0 [2009-11-23 22:48:24] koubel at volny dot cz i dot galic: yes, but if I use bundled sqlite, without /usr in configure, bug is still here. When I use --enable-pdo=shared --with-pdo-sqlite=shared "configure" and "make" phases are ok, but when I try to use "make test" all tests fails, because warning: dl(): Unable to load dynamic library '.../pdo_sqlite.so' - .../pdo_sqlite.so: undefined symbol: sqlite3_libversion is produced on every test. So bug is still there (tested php 5.3.1 on Debian Lenny). Using own sqlite is workaround I think. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=48614 -- Edit this bug report at http://bugs.php.net/bug.php?id=48614&edit=1
#45894 [Opn]: PHP (cleanup?) runs infinite loop after ODBC used
ID: 45894
User updated by: ashoat at gmail dot com
Reported By: ashoat at gmail dot com
Status: Open
Bug Type: ODBC related
Operating System: CentOS 5.2 x64_86
PHP Version: 5.2.6
New Comment:
OK, after examining PHP's source code a bit, it seems that the issue
here is that when the ODBC extension is cleaning up its connection with
MySQL, it interferes with the MySQL's extension's cleanup.
As a result, MySQL blocks at some later point when trying to kill some
MySQL thread.
You can disregard most of my last post, except the two points listed at
the top.
Previous Comments:
[2008-08-24 07:26:27] ashoat at gmail dot com
I've experimented around, and I have a few updates:
1) This problem is not general to all ODBC drivers. When I attempt a
connection to PostgreSQL (I have PostgreSQL/psqlodbc installed as well
as MySQL/Connector ODBC), I experience no problems.
2) This problem is not specific to MySQL/Connector ODBC. When I attempt
an ODBC connection from ASP.NET (Mono Project v1.9.1), there is no
stalling in the connection or cleanup.
For the record, I am using unixODBC 2.2.11 and MySQL Connector/ODBC
3.51.26.
The above points lead me to the conclusion that this is an issue with
PHP's behavior when it is passed a certain parameter by ODBC that
coincedentally is passed by MySQL/Connector ODBC. This conclusion seems
to be supported by the backtrace, although I am confused as to the jump
between frame #8 and frame #9.
More information from gdb on those frames:
(gdb) frame 9
#9 0x008879fc in module_destructor (module=0x193015e0)
at /home/cpeasyapache/src/php-5.2.6/Zend/zend_API.c:1921
1921module->module_shutdown_func(module->type,
module->module_number TSRMLS_CC);
(gdb) frame 8
#8 0x0061f546 in zm_shutdown_mysql (type=1, module_number=21,
tsrm_ls=0x192909c0)
at /home/cpeasyapache/src/php-5.2.6/ext/mysql/php_mysql.c:426
426 mysql_server_end();
Forgive me if I am wrong here, but I am baffled as to why PHP is
calling ext/mysql/php_mysql.c. At no point is the MySQL extension used -
I am exclusively using the ODBC (Unified) extension. Furthermore, if PHP
was indeed utilizing the ODBC extension then wouldn't libodbc appear as
an intermediary somewhere in the stack?
If I were asked to guess what the issue was here, I would think that
somewhere in the PHP source there is a filter to catch all calls for
Driver={MySQL ODBC} in odbc_connect() and to channel them to the MySQL
extension. Of course, I have never even looked at the PHP source, so I
may be totally wrong :)
Whatever the problem is, such behavior should not be happening and I
would strongly discourage anybody on the team from pinning the blame on
unixODBC or MySQL Connector/ODBC. Whatever the issue is, PHP should
always successfully close a stream and if there is an issue on either of
the above module's sides then an appropriate error message should be
given.
Thanks a lot for taking the time from your busy schedules to
investigate this bug! Myself and others appreciate your open-source and
collaborative effort to keep the PHP project up and running.
------------
[2008-08-22 23:19:56] ashoat at gmail dot com
Attached is the backtrace. Note that the segfault is not generated
unless a force-close the command-line php interpreter by hitting
Ctrl+C.
(gdb) bt
#0 0x00308dab93d0 in ?? ()
#1
#2 0x003a2c80c898 in __lll_mutex_lock_wait () from
/lib64/libpthread.so.0
#3 0x003a2c80a315 in _L_mutex_lock_18 () from
/lib64/libpthread.so.0
#4 0x003a2c80a273 in pthread_cond_destroy@@GLIBC_2.3.2 ()
from /lib64/libpthread.so.0
#5 0x003a340269fb in my_thread_global_end () at my_thr_init.c:216
#6 0x003a34022265 in my_end (infoflag=0) at my_init.c:205
#7 0x003a3402100f in mysql_server_end () at libmysql.c:197
#8 0x0061f546 in zm_shutdown_mysql (type=1, module_number=21,
tsrm_ls=0x192909c0)
at /home/cpeasyapache/src/php-5.2.6/ext/mysql/php_mysql.c:426
#9 0x008879fc in module_destructor (module=0x193015e0)
at /home/cpeasyapache/src/php-5.2.6/Zend/zend_API.c:1921
#10 0x0088df4b in zend_hash_apply_deleter (ht=0xf37700,
p=0x19301580)
at /home/cpeasyapache/src/php-5.2.6/Zend/zend_hash.c:611
#11 0x0088e0b7 in zend_hash_graceful_reverse_destroy
(ht=0xf37700)
at /home/cpeasyapache/src/php-5.2.6/Zend/zend_hash.c:646
#12 0x0087cea7 in zend_shutdown (tsrm_ls=0x192909c0)
at /home/cpeasyapache/src/php-5.2.6/Zend/zend.c:733
#13 0x0080476f in php_module_shutdown (tsrm_ls=0x192909c0)
at /home/cpeasyapache/src/php-5.2.6/main/main.c:1888
#14 0x0091a396 in main (argc=2, argv=0x78753f88)
[2008-08-22 21:
#45894 [Opn]: PHP (cleanup?) runs infinite loop after ODBC used
ID: 45894
User updated by: ashoat at gmail dot com
Reported By: ashoat at gmail dot com
Status: Open
Bug Type: ODBC related
Operating System: CentOS 5.2 x64_86
PHP Version: 5.2.6
New Comment:
I've experimented around, and I have a few updates:
1) This problem is not general to all ODBC drivers. When I attempt a
connection to PostgreSQL (I have PostgreSQL/psqlodbc installed as well
as MySQL/Connector ODBC), I experience no problems.
2) This problem is not specific to MySQL/Connector ODBC. When I attempt
an ODBC connection from ASP.NET (Mono Project v1.9.1), there is no
stalling in the connection or cleanup.
For the record, I am using unixODBC 2.2.11 and MySQL Connector/ODBC
3.51.26.
The above points lead me to the conclusion that this is an issue with
PHP's behavior when it is passed a certain parameter by ODBC that
coincedentally is passed by MySQL/Connector ODBC. This conclusion seems
to be supported by the backtrace, although I am confused as to the jump
between frame #8 and frame #9.
More information from gdb on those frames:
(gdb) frame 9
#9 0x008879fc in module_destructor (module=0x193015e0)
at /home/cpeasyapache/src/php-5.2.6/Zend/zend_API.c:1921
1921module->module_shutdown_func(module->type,
module->module_number TSRMLS_CC);
(gdb) frame 8
#8 0x0061f546 in zm_shutdown_mysql (type=1, module_number=21,
tsrm_ls=0x192909c0)
at /home/cpeasyapache/src/php-5.2.6/ext/mysql/php_mysql.c:426
426 mysql_server_end();
Forgive me if I am wrong here, but I am baffled as to why PHP is
calling ext/mysql/php_mysql.c. At no point is the MySQL extension used -
I am exclusively using the ODBC (Unified) extension. Furthermore, if PHP
was indeed utilizing the ODBC extension then wouldn't libodbc appear as
an intermediary somewhere in the stack?
If I were asked to guess what the issue was here, I would think that
somewhere in the PHP source there is a filter to catch all calls for
Driver={MySQL ODBC} in odbc_connect() and to channel them to the MySQL
extension. Of course, I have never even looked at the PHP source, so I
may be totally wrong :)
Whatever the problem is, such behavior should not be happening and I
would strongly discourage anybody on the team from pinning the blame on
unixODBC or MySQL Connector/ODBC. Whatever the issue is, PHP should
always successfully close a stream and if there is an issue on either of
the above module's sides then an appropriate error message should be
given.
Thanks a lot for taking the time from your busy schedules to
investigate this bug! Myself and others appreciate your open-source and
collaborative effort to keep the PHP project up and running.
Previous Comments:
----
[2008-08-22 23:19:56] ashoat at gmail dot com
Attached is the backtrace. Note that the segfault is not generated
unless a force-close the command-line php interpreter by hitting
Ctrl+C.
(gdb) bt
#0 0x00308dab93d0 in ?? ()
#1
#2 0x003a2c80c898 in __lll_mutex_lock_wait () from
/lib64/libpthread.so.0
#3 0x003a2c80a315 in _L_mutex_lock_18 () from
/lib64/libpthread.so.0
#4 0x003a2c80a273 in pthread_cond_destroy@@GLIBC_2.3.2 ()
from /lib64/libpthread.so.0
#5 0x003a340269fb in my_thread_global_end () at my_thr_init.c:216
#6 0x003a34022265 in my_end (infoflag=0) at my_init.c:205
#7 0x003a3402100f in mysql_server_end () at libmysql.c:197
#8 0x0061f546 in zm_shutdown_mysql (type=1, module_number=21,
tsrm_ls=0x192909c0)
at /home/cpeasyapache/src/php-5.2.6/ext/mysql/php_mysql.c:426
#9 0x008879fc in module_destructor (module=0x193015e0)
at /home/cpeasyapache/src/php-5.2.6/Zend/zend_API.c:1921
#10 0x0088df4b in zend_hash_apply_deleter (ht=0xf37700,
p=0x19301580)
at /home/cpeasyapache/src/php-5.2.6/Zend/zend_hash.c:611
#11 0x0088e0b7 in zend_hash_graceful_reverse_destroy
(ht=0xf37700)
at /home/cpeasyapache/src/php-5.2.6/Zend/zend_hash.c:646
#12 0x0087cea7 in zend_shutdown (tsrm_ls=0x192909c0)
at /home/cpeasyapache/src/php-5.2.6/Zend/zend.c:733
#13 0x0080476f in php_module_shutdown (tsrm_ls=0x192909c0)
at /home/cpeasyapache/src/php-5.2.6/main/main.c:1888
#14 0x0091a396 in main (argc=2, argv=0x78753f88)
[2008-08-22 21:55:58] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32
Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". T
#45894 [Fbk->Opn]: PHP (cleanup?) runs infinite loop after ODBC used
ID: 45894 User updated by: ashoat at gmail dot com Reported By: ashoat at gmail dot com -Status: Feedback +Status: Open Bug Type: ODBC related Operating System: CentOS 5.2 x64_86 PHP Version: 5.2.6 New Comment: Attached is the backtrace. Note that the segfault is not generated unless a force-close the command-line php interpreter by hitting Ctrl+C. (gdb) bt #0 0x00308dab93d0 in ?? () #1 #2 0x003a2c80c898 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 #3 0x003a2c80a315 in _L_mutex_lock_18 () from /lib64/libpthread.so.0 #4 0x003a2c80a273 in pthread_cond_destroy@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #5 0x003a340269fb in my_thread_global_end () at my_thr_init.c:216 #6 0x003a34022265 in my_end (infoflag=0) at my_init.c:205 #7 0x003a3402100f in mysql_server_end () at libmysql.c:197 #8 0x0061f546 in zm_shutdown_mysql (type=1, module_number=21, tsrm_ls=0x192909c0) at /home/cpeasyapache/src/php-5.2.6/ext/mysql/php_mysql.c:426 #9 0x008879fc in module_destructor (module=0x193015e0) at /home/cpeasyapache/src/php-5.2.6/Zend/zend_API.c:1921 #10 0x0088df4b in zend_hash_apply_deleter (ht=0xf37700, p=0x19301580) at /home/cpeasyapache/src/php-5.2.6/Zend/zend_hash.c:611 #11 0x0088e0b7 in zend_hash_graceful_reverse_destroy (ht=0xf37700) at /home/cpeasyapache/src/php-5.2.6/Zend/zend_hash.c:646 #12 0x0087cea7 in zend_shutdown (tsrm_ls=0x192909c0) at /home/cpeasyapache/src/php-5.2.6/Zend/zend.c:733 #13 0x0080476f in php_module_shutdown (tsrm_ls=0x192909c0) at /home/cpeasyapache/src/php-5.2.6/main/main.c:1888 #14 0x0091a396 in main (argc=2, argv=0x78753f88) Previous Comments: [2008-08-22 21:55:58] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. [2008-08-22 20:09:46] ashoat at gmail dot com Description: I have PHP 5.2.6 compiled as CGI wrapped with suPHP installed on a CentOS 5.2 x64_86 box. I compiled PHP with --with-unixODBC, version 2.2.11. After I open an ODBC connection and then close it, I am able to continue executing PHP code. However, when it is time to cleanup and exit the script, the parser stalls and does not close the stream. This has been tested through the commandline and httpd. When I force close the command-line executor after the cleanup stalls, I get "Segmentation fault" appended to the end of the stream before it closes. Reproduce code: --- after the connection is closed."; echo "Something is clearly wrong with PHP's cleanup."; ?> Expected result: The expected result is that the code executes and the stream then closes. If the ODBC functions caused a block and did not close, a timeout would be expected and the code towards the end of the file would not execute. However, the code at the end does execute (see here: http://www.heliohost.org/test.php). Therefore, it seems that the issue here is with PHP's cleanup methods. Actual result: -- See here: http://www.heliohost.org/test.php -- Edit this bug report at http://bugs.php.net/?id=45894&edit=1
#45894 [NEW]: PHP (cleanup?) runs infinite loop after ODBC used
From: ashoat at gmail dot com Operating system: CentOS 5.2 x64_86 PHP version: 5.2.6 PHP Bug Type: ODBC related Bug description: PHP (cleanup?) runs infinite loop after ODBC used Description: I have PHP 5.2.6 compiled as CGI wrapped with suPHP installed on a CentOS 5.2 x64_86 box. I compiled PHP with --with-unixODBC, version 2.2.11. After I open an ODBC connection and then close it, I am able to continue executing PHP code. However, when it is time to cleanup and exit the script, the parser stalls and does not close the stream. This has been tested through the commandline and httpd. When I force close the command-line executor after the cleanup stalls, I get "Segmentation fault" appended to the end of the stream before it closes. Reproduce code: --- after the connection is closed."; echo "Something is clearly wrong with PHP's cleanup."; ?> Expected result: The expected result is that the code executes and the stream then closes. If the ODBC functions caused a block and did not close, a timeout would be expected and the code towards the end of the file would not execute. However, the code at the end does execute (see here: http://www.heliohost.org/test.php). Therefore, it seems that the issue here is with PHP's cleanup methods. Actual result: -- See here: http://www.heliohost.org/test.php -- Edit bug report at http://bugs.php.net/?id=45894&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=45894&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=45894&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=45894&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=45894&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=45894&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=45894&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=45894&r=needscript Try newer version:http://bugs.php.net/fix.php?id=45894&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=45894&r=support Expected behavior:http://bugs.php.net/fix.php?id=45894&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=45894&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=45894&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=45894&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45894&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=45894&r=dst IIS Stability:http://bugs.php.net/fix.php?id=45894&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=45894&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=45894&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=45894&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=45894&r=mysqlcfg
