#26796 [Fbk->Opn]: PHP segfaults on pg_connect if SQLite is built in
ID: 26796
User updated by: arjen at glas dot its dot tudelft dot nl
Reported By: arjen at glas dot its dot tudelft dot nl
-Status: Feedback
+Status: Open
Bug Type: SQLite related
Operating System: Linux (gentoo 1.4)
PHP Version: 5CVS-2004-01-05 (dev)
New Comment:
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
)
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
)
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
) 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)
Previous Comments:
[2004-01-05 19:43:52] [EMAIL PROTECTED]
Change your CFLAGS and CXXFLAGS to
CFLAGS='g3 -pipe' \
CXXFLAGS='-g3 -pipe' \
Are you using apache2 with fork() or thread model?
--------
[2004-01-05 19:35:56] 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 18:23:53] [EMAIL PROTECTED]
Could you please compile PHP with debug symbols and try
again. That would make the backtrace much more informative.
[2004-01-05 13:05:27] 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
#26796 [Fbk->Opn]: PHP segfaults on pg_connect if SQLite is built in
ID: 26796 User updated by: arjen at glas dot its dot tudelft dot nl Reported By: arjen at glas dot its dot tudelft dot nl -Status: Feedback +Status: Open Bug Type: SQLite related Operating System: Linux (gentoo 1.4) PHP Version: 5CVS-2004-01-05 (dev) New Comment: 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. Previous Comments: [2004-01-05 18:23:53] [EMAIL PROTECTED] Could you please compile PHP with debug symbols and try again. That would make the backtrace much more informative. -------------------- [2004-01-05 13:05:27] 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 0x4058 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 -- Edit this bug report at http://bugs.php.net/?id=26796&edit=1
#26796 [NEW]: PHP segfaults on pg_connect if SQLite is built in
From: arjen at glas dot its dot tudelft dot nl Operating system: Linux (gentoo 1.4) PHP version: 5CVS-2004-01-05 (dev) PHP Bug Type: SQLite related Bug description: PHP segfaults on pg_connect if SQLite is built in 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 0x4058 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 -- Edit bug report at http://bugs.php.net/?id=26796&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26796&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26796&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26796&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26796&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26796&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=26796&r=needscript Try newer version: http://bugs.php.net/fix.php?id=26796&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26796&r=support Expected behavior: http://bugs.php.net/fix.php?id=26796&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26796&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26796&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26796&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26796&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26796&r=dst IIS Stability: http://bugs.php.net/fix.php?id=26796&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26796&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26796&r=float
#26325 [Com]: At least a notice when accessing private members in a derived class?
ID: 26325
Comment by: arjen at glas dot its dot tudelft dot nl
Reported By: drm at melp dot nl
Status: Open
Bug Type: Zend Engine 2 problem
Operating System: *
PHP Version: 5.0.0b2 (beta2)
New Comment:
I've tested this with php5-20031030 snapshot and I get two notices,
when using this code (which is correct):
member}, nonexistent
{$this->nonexistent}";
}
}
$o = new DeriveTest ();
echo $o, '';
highlight_file(__FILE__);
?>
It could, however, be done even better if it were a bit more
explainatory notice. Like Java's error for instance:
DeriveTest.java:5: member2 has private access in Test
return "Member contains: " + member2 + " and getMember
sais: " + nonexistent;
^
DeriveTest.java:5: cannot resolve symbol
symbol : variable nonexistent
location: class DeriveTest
return "Member contains: " + member2 + " and getMember
sais: " + nonexistent;
^
2 errors
I.e. a distinction between nonexistent members and private members.
Previous Comments:
[2003-12-17 12:06:25] drm at melp dot nl
sniper >
I tried the snapshot (labeled PHP/5.0.0b3-dev), but the problem
persists.
[2003-12-16 03:00:41] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
AFAICT, bug #26182 is fixed..so try the snapshot?
[2003-11-26 11:07:13] drm at melp dot nl
J > Sorry i reacted that way, I misinterpreted your post.
I cannot reproduce what you mean in PHP4. Can you give an example?
I tried some stuff, but all the versions i tried gave expected results.
Changing "private $member" into "var $member" or removing that line
completely results in:
-
Member contains: Test constructor, though getMember() says: Test
constructor?
Member contains: a, though getMember() says: a?
-
which is logical, since the member will be public as soon as you
introduce it, both with "var $member" and removing the line completely
(and initializing it in the Test constructor). When removing the
initialization in the Test constructor, the same notice as in the other
codesample will be produced. (Notice: Undefined property: member in
)
btw: i figure this hasn't got anything to do with the fact that I
tested on WinXP, maybe that should be changed to OS: irrelevant?
[2003-11-24 11:28:58] [EMAIL PROTECTED]
Take your original example and edit it so it works in PHP
4. It runs in both 4 and 5 without a notice. Based on your
original example code, that isn't "just plain bs."
Upon further inspection based on your second example,
there is definitely something weird going on here. This is
most likely related to #26182.
J
I'm not positive, but I think this may have something to
do with #26182.
J
[2003-11-22 18:57:46] drm at melp dot nl
You are right, i hadn't researched the problem that well, since i
assumed php5 would treat properties the php4-style the same way as php4
itself. But you are right; the code sample above when ran in php5
doesn't give a notice, though php4 does.
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/26325
--
Edit this bug report at http://bugs.php.net/?id=26325&edit=1
#26697 [NEW]: calling class_exists on a nonexistent class in __autoload results in segfault
From: arjen at glas dot its dot tudelft dot nl Operating system: Linux PHP version: 5CVS-2003-12-22 (dev) PHP Bug Type: Zend Engine 2 problem Bug description: calling class_exists on a nonexistent class in __autoload results in segfault Description: When calling class_exists on a nonexistent classname in __autoload, you'll get a segfault. This is in beta1, beta2 and beta3 (and now I had the time to create a testcase and do a report). Which ran under apache2 (2.0.48) on gentoo linux. And then I saw this report: http://bugs.php.net/bug.php?id=26630&edit=2 So I downloaded the php5-20031030 snapshot and there it also segfaults... Reproduce code: --- -- Edit bug report at http://bugs.php.net/?id=26697&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26697&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26697&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26697&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26697&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26697&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=26697&r=needscript Try newer version: http://bugs.php.net/fix.php?id=26697&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26697&r=support Expected behavior: http://bugs.php.net/fix.php?id=26697&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26697&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26697&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26697&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26697&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26697&r=dst IIS Stability: http://bugs.php.net/fix.php?id=26697&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26697&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26697&r=float
