#33737 [Fbk->Opn]: PDO::SQLite crashes
ID: 33737 User updated by: leon at lost dot co dot nz Reported By: leon at lost dot co dot nz -Status: Feedback +Status: Open Bug Type: PDO related Operating System: Linux 2.6 / Apache2 PHP Version: PHP 5 CVS Assigned To: wez New Comment: Thanks Tony. With the suggested build it took three refreshes of the unit test page while running Apache from gdb to cause a segfault. Here is the back trace from that: # gdb /usr/sbin/apache2 (gdb) run -X ... Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1214533504 (LWP 7300)] 0xb780e9ae in lex_scan (zendlval=0xbfd38934, tsrm_ls=0x8168258) at Zend/zend_language_scanner.c:3786 3786yy_current_state += YY_AT_BOL(); (gdb) bt #0 0xb780e9ae in lex_scan (zendlval=0xbfd38934, tsrm_ls=0x8168258) at Zend/zend_language_scanner.c:3786 #1 0xb781ffd9 in zendlex (zendlval=0xbfd38930, tsrm_ls=0x8168258) at /tmp/php5-200507192230/Zend/zend_compile.c:3886 #2 0xb780dc61 in zendparse (tsrm_ls=0x8168258) at Zend/zend_language_parser.c:2263 #3 0xb780e1ac in compile_file (file_handle=0xbfd3ad30, type=2, tsrm_ls=0x8168258) at Zend/zend_language_scanner.c:3166 #4 0xb782ee51 in zend_execute_scripts (type=8, tsrm_ls=0x8168258, retval=0x0, file_count=3) at /tmp/php5-200507192230/Zend/zend.c:1079 #5 0xb77ebda4 in php_execute_script (primary_file=0xbfd3ad30, tsrm_ls=0x8168258) at /tmp/php5-200507192230/main/main.c:1672 #6 0xb78b2cf7 in php_handler (r=0x8258d60) at /tmp/php5-200507192230/sapi/apache2handler/sapi_apache2.c:555 #7 0x080783a5 in ap_run_handler () #8 0x080789b0 in ap_invoke_handler () #9 0x08069c9a in ap_process_request () #10 0x0806512d in _start () #11 0x08258d60 in ?? () #12 0x0004 in ?? () #13 0x08258d60 in ?? () #14 0x0808373c in ap_run_pre_connection () #15 0x080835f5 in ap_run_process_connection () #16 0x080769a4 in ap_graceful_stop_signalled () #17 0x08076bbb in ap_graceful_stop_signalled () #18 0x08076c18 in ap_graceful_stop_signalled () #19 0x0807748a in ap_mpm_run () #20 0x0807dabd in main () Next I did the valgrind using the CLI version of php. The script 'test.php' contains all the classes that the dynamic page uses. I can make this availiable if you like, although not here; it's 13kB. $ valgrind --tool=memcheck --leak-check=yes --num-callers=30 --show-reachable=yes php test.php ==7361== Memcheck, a memory error detector for x86-linux. ==7361== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al. ==7361== Using valgrind-2.4.0, a program supervision framework for x86-linux. ==7361== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al. ==7361== For more details, rerun with: -v ==7361== ==7361== ==7361== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 43 from 3) ==7361== malloc/free: in use at exit: 264 bytes in 4 blocks. ==7361== malloc/free: 160443 allocs, 160439 frees, 19203977 bytes allocated. ==7361== For counts of detected errors, rerun with: -v ==7361== searching for pointers to 4 not-freed blocks. ==7361== checked 17850632 bytes. ==7361== ==7361== 128 bytes in 2 blocks are still reachable in loss record 1 of 2 ==7361==at 0x1B90459D: malloc (vg_replace_malloc.c:130) ==7361==by 0x8127CC6: sqlite3Malloc (util.c:271) ==7361==by 0x810F188: rehash (hash.c:225) ==7361==by 0x810F5D5: sqlite3HashInsert (hash.c:371) ==7361==by 0x8113972: findLockInfo (os_unix.c:373) ==7361==by 0x8113A8D: sqlite3OsOpenReadWrite (os_unix.c:463) ==7361==by 0x8116D0B: sqlite3pager_open (pager.c:1618) ==7361==by 0x80FA240: sqlite3BtreeOpen (btree.c:1228) ==7361==by 0x8112B76: sqlite3BtreeFactory (main.c:586) ==7361==by 0x8112FDF: openDatabase (main.c:716) ==7361==by 0x80F7619: pdo_sqlite_handle_factory (sqlite_driver.c:701) ==7361==by 0x80EE7DC: zif_dbh_constructor (pdo_dbh.c:374) ==7361==by 0x8282947: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:184) ==7361==by 0x8281FAB: execute (zend_vm_execute.h:87) ==7361==by 0x8282640: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:213) ==7361==by 0x8281FAB: execute (zend_vm_execute.h:87) ==7361==by 0x8282640: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:213) ==7361==by 0x8281FAB: execute (zend_vm_execute.h:87) ==7361==by 0x8282640: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:213) ==7361==by 0x8281FAB: execute (zend_vm_execute.h:87) ==7361==by 0x8282640: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:213) ==7361==by 0x8281FAB: execute (zend_vm_execute.h:87) ==7361==by 0x8282640: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:213) ==7361==by 0x8281FAB: execute (zend_vm_execute.h:87) ==7361==by 0x825B91B: zend_execute_scripts (zend.c:1087) ==7361==by 0x8218813: php_execute_script (main.c:1672) ==7361==by 0x82DFDBA: main (php_cli.c:1039) ==7361== ==7361== ==7361== 136 bytes in 2 blocks are possibly lost in loss record 2 of 2 ==7
#33737 [Fbk->Opn]: PDO::SQLite crashes
ID: 33737 User updated by: leon at lost dot co dot nz Reported By: leon at lost dot co dot nz -Status: Feedback +Status: Open Bug Type: PDO related Operating System: Linux 2.6 / Apache2 PHP Version: PHP 5 CVS Assigned To: wez New Comment: It's a little disheartening to put so much work into bug hunting to be given the proverbial cold shoulder of the canned response above... Anyway, to review: When built with --enable-debug PHP doesn't segfault, instead it prints the warning message I quoted before (every single time, though the part after '' changes): Warning: String is not zero-terminated (�̏**̏*�) (source: /tmp/php5-200507192230/Zend/zend_variables.h:35) in Unknown on line 0 How can I send a useful backtrace from this? I've been trying all morning to put together a single script that would replicate the problem, but nothing but the original seem to cause the problem. What would you like me to do? Previous Comments: [2005-07-20 03:03:28] [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 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. Need a backtrace and/or a short, self-contained reproducing test case; when you can provide either or both of these, re-open this report. Until then, your comments won't really help us to track down the problem. [2005-07-20 02:01:37] leon at lost dot co dot nz Just rebuilt the above build with --enable-debug to try to generate a backtrace for you. It has so far refused to segfault, but I am getting this error appearing on the end of my unit-test page: Warning: String is not zero-terminated (�̏**̏*�) (source: /tmp/php5-200507192230/Zend/zend_variables.h:35) in Unknown on line 0 Needless to say, I don't have any variables that look even close to that! :-) [2005-07-20 01:22:40] leon at lost dot co dot nz Tried again this morning with CVS snapshot php5-200507192230. Same install routine which, this time, created and install the .so file properly. My test script now works fine, and I can run the unit tests successfully. Big improvement! However... I'm still getting intermittent (like about half of the time I run the PDO::SQLite tests) segfaults reported in Apache's error log. Prehaps more worryingly, after trying to run the SQLite unit tests for a while, I have seen what looks like some of the apache2 stuck in infinite loops (three processs each using ~33% CPU -- I'm using the Apache2 prefork MPM with APXS2 to build PHP). [2005-07-18 23:45:06] leon at lost dot co dot nz Hmmm... I think something screwy happened with the install of the latest snapshot, making my last (good news/bad news) report suspect. I did my usual install routine (on Debian 3.1): make apache2ctl stop make install apache2ctl start Then tested the snippet using the CLI: $ php -v PHP 5.1.0-dev (cli) (built: Jul 19 2005 08:45:23 NZ) $ php test.php $ (no segfault!) The 'bad news' came when I browsed to the unit test page normally -- but on further investigation it seems that the normal install process failed on the snapshot. For some reason 'make install' put the files libphp5.[a|la] in my /usr/lib/apache2/modules, rather than the usual libphp5.so... Has the build process changed, or have I done something stupid? ;-) ./configure --with-apxs2=/usr/bin/apxs2 \ --with-config-file-dir=/etc/php --with-mcrypt --with-gd \ --with-zlib --enable-exif --with-freetype-dir \ --with-jpeg-dir --enable-debug [2005-07-18 23:15:18] [EMAIL PROTECTED] Let's see the backtrace(s) for the problems here, before deciding what else to do. 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/33737 -- Edit this bug report at http://bugs.php.net/?id=33737&edit=1
#33737 [Fbk->Opn]: PDO::SQLite crashes
ID: 33737 User updated by: leon at lost dot co dot nz Reported By: leon at lost dot co dot nz -Status: Feedback +Status: Open Bug Type: PDO related Operating System: Linux 2.6 / Apache2 PHP Version: PHP 5 CVS Assigned To: wez New Comment: Hmmm... I think something screwy happened with the install of the latest snapshot, making my last (good news/bad news) report suspect. I did my usual install routine (on Debian 3.1): make apache2ctl stop make install apache2ctl start Then tested the snippet using the CLI: $ php -v PHP 5.1.0-dev (cli) (built: Jul 19 2005 08:45:23 NZ) $ php test.php $ (no segfault!) The 'bad news' came when I browsed to the unit test page normally -- but on further investigation it seems that the normal install process failed on the snapshot. For some reason 'make install' put the files libphp5.[a|la] in my /usr/lib/apache2/modules, rather than the usual libphp5.so... Has the build process changed, or have I done something stupid? ;-) ./configure --with-apxs2=/usr/bin/apxs2 \ --with-config-file-dir=/etc/php --with-mcrypt --with-gd \ --with-zlib --enable-exif --with-freetype-dir \ --with-jpeg-dir --enable-debug Previous Comments: [2005-07-18 23:15:18] [EMAIL PROTECTED] Let's see the backtrace(s) for the problems here, before deciding what else to do. [2005-07-18 22:59:55] leon at lost dot co dot nz Just rebuilt and retested with php5-200507182030, thanks for the quick response! I've got good news and bad news: The good news is that the latest snapshot doesn't segfault on the test snippet above. The bad news is that my full unit tests still cause PHP to segfault on the SQLite tests... What would you like me to do? I could: 1) Put together another snippet and post it here 2) As above, but create a new bug report 3) Post my classes somewhere for you to look at directly Cheers, Leon [2005-07-18 16:49:44] [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 Works for me with CVS HEAD. Please try the snap dated after this message to confirm. [2005-07-18 01:31:49] leon at lost dot co dot nz Whew... All done... I've pared my script from > 1800 lines of PHP scattered accross 7 files to three lines in one file! Turns out to be a SQLite PDO problem... query($sql); ?> This snippet causes PHP5.1b3 to segfault everytime (I'm using the bundled SQLite library). One of my other unit tests still throws up that corruption I talked about before, but I'll try to isolate that and submit a brand new bug report for that. [2005-07-18 00:39:46] leon at lost dot co dot nz Yahoo! I couldn't wait, and have already produced a single PHP file that segfaults the command line version of PHP-5.1b3 routinely. If you want it now let me know -- I'm currently just in the process of trying to whittle it down to it's essential elements... 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/33737 -- Edit this bug report at http://bugs.php.net/?id=33737&edit=1
#33737 [Fbk->Opn]: PDO::SQLite crashes
ID: 33737 User updated by: leon at lost dot co dot nz Reported By: leon at lost dot co dot nz -Status: Feedback +Status: Open Bug Type: PDO related Operating System: Linux 2.6 / Apache2 PHP Version: 5.1.0b2 Assigned To: wez New Comment: Just rebuilt and retested with php5-200507182030, thanks for the quick response! I've got good news and bad news: The good news is that the latest snapshot doesn't segfault on the test snippet above. The bad news is that my full unit tests still cause PHP to segfault on the SQLite tests... What would you like me to do? I could: 1) Put together another snippet and post it here 2) As above, but create a new bug report 3) Post my classes somewhere for you to look at directly Cheers, Leon Previous Comments: [2005-07-18 16:49:44] [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 Works for me with CVS HEAD. Please try the snap dated after this message to confirm. [2005-07-18 01:31:49] leon at lost dot co dot nz Whew... All done... I've pared my script from > 1800 lines of PHP scattered accross 7 files to three lines in one file! Turns out to be a SQLite PDO problem... query($sql); ?> This snippet causes PHP5.1b3 to segfault everytime (I'm using the bundled SQLite library). One of my other unit tests still throws up that corruption I talked about before, but I'll try to isolate that and submit a brand new bug report for that. [2005-07-18 00:39:46] leon at lost dot co dot nz Yahoo! I couldn't wait, and have already produced a single PHP file that segfaults the command line version of PHP-5.1b3 routinely. If you want it now let me know -- I'm currently just in the process of trying to whittle it down to it's essential elements... [2005-07-18 00:14:08] leon at lost dot co dot nz Okay, I understand. It's going to be tough -- I have objects creating other objects, dynamically including other class files, etc..., but I'll give it another crack tonight (New Zealand time). Cheers, Leon [2005-07-17 23:48:18] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. We really need a reproducable script... 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/33737 -- Edit this bug report at http://bugs.php.net/?id=33737&edit=1