php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #33737 Only when default args are false or null
Submitted: 2005-07-17 23:44 UTC Modified: 2005-07-22 03:05 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:0 of 0 (0.0%)
From: leon at lost dot co dot nz Assigned: wez (profile)
Status: Not a bug Package: PDO related
PHP Version: PHP 5 CVS OS: Linux 2.6 / Apache2
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem:
6 + 29 = ?
Subscribe to this entry?

 
 [2005-07-17 23:44 UTC] leon at lost dot co dot nz
Description:
------------
My fairly complex object orientated PHP5 app consistently segfaults when trying to run code with particular parameters.

I've been trying to fix this problem since 5.1b1, through lots of recent CVS snapshots, and now this morning with 5.1b3 -- I'm now pretty sure it's a PHP problem.



The code in question is my apps unit test framework.

A tester object dynamically creates instances of my application's objects as well as a test class for each app. object. The tester runs methods in the test class against the app. object.

$testObject = new $testClassName();

The same page is run with the names of class to be tested as a parameter.  Currently, it consistantly segfaults when trying to test my PDO SQLite wrapper, although it is giving 'unusual' warnings (I suspect memory corruption, for reasons given below) when testing another object (a mcrypt wrapper):

NOTICE: Use of undefined constant  - assumed ''

There are about 20 other objects that test fine.








Reproduce code:
---------------
Unfortunately I have not been able to produce a snippet that reproduces the behaviour -- the same PHP code seems to work great with some inputs.

I'm not sure what more to do for now.  I'll run whatever tests you like to try to get to the bottom of the problem.

Actual result:
--------------
As well as the segfault described above I have also seen, with the same test, memory corruption in a previous snapshot of PHP5.1 -- PHP 'notices' about undefined constants where the constants are long strings of what looked like completely random data.

Backtrace of last segfault:
--------------------------

# gdb /usr/sbin/apache2
...
(gdb) run -X
....
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1214132096 (LWP 8340)]
_efree (ptr=0x0) at /tmp/nz.php.net/distributions/php-5.1.0b3/Zend/zend_alloc.c:285
285             CALCULATE_REAL_SIZE_AND_CACHE_INDEX(p->size);

(gdb) bt
#0  _efree (ptr=0x0) at /tmp/nz.php.net/distributions/php-5.1.0b3/Zend/zend_alloc.c:285
#1  0xb775e7ee in free_statement (stmt=0x8337d4c, tsrm_ls=0x8168258)
    at /tmp/nz.php.net/distributions/php-5.1.0b3/ext/pdo/pdo_stmt.c:1937
#2  0xb78bf664 in zend_objects_store_del_ref (zobject=0x8339484, tsrm_ls=0x8168258)
    at /tmp/nz.php.net/distributions/php-5.1.0b3/Zend/zend_objects_API.c:161
#3  0xb78a5b14 in _zval_dtor_func (zvalue=0x8339484)
    at /tmp/nz.php.net/distributions/php-5.1.0b3/Zend/zend_variables.c:52
#4  0xb775a585 in zif_PDO_query (ht=1, return_value=0x8339484,
    return_value_ptr=0x8168258, this_ptr=0xb792b3d0, return_value_used=135692888,
    tsrm_ls=0x8168258) at zend_variables.h:35
#5  0xb78cd42a in zend_do_fcall_common_helper_SPEC (execute_data=0xbfa97f80,
    tsrm_ls=0x8168258) at zend_vm_execute.h:184
#6  0xb78ccb2c in execute (op_array=0x82ee674, tsrm_ls=0x8168258)
    at zend_vm_execute.h:87
#7  0xb78cd14b in zend_do_fcall_common_helper_SPEC (execute_data=0xbfa98150,
    tsrm_ls=0x8168258) at zend_vm_execute.h:213
#8  0xb78ccb2c in execute (op_array=0x82f161c, tsrm_ls=0x8168258)
    at zend_vm_execute.h:87
#9  0xb78cd14b in zend_do_fcall_common_helper_SPEC (execute_data=0xbfa98270,
    tsrm_ls=0x8168258) at zend_vm_execute.h:213
#10 0xb78ccb2c in execute (op_array=0x82f12e4, tsrm_ls=0x8168258)
    at zend_vm_execute.h:87
#11 0xb78cd14b in zend_do_fcall_common_helper_SPEC (execute_data=0xbfa985c0,
    tsrm_ls=0x8168258) at zend_vm_execute.h:213
#12 0xb78ccb2c in execute (op_array=0x83295ec, tsrm_ls=0x8168258)

    at zend_vm_execute.h:87
#13 0xb78cd14b in zend_do_fcall_common_helper_SPEC (execute_data=0xbfa98bf0,
    tsrm_ls=0x8168258) at zend_vm_execute.h:213
#14 0xb78ccb2c in execute (op_array=0x83163bc, tsrm_ls=0x8168258)
    at zend_vm_execute.h:87
#15 0xb78cd14b in zend_do_fcall_common_helper_SPEC (execute_data=0xbfa98e00,
    tsrm_ls=0x8168258) at zend_vm_execute.h:213
#16 0xb78ccb2c in execute (op_array=0x82df884, tsrm_ls=0x8168258)
    at zend_vm_execute.h:87
#17 0xb78cd14b in zend_do_fcall_common_helper_SPEC (execute_data=0xbfa98f10,
    tsrm_ls=0x8168258) at zend_vm_execute.h:213
