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 <?php and ends 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...

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

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...

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... 

<?php
$conn = new PDO('sqlite::memory:');
$sql = "SELECT name FROM sqlite_master WHERE type='table' ORDER BY name;";
$conn->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.

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.

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

Let's see the backtrace(s) for the problems here, before deciding what else to do.

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

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).

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! :-)

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.

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?

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.

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

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...

The problem only occurs when the default argument is either NULL or FALSE:

rgb2hex($rgb, $g=34)    // fine
rgb2hex($rgb, $g=0)     // fine
rgb2hex($rgb, $g='')    // fine
rgb2hex($rgb, $g=false) // leak!
rgb2hex($rgb, $g=null)  // leak!

We're not getting any useful information out of this report, marking it as bogus.

If you think the problem is PDO related, then reopen this report with a short (20 lines max) self-contained script that can be used to reproduce the problem.

If you think you've found a different bug, then open a new report and provide a short (20 lines max) self contained script that can be used to reproduce it.

The key here is that we can't read your mind and guess what you're up to, and you don't seem to be able to give us the reproducing script that we keep asking for.