ID: 33737
User updated by: leon at lost dot co dot nz
-Summary: PDO::SQLite crashes
Reported By: leon at lost dot co dot nz
Status: Open
Bug Type: PDO related
Operating System: Linux 2.6 / Apache2
PHP Version: PHP 5 CVS
Assigned To: wez
New Comment:
I'm now pretty sure this thread has been chasing two bugs, the first of
which was promptly squashed by wez.
It looks like the second bug has nothing to do with PDO.
The second bug reared it's head once again this morning when I was
tooling around with some text manipulation classes. One minute
everything was fine, then I added a default argument to one of my
functions. Suddenly I was in memory leak city!
I then removed all default arguments from the SQLite wrapper class and
the leak there disapeared too...
Perhaps we should close this bug and open a new one? (I didn't find
any other bugs relating to default arguments while searching just
now.)
I'm trying to write a test snippet but so far everything works nicely
without the complications of the full app... I'll keep trying...
Previous Comments:
------------------------------------------------------------------------
[2005-07-21 04:31:32] leon at lost dot co dot nz
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
3786 yy_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 0x00000004 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
==7361== at 0x1B904F75: calloc (vg_replace_malloc.c:175)
==7361== by 0x1B8F2678: (within /lib/ld-2.3.2.so)
==7361== by 0x1B8F294B: _dl_allocate_tls (in /lib/ld-2.3.2.so)
==7361== by 0x1BB9B24A: allocate_stack (in
/lib/tls/libpthread-0.60.so)
==7361== by 0x1BB9AC54: pthread_create@@GLIBC_2.1 (in
/lib/tls/libpthread-0.60.so)
==7361== by 0x8113634: testThreadLockingBehavior (os_unix.c:300)
==7361== by 0x81139C4: findLockInfo (os_unix.c:357)
==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== LEAK SUMMARY:
==7361== definitely lost: 0 bytes in 0 blocks.
==7361== possibly lost: 136 bytes in 2 blocks.
==7361== still reachable: 128 bytes in 2 blocks.
==7361== suppressed: 0 bytes in 0 blocks.
Let me know if you want the script and I'll email it to you.
Cheers,
Leon
------------------------------------------------------------------------
[2005-07-21 02:04:17] [EMAIL PROTECTED]
Could you plz try to build PHP with --enable-debug &&
--disable-zend-memory-manager and run the same script through valgrind:
valgrind --tool=memcheck --leak-check=yes --num-callers=30
--show-reachable=yes php /path/to/script.php
That should give us enough information, I hope.
But some reproduce script would be really nice to have, this will
definitely help to fix the bug.
Thanks.
------------------------------------------------------------------------
[2005-07-21 01:47:31] leon at lost dot co dot nz
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 'ZZZZ' changes):
Warning: String is not zero-terminated
(ZZZZ�̏**̏*�) (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?
------------------------------------------------------------------------
[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
(ZZZZ�̏**̏*�) (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! :-)
------------------------------------------------------------------------
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
