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
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
Previous Comments:
------------------------------------------------------------------------
[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! :-)
------------------------------------------------------------------------
[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).
------------------------------------------------------------------------
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
