php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #26796 SQLite causes crashes with other extensions *connect() calls
Submitted: 2004-01-05 13:05 UTC Modified: 2004-01-15 20:53 UTC
From: arjen at glas dot its dot tudelft dot nl Assigned:
Status: Closed Package: SQLite related
PHP Version: 5CVS-2004-01-11 OS: *
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem:
10 + 6 = ?
Subscribe to this entry?

 
 [2004-01-05 13:05 UTC] arjen at glas dot its dot tudelft dot nl
Description:
------------
I just did a default install of today's php-snapshot (php5-200401051230) in my apache2 and when a script came to its pg_connect, to open a postgresql connection, it segfaulted.

When I tried to debug that in gdb I saw a few sqlite-functions being mentioned, so I disabled the sqlite-extension and my scripts work perfectly now.

This issue was not there in php-5b3 and a snapshot of 22-12-2003

Actual result:
--------------
Below is the backtrace I got from gdb, when loading a single threaded debug apache (apache2 -X)

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 6588)]
0x4055bc0a in php_sqlite_callback_invalidator () from /etc/apache2/lib/apache2/libphp5.so
(gdb) bt
#0  0x4055bc0a in php_sqlite_callback_invalidator () from /etc/apache2/lib/apache2/libphp5.so
#1  0x4064479c in zend_hash_apply () from /etc/apache2/lib/apache2/libphp5.so
#2  0x4055abc4 in php_sqlite_forget_persistent_id_numbers () from /etc/apache2/lib/apache2/libphp5.so
#3  0x4064479c in zend_hash_apply () from /etc/apache2/lib/apache2/libphp5.so
#4  0x40555eb2 in zm_deactivate_sqlite () from /etc/apache2/lib/apache2/libphp5.so
#5  0x40641037 in module_registry_cleanup () from /etc/apache2/lib/apache2/libphp5.so
#6  0x4064479c in zend_hash_apply () from /etc/apache2/lib/apache2/libphp5.so
#7  0x4063da10 in zend_deactivate_modules () from /etc/apache2/lib/apache2/libphp5.so
#8  0x40605d89 in php_request_shutdown () from /etc/apache2/lib/apache2/libphp5.so
#9  0x40666658 in php_handler () from /etc/apache2/lib/apache2/libphp5.so
#10 0x080686b2 in ap_invoke_handler ()
#11 0x08065a2b in ap_process_request ()
#12 0x08060c7b in _start ()
#13 0x08072f85 in ap_process_connection ()
#14 0x0806818b in ap_graceful_stop_signalled ()
#15 0x0806755e in ap_graceful_stop_signalled ()
#16 0x08066e74 in ap_mpm_run ()
#17 0x0806e0e2 in main ()
#18 0x402f494c in __libc_start_main () from /lib/libc.so.6


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2004-01-05 18:23 UTC] iliaa@php.net
Could you please compile PHP with debug symbols and try 
again. That would make the backtrace much more informative. 
 [2004-01-05 19:35 UTC] arjen at glas dot its dot tudelft dot nl
I'm sorry, when compiling with debug-symbols (--enable-debug) it doesn't seem to happen...

Perhaps you can use this extra bit of information:
gcc = 3.3.2
glibc = 2.3.2
postgresql = 7.4.1
apache = 2.0.48

Even weirder, when I start apache2 -X, its opening two processes. The manager (I suppose) and one handler (I suppose). The manager process dies, the handler seems to survive (at least, the one with the higher pid and which is displayed in the ps xaufww output as the lower one).
When I attach gdb to that process, it doesn't really do anything, but if I attach gdb to the top process, it tells me there is a segfault and I can get the above stacktrace again.

If you have any clues in how to build a proper debuggable php, please let me know. My config.nice contains:
CFLAGS='-march=athlon-tbird -O3 -pipe' \
CXXFLAGS='-march=athlon-tbird -O3 -pipe' \
CC='gcc' \
CXX='g++' \
'./configure' \
'--with-apxs2=/usr/sbin/apxs2' \
'--with-zlib' \
'--with-mysql' \
'--with-pgsql'