#18 0xb78ccb2c in execute (op_array=0x82df5a4, tsrm_ls=0x8168258)
    at zend_vm_execute.h:87
#19 0xb78cd14b in zend_do_fcall_common_helper_SPEC (execute_data=0xbfa99400,
    tsrm_ls=0x8168258) at zend_vm_execute.h:213
#20 0xb78ccb2c in execute (op_array=0x830dc34, tsrm_ls=0x8168258)
    at zend_vm_execute.h:87
#21 0xb78cd14b in zend_do_fcall_common_helper_SPEC (execute_data=0xbfa995d0,
    tsrm_ls=0x8168258) at zend_vm_execute.h:213
#22 0xb78ccb2c in execute (op_array=0x82e008c, tsrm_ls=0x8168258)
    at zend_vm_execute.h:87
#23 0xb78cd14b in zend_do_fcall_common_helper_SPEC (execute_data=0xbfa99fb0,
    tsrm_ls=0x8168258) at zend_vm_execute.h:213
#24 0xb78ccb2c in execute (op_array=0x8297b8c, tsrm_ls=0x8168258)
    at zend_vm_execute.h:87
#25 0xb78ddf25 in ZEND_INCLUDE_OR_EVAL_SPEC_VAR_HANDLER (execute_data=0xbfa9a370,
    tsrm_ls=0x8168258) at zend_vm_execute.h:7345
#26 0xb78ccb2c in execute (op_array=0x826f764, tsrm_ls=0x8168258)
    at zend_vm_execute.h:87
#27 0xb78ddf25 in ZEND_INCLUDE_OR_EVAL_SPEC_VAR_HANDLER (execute_data=0xbfa9a660,
    tsrm_ls=0x8168258) at zend_vm_execute.h:7345
#28 0xb78ccb2c in execute (op_array=0x828ce04, tsrm_ls=0x8168258)
    at zend_vm_execute.h:87
#29 0xb78cd14b in zend_do_fcall_common_helper_SPEC (execute_data=0xbfa9a910,
    tsrm_ls=0x8168258) at zend_vm_execute.h:213
---Type <return> to continue, or q <return> to quit---
#30 0xb78ccb2c in execute (op_array=0x8288754, tsrm_ls=0x8168258)
    at zend_vm_execute.h:87
#31 0xb78cd14b in zend_do_fcall_common_helper_SPEC (execute_data=0xbfa9b110,
    tsrm_ls=0x8168258) at zend_vm_execute.h:213
#32 0xb78ccb2c in execute (op_array=0x827a9ac, tsrm_ls=0x8168258)
    at zend_vm_execute.h:87
#33 0xb78cd14b in zend_do_fcall_common_helper_SPEC (execute_data=0xbfa9b250,
    tsrm_ls=0x8168258) at zend_vm_execute.h:213
#34 0xb78ccb2c in execute (op_array=0x82693bc, tsrm_ls=0x8168258)
    at zend_vm_execute.h:87
#35 0xb78a81ec in zend_execute_scripts (type=8, tsrm_ls=0x8168258, retval=0x0,
    file_count=3) at /tmp/nz.php.net/distributions/php-5.1.0b3/Zend/zend.c:1087
#36 0xb7868604 in php_execute_script (primary_file=0xbfa9d5e0, tsrm_ls=0x8168258)
    at /tmp/nz.php.net/distributions/php-5.1.0b3/main/main.c:1672
#37 0xb7922b07 in php_handler (r=0x82581e0)
    at /tmp/nz.php.net/distributions/php-5.1.0b3/sapi/apache2handler/sapi_apache2.c:555
#38 0x080783a5 in ap_run_handler ()
#39 0x080789b0 in ap_invoke_handler ()
#40 0x08069c9a in ap_process_request ()
#41 0x0806512d in _start ()
#42 0x082581e0 in ?? ()
#43 0x00000004 in ?? ()
#44 0x082581e0 in ?? ()
#45 0x0808373c in ap_run_pre_connection ()
#46 0x080835f5 in ap_run_process_connection ()
#47 0x080769a4 in ap_graceful_stop_signalled ()
#48 0x08076bbb in ap_graceful_stop_signalled ()
#49 0x08076c18 in ap_graceful_stop_signalled ()
#50 0x0807748a in ap_mpm_run ()
#51 0x0807dabd in main ()
(gdb) 

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2005-07-17 23:48 UTC] derick@php.net
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...
 [2005-07-18 00:14 UTC] 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-18 00:39 UTC] 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 01:31 UTC] 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... 

<?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.
 [2005-07-18 16:49 UTC] wez@php.net
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 22:59 UTC] 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 23:15 UTC] wez@php.net
Let's see the backtrace(s) for the problems here, before deciding what else to do.
 [2005-07-18 23:45 UTC] 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-20 01:22 UTC] 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-20 02:01 UTC] 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&#65533;&#783;**&#783;*&#65533;) (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 03:03 UTC] wez@php.net
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-21 01:47 UTC] 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&#65533;&#783;**&#783;*&#65533;) (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-21 02:04 UTC] tony2001@php.net
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 04:31 UTC] 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-22 01:39 UTC] leon at lost dot co dot nz
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...
 [2005-07-22 01:45 UTC] leon at lost dot co dot nz
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!
 [2005-07-22 03:05 UTC] wez@php.net
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.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Mar 28 23:01:26 2024 UTC