I'll check whether it works correctly without the parameters, but they shouldn't make any difference.
 [2004-01-05 19:43 UTC] iliaa@php.net
Change your CFLAGS and CXXFLAGS to 
 
CFLAGS='g3 -pipe' \ 
CXXFLAGS='-g3 -pipe' \ 
 
Are you using apache2 with fork() or thread model? 
 [2004-01-06 05:49 UTC] arjen at glas dot its dot tudelft dot nl
Ok, it's a bit clearer now:
Program received signal SIGSEGV, Segmentation fault.
0x4055e425 in php_sqlite_callback_invalidator (funcs=0x0) at /home/acm/source/php5-200401051230/ext/sqlite/sqlite.c:289
289             if (!funcs->is_valid) {
(gdb) bt
#0  0x4055e425 in php_sqlite_callback_invalidator (funcs=0x0) at /home/acm/source/php5-200401051230/ext/sqlite/sqlite.c:289
#1  0x40673df6 in zend_hash_apply (ht=0x81c9940, apply_func=0x4055e410 <php_sqlite_callback_invalidator>)
    at /home/acm/source/php5-200401051230/Zend/zend_hash.c:658
#2  0x4055e6be in php_sqlite_forget_persistent_id_numbers (rsrc=0x819f3c8) at /home/acm/source/php5-200401051230/ext/sqlite/sqlite.c:379
#3  0x40673df6 in zend_hash_apply (ht=0x406f5418, apply_func=0x4055e68c <php_sqlite_forget_persistent_id_numbers>)
    at /home/acm/source/php5-200401051230/Zend/zend_hash.c:658
#4  0x4055e74e in zm_deactivate_sqlite (type=1, module_number=4) at /home/acm/source/php5-200401051230/ext/sqlite/sqlite.c:395
#5  0x40670718 in module_registry_cleanup (module=0x818d9c8) at /home/acm/source/php5-200401051230/Zend/zend_API.c:1411
#6  0x40673df6 in zend_hash_apply (ht=0x406f5540, apply_func=0x406706d5 <module_registry_cleanup>) at /home/acm/source/php5-200401051230/Zend/zend_hash.c:658
#7  0x4066c2eb in zend_deactivate_modules () at /home/acm/source/php5-200401051230/Zend/zend.c:797
#8  0x4062a32b in php_request_shutdown (dummy=0x0) at /home/acm/source/php5-200401051230/main/main.c:1228
#9  0x406994ce in php_apache_request_dtor (r=0x81c4c78) at /home/acm/source/php5-200401051230/sapi/apache2handler/sapi_apache2.c:443
#10 0x406998b7 in php_handler (r=0x81c4c78) at /home/acm/source/php5-200401051230/sapi/apache2handler/sapi_apache2.c:547
#11 0x080686b2 in ap_invoke_handler ()
#12 0x08065a2b in ap_process_request ()
#13 0x08060c7b in _start ()
#14 0x08072f85 in ap_process_connection ()
#15 0x0806818b in ap_graceful_stop_signalled ()
#16 0x0806755e in ap_graceful_stop_signalled ()
#17 0x08066e74 in ap_mpm_run ()
#18 0x0806e0e2 in main ()
#19 0x402f494c in __libc_start_main () from /lib/libc.so.6


And as far as I can tell, I'm running the prefork model, although gdb does claim a thread gets forked off ?? (but from what I can tell from the configuration-line in gentoo's ebuild and the output of ps, it should be the prefork model)
 [2004-01-11 10:31 UTC] sniper@php.net
See also bug #26852


 [2004-01-15 20:53 UTC] iliaa@php.net
This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.


 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Apr 19 15:01:28 2024 UTC