#34844 [Com]: PHP 5.1.0RC1 Make Fails on OS X
ID: 34844 Comment by: leon at lost dot co dot nz Reported By: admin at allthingsinteresting dot com Status: Feedback Bug Type: Compile Failure Operating System: Mac OS X PHP Version: 5.1.0RC1 New Comment: I've been using PHP 5.1rc1 on my iBook no problems -- with 10.3, and more recently, 10.4 using fink with the following config flags: ./configure --with-apxs --with-mcrypt=/sw --with-libxml- dir=/sw --with-gd --with-zlib --enable-exif --with-freetype- dir=/sw/lib/freetype2 --with-jpeg-dir=/sw --with-png-dir=/sw --without-pear --enable-pspell --enable-wddx (/sw is fink's prefix, BTW, and the XML2 version provided by fink is 2.6.20) Previous Comments: [2005-10-14 14:21:39] [EMAIL PROTECTED] `/usr/bin/xml2-config --version` should the version number. I'm not sure xml2-config is under /usr/bin/ in MacOS, so you should find it yourself. [2005-10-13 16:25:18] admin at allthingsinteresting dot com How Do I tell? I would be perfectly glad to disable it, if I knew how... [2005-10-13 10:44:22] [EMAIL PROTECTED] Which version of libxml2 you have in your system? [2005-10-13 01:32:39] admin at allthingsinteresting dot com The snapshot is suffering with the same xml parser bug, at least on my computer. [2005-10-13 00:29:09] [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 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/34844 -- Edit this bug report at http://bugs.php.net/?id=34844edit=1
#34078 [Asn]: Reflection API problems in methods with boolean or null default values
ID: 34078
User updated by: leon at lost dot co dot nz
Reported By: leon at lost dot co dot nz
Status: Assigned
Bug Type: Scripting Engine problem
Operating System: Debian Sarge (2.6.12 kernel)
PHP Version: 5CVS-2005-08-11 (dev)
Assigned To: tony2001
New Comment:
Great work!
I can understand you having to wait to merge into the 5.5/6.0 series,
but it would be great if the fix could be pushed into just the 5.1 tree
before the next release (beta4? rc4?).
We -- like many other companies -- are waiting for the 5.1 release to
move everything from PHP4 to PHP5. Unfortunately this bug is a 'show
stopper' for us right now.
Previous Comments:
[2005-08-11 12:50:22] [EMAIL PROTECTED]
The fix is ready, but we have to wait for Andrey Dmitry to finish
merging of Unicode patches.
[2005-08-11 03:37:24] leon at lost dot co dot nz
Description:
This problem came up when moving our homebrew 'PHPDoc' type class to
PHP5.1. When built with --enable-debug PHP throws up warnings up when
the class to be documented ('A' below) contains methods with default
values that are either NULL or boolean
In the code snippet below we get two warnings, one for each default
parameter. Changing the default values to a string or number (even
zero) eliminates the warnings.
This is a serious problem for us. When documenting some of our bigger
classes we have seen lots of 'odd' behaviour, including permanent 100%
CPU usage by Apache! It has taken *days* to track down the problem to
the snippet below. If there is anything elso I can do to help fix it
please let me know...
Reproduce code:
---
$r = new ReflectionClass('A');
$methods = $r-getMethods();
foreach($methods as $method)
{
$parameters = $method-getParameters();
foreach($parameters as $p)
{
if($p-isDefaultValueAvailable())
$p-getDefaultValue();
}
}
class A
{
function foo($p=null, $q=false)
{
}
}
Expected result:
No output at all -- I've trimed all the output code out.
Actual result:
--
$ php bug2.php
Warning: String is not zero-terminated (ZÌ*) (source:
/tmp/php5-200508110030/Zend/zend_variables.h:35) in Unknown on line 0
[Thu Aug 11 13:18:58 2005] Script: 'bug2.php'
---
/tmp/php5-200508110030/Zend/zend_variables.h(35) : Block 0x08514F30
status:
/tmp/php5-200508110030/Zend/zend_variables.c(36) : Actual location
(location was relayed)
Beginning: Cached (allocated on Zend/zend_language_scanner.c:4689,
5 bytes)
End: OK
---
Warning: String is not zero-terminated (ZZÌ*) (source:
/tmp/php5-200508110030/Zend/zend_variables.h:35) in Unknown on line 0
[Thu Aug 11 13:18:58 2005] Script: 'bug2.php'
---
/tmp/php5-200508110030/Zend/zend_variables.h(35) : Block 0x085150C8
status:
/tmp/php5-200508110030/Zend/zend_variables.c(36) : Actual location
(location was relayed)
Beginning: Cached (allocated on Zend/zend_language_scanner.c:4689,
6 bytes)
End: OK
---
--
Edit this bug report at http://bugs.php.net/?id=34078edit=1
#34078 [Asn]: Reflection API problems in methods with boolean or null default values
ID: 34078
User updated by: leon at lost dot co dot nz
Reported By: leon at lost dot co dot nz
Status: Assigned
Bug Type: Scripting Engine problem
Operating System: Debian Sarge (2.6.12 kernel)
PHP Version: 5CVS-2005-08-11 (dev)
Assigned To: tony2001
New Comment:
As Homer would say: Woo-hoo! You absolutely rock! I just can't wait
for the next 5.1 snapshot... :-)
Previous Comments:
[2005-08-11 23:18:55] [EMAIL PROTECTED]
Okay, I discussed it with Marcus and committed the fix to 5.0 5.1
branches.
I'll commit it to 6.0 too when I'll be able to do it.
[2005-08-11 22:47:22] leon at lost dot co dot nz
Great work!
I can understand you having to wait to merge into the 5.5/6.0 series,
but it would be great if the fix could be pushed into just the 5.1 tree
before the next release (beta4? rc4?).
We -- like many other companies -- are waiting for the 5.1 release to
move everything from PHP4 to PHP5. Unfortunately this bug is a 'show
stopper' for us right now.
[2005-08-11 12:50:22] [EMAIL PROTECTED]
The fix is ready, but we have to wait for Andrey Dmitry to finish
merging of Unicode patches.
[2005-08-11 03:37:24] leon at lost dot co dot nz
Description:
This problem came up when moving our homebrew 'PHPDoc' type class to
PHP5.1. When built with --enable-debug PHP throws up warnings up when
the class to be documented ('A' below) contains methods with default
values that are either NULL or boolean
In the code snippet below we get two warnings, one for each default
parameter. Changing the default values to a string or number (even
zero) eliminates the warnings.
This is a serious problem for us. When documenting some of our bigger
classes we have seen lots of 'odd' behaviour, including permanent 100%
CPU usage by Apache! It has taken *days* to track down the problem to
the snippet below. If there is anything elso I can do to help fix it
please let me know...
Reproduce code:
---
$r = new ReflectionClass('A');
$methods = $r-getMethods();
foreach($methods as $method)
{
$parameters = $method-getParameters();
foreach($parameters as $p)
{
if($p-isDefaultValueAvailable())
$p-getDefaultValue();
}
}
class A
{
function foo($p=null, $q=false)
{
}
}
Expected result:
No output at all -- I've trimed all the output code out.
Actual result:
--
$ php bug2.php
Warning: String is not zero-terminated (ZÌ*) (source:
/tmp/php5-200508110030/Zend/zend_variables.h:35) in Unknown on line 0
[Thu Aug 11 13:18:58 2005] Script: 'bug2.php'
---
/tmp/php5-200508110030/Zend/zend_variables.h(35) : Block 0x08514F30
status:
/tmp/php5-200508110030/Zend/zend_variables.c(36) : Actual location
(location was relayed)
Beginning: Cached (allocated on Zend/zend_language_scanner.c:4689,
5 bytes)
End: OK
---
Warning: String is not zero-terminated (ZZÌ*) (source:
/tmp/php5-200508110030/Zend/zend_variables.h:35) in Unknown on line 0
[Thu Aug 11 13:18:58 2005] Script: 'bug2.php'
---
/tmp/php5-200508110030/Zend/zend_variables.h(35) : Block 0x085150C8
status:
/tmp/php5-200508110030/Zend/zend_variables.c(36) : Actual location
(location was relayed)
Beginning: Cached (allocated on Zend/zend_language_scanner.c:4689,
6 bytes)
End: OK
---
--
Edit this bug report at http://bugs.php.net/?id=34078edit=1
#34078 [NEW]: Reflection API problems in methods with boolean or null default values
From: leon at lost dot co dot nz
Operating system: Debian Sarge (2.6.12 kernel)
PHP version: 5CVS-2005-08-11 (dev)
PHP Bug Type: Scripting Engine problem
Bug description: Reflection API problems in methods with boolean or null
default values
Description:
This problem came up when moving our homebrew 'PHPDoc' type class to
PHP5.1. When built with --enable-debug PHP throws up warnings up when the
class to be documented ('A' below) contains methods with default values
that are either NULL or boolean
In the code snippet below we get two warnings, one for each default
parameter. Changing the default values to a string or number (even zero)
eliminates the warnings.
This is a serious problem for us. When documenting some of our bigger
classes we have seen lots of 'odd' behaviour, including permanent 100% CPU
usage by Apache! It has taken *days* to track down the problem to the
snippet below. If there is anything elso I can do to help fix it please
let me know...
Reproduce code:
---
$r = new ReflectionClass('A');
$methods = $r-getMethods();
foreach($methods as $method)
{
$parameters = $method-getParameters();
foreach($parameters as $p)
{
if($p-isDefaultValueAvailable())
$p-getDefaultValue();
}
}
class A
{
function foo($p=null, $q=false)
{
}
}
Expected result:
No output at all -- I've trimed all the output code out.
Actual result:
--
$ php bug2.php
Warning: String is not zero-terminated (ZÌ*) (source:
/tmp/php5-200508110030/Zend/zend_variables.h:35) in Unknown on line 0
[Thu Aug 11 13:18:58 2005] Script: 'bug2.php'
---
/tmp/php5-200508110030/Zend/zend_variables.h(35) : Block 0x08514F30
status:
/tmp/php5-200508110030/Zend/zend_variables.c(36) : Actual location
(location was relayed)
Beginning: Cached (allocated on Zend/zend_language_scanner.c:4689, 5
bytes)
End: OK
---
Warning: String is not zero-terminated (ZZÌ*) (source:
/tmp/php5-200508110030/Zend/zend_variables.h:35) in Unknown on line 0
[Thu Aug 11 13:18:58 2005] Script: 'bug2.php'
---
/tmp/php5-200508110030/Zend/zend_variables.h(35) : Block 0x085150C8
status:
/tmp/php5-200508110030/Zend/zend_variables.c(36) : Actual location
(location was relayed)
Beginning: Cached (allocated on Zend/zend_language_scanner.c:4689, 6
bytes)
End: OK
---
--
Edit bug report at http://bugs.php.net/?id=34078edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34078r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=34078r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=34078r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=34078r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=34078r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=34078r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=34078r=needscript
Try newer version: http://bugs.php.net/fix.php?id=34078r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=34078r=support
Expected behavior: http://bugs.php.net/fix.php?id=34078r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=34078r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=34078r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=34078r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34078r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=34078r=dst
IIS Stability: http://bugs.php.net/fix.php?id=34078r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=34078r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=34078r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=34078r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=34078r=mysqlcfg
#33859 [Bgs-Opn]: Failed SQLite assertion when using SQL 'AS'
ID: 33859
User updated by: leon at lost dot co dot nz
Reported By: leon at lost dot co dot nz
-Status: Bogus
+Status: Open
Bug Type: PDO related
Operating System: Linux (Debian Sarge)
PHP Version: 5CVS-2005-07-26 (dev)
New Comment:
You cannot mean to say that an SQL query should be allowed to CRASH a
scripting language like PHP, surely! Even if the SQL were incorrect
(and mine wasn't) crashing PHP is not an option...
Prehaps I should have made myself more clear:
Triggering the assertion caused PHP to abort. No page view, no HTML
error messages, nothing but a frustrated user and an error in Apache's
errorlog...
This is not a bogus bug report.
Previous Comments:
[2005-07-26 09:28:30] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
Ask for SQLite support here: http://sqlite.org
[2005-07-26 05:36:59] leon at lost dot co dot nz
Description:
Attached snippet triggers an assertion everytime:
$ php -v
PHP 5.1.0-dev (cli) (built: Jul 26 2005 15:26:09) (DEBUG)
Copyright (c) 1997-2005 The PHP Group
Zend Engine v2.1.0-dev, Copyright (c) 1998-2004 Zend Technologies
$ php bug3.php
php: /tmp/php5-200507260230/ext/pdo_sqlite/sqlite/src/auth.c:117:
sqlite3AuthRead: Assertion `pExpr-op==7' failed.
Aborted
Reproduce code:
---
?php
// Setup sample database
$conn = new PDO('sqlite::memory:');
$conn-exec('CREATE TABLE barrel (docid INTEGER, wordid INTEGER,
position INTEGER)');
$conn-exec('CREATE TABLE documents (id INTEGER PRIMARY KEY, key TEXT
UNIQUE)');
// Run problem query
$sql = SELECT count(*) AS count, key FROM .
barrel, documents WHERE id == docid AND .
wordid == 1 GROUP BY docid ORDER BY count DESC;;
$stmt = $conn-query($sql);
$result = $stmt-fetch();
print_r($result);
?
Expected result:
Array
(
[count] = 0
[0] = 0
[key] =
[1] =
)
Actual result:
--
php: /tmp/php5-200507260230/ext/pdo_sqlite/sqlite/src/auth.c:117:
sqlite3AuthRead: Assertion `pExpr-op==7' failed.
Aborted
--
Edit this bug report at http://bugs.php.net/?id=33859edit=1
#33859 [Bgs-Opn]: Failed SQLite assertion when using SQL 'AS'
ID: 33859
User updated by: leon at lost dot co dot nz
Reported By: leon at lost dot co dot nz
-Status: Bogus
+Status: Open
Bug Type: PDO related
Operating System: Linux (Debian Sarge)
PHP Version: 5CVS-2005-07-26 (dev)
New Comment:
With all due respect, that's complete and utter nonsense.
However on the postitive side, at least now I can see where you were
confused.
Obviously you have assumed that the error was because my choice of
alias is also a function name (prehaps you should have ran the code to
actually test your assumption). This turns out not to be the case.
The error still occurs if I use another alias (I've also simplified
the SQL to the bare minimum for you):
?php
// Setup sample database
$conn = new PDO('sqlite::memory:');
$conn-exec('CREATE TABLE barrel (docid INTEGER)');
// Run problem query
$sql = SELECT count(*) AS cnt FROM barrel ORDER BY cnt;
$stmt = $conn-query($sql);
$result = $stmt-fetch();
print_r($result);
?
Also, the original example SQL was perfecly valid, as demonstrated by
giving it to native sqlite3 command line program:
$ echo SELECT count(*) AS count,key FROM barrel, \
documents WHERE id == docid AND wordid == 3 \
GROUP BY docid ORDER BY count DESC; |
sqlite3 search.sqlite3
3|/main/library/index.html
2|/main/docs/page/printable.html
1|/main/apps/index.html
... and so on...
$
Previous Comments:
[2005-07-27 01:13:10] [EMAIL PROTECTED]
The only way to fix it would be for PHP to implement it's own SQL query
parser, pre-scan user queries and determine if any disallowed keywords
are being used. This is not only highly impractical, but would also
make database communication code very slow.
[2005-07-27 00:51:14] leon at lost dot co dot nz
You cannot mean to say that an SQL query should be allowed to CRASH a
scripting language like PHP, surely! Even if the SQL were incorrect
(and mine wasn't) crashing PHP is not an option...
Prehaps I should have made myself more clear:
Triggering the assertion caused PHP to abort. No page view, no HTML
error messages, nothing but a frustrated user and an error in Apache's
errorlog...
This is not a bogus bug report.
[2005-07-26 09:28:30] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
Ask for SQLite support here: http://sqlite.org
[2005-07-26 05:36:59] leon at lost dot co dot nz
Description:
Attached snippet triggers an assertion everytime:
$ php -v
PHP 5.1.0-dev (cli) (built: Jul 26 2005 15:26:09) (DEBUG)
Copyright (c) 1997-2005 The PHP Group
Zend Engine v2.1.0-dev, Copyright (c) 1998-2004 Zend Technologies
$ php bug3.php
php: /tmp/php5-200507260230/ext/pdo_sqlite/sqlite/src/auth.c:117:
sqlite3AuthRead: Assertion `pExpr-op==7' failed.
Aborted
Reproduce code:
---
?php
// Setup sample database
$conn = new PDO('sqlite::memory:');
$conn-exec('CREATE TABLE barrel (docid INTEGER, wordid INTEGER,
position INTEGER)');
$conn-exec('CREATE TABLE documents (id INTEGER PRIMARY KEY, key TEXT
UNIQUE)');
// Run problem query
$sql = SELECT count(*) AS count, key FROM .
barrel, documents WHERE id == docid AND .
wordid == 1 GROUP BY docid ORDER BY count DESC;;
$stmt = $conn-query($sql);
$result = $stmt-fetch();
print_r($result);
?
Expected result:
Array
(
[count] = 0
[0] = 0
[key] =
[1] =
)
Actual result:
--
php: /tmp/php5-200507260230/ext/pdo_sqlite/sqlite/src/auth.c:117:
sqlite3AuthRead: Assertion `pExpr-op==7' failed.
Aborted
--
Edit this bug report at http://bugs.php.net/?id=33859edit=1
#33859 [NEW]: Failed SQLite assertion when using SQL 'AS'
From: leon at lost dot co dot nz
Operating system: Linux (Debian Sarge)
PHP version: 5CVS-2005-07-26 (dev)
PHP Bug Type: PDO related
Bug description: Failed SQLite assertion when using SQL 'AS'
Description:
Attached snippet triggers an assertion everytime:
$ php -v
PHP 5.1.0-dev (cli) (built: Jul 26 2005 15:26:09) (DEBUG)
Copyright (c) 1997-2005 The PHP Group
Zend Engine v2.1.0-dev, Copyright (c) 1998-2004 Zend Technologies
$ php bug3.php
php: /tmp/php5-200507260230/ext/pdo_sqlite/sqlite/src/auth.c:117:
sqlite3AuthRead: Assertion `pExpr-op==7' failed.
Aborted
Reproduce code:
---
?php
// Setup sample database
$conn = new PDO('sqlite::memory:');
$conn-exec('CREATE TABLE barrel (docid INTEGER, wordid INTEGER, position
INTEGER)');
$conn-exec('CREATE TABLE documents (id INTEGER PRIMARY KEY, key TEXT
UNIQUE)');
// Run problem query
$sql = SELECT count(*) AS count, key FROM .
barrel, documents WHERE id == docid AND .
wordid == 1 GROUP BY docid ORDER BY count DESC;;
$stmt = $conn-query($sql);
$result = $stmt-fetch();
print_r($result);
?
Expected result:
Array
(
[count] = 0
[0] = 0
[key] =
[1] =
)
Actual result:
--
php: /tmp/php5-200507260230/ext/pdo_sqlite/sqlite/src/auth.c:117:
sqlite3AuthRead: Assertion `pExpr-op==7' failed.
Aborted
--
Edit bug report at http://bugs.php.net/?id=33859edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33859r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33859r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33859r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33859r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33859r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33859r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33859r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33859r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33859r=support
Expected behavior: http://bugs.php.net/fix.php?id=33859r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33859r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33859r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33859r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33859r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33859r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33859r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33859r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33859r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33859r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33859r=mysqlcfg
#33737 [Opn]: Nothing to do with PDO::SQLite after all
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 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
#33737 [Opn]: Only when default args are false or null
ID: 33737 User updated by: leon at lost dot co dot nz -Summary: Nothing to do with PDO::SQLite after all 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: 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! Previous Comments: [2005-07-22 01:39:53] 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-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 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
#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 (#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? 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 (#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 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=33737edit=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: 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
#33737 [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: Open
Bug Type: PDO related
Operating System: Linux 2.6 / Apache2
PHP Version: PHP 5 CVS
Assigned To: wez
New Comment:
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).
Previous Comments:
[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.
[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...
?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.
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=33737edit=1
#33737 [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: Open Bug Type: PDO related Operating System: Linux 2.6 / Apache2 PHP Version: PHP 5 CVS Assigned To: wez New Comment: 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 (#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! :-) Previous Comments: [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. [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. 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=33737edit=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...
?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 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 ?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...
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=33737edit=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...
?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 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=33737edit=1
#33737 [NEW]: Reproducable segfault on complex object orientated code
From: leon at lost dot co dot nz Operating system: Linux 2.6 / Apache2 PHP version: 5.1.0b2 PHP Bug Type: Reproducible crash Bug description: Reproducable segfault on complex object orientated code 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
#33737 [Fbk-Opn]: Reproducable segfault on complex object orientated code
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: Reproducible crash Operating System: Linux 2.6 / Apache2 PHP Version: 5.1.0b2 New Comment: 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 Previous Comments: [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 ?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-17 23:44:33] 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
#33737 [Opn]: Reproducable segfault on complex object orientated code
ID: 33737 User updated by: leon at lost dot co dot nz Reported By: leon at lost dot co dot nz Status: Open Bug Type: Reproducible crash Operating System: Linux 2.6 / Apache2 PHP Version: 5.1.0b2 New Comment: 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... Previous Comments: [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 ?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-17 23:44:33] 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
#33737 [Opn]: Looks like it's a PDO::SQLite issue
ID: 33737
User updated by: leon at lost dot co dot nz
-Summary: Reproducable segfault on complex object orientated
code
Reported By: leon at lost dot co dot nz
Status: Open
Bug Type: Reproducible crash
Operating System: Linux 2.6 / Apache2
PHP Version: 5.1.0b2
New Comment:
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.
Previous Comments:
[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 ?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-17 23:44:33] 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
#33490 [NEW]: Bundled PDO SQLite driver contains critical bugs
From: leon at lost dot co dot nz Operating system: Linux PHP version: 5.1.0b2 PHP Bug Type: PDO related Bug description: Bundled PDO SQLite driver contains critical bugs Description: The bundled PDO SQLite driver is 3.13, as reported by: PDO::getAttribute(PDO_ATTR_SERVER_VERSION); There have been a number of critical bugs fixed upstream since this release. See http://www.sqlite.org/ I don't see any reason not to upgrade to the latest upstream release: 3.2.2 as of now... -- Edit bug report at http://bugs.php.net/?id=33490edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33490r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33490r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33490r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33490r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33490r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33490r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33490r=needscript Try newer version: http://bugs.php.net/fix.php?id=33490r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33490r=support Expected behavior: http://bugs.php.net/fix.php?id=33490r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33490r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33490r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33490r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33490r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33490r=dst IIS Stability: http://bugs.php.net/fix.php?id=33490r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33490r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33490r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33490r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33490r=mysqlcfg
#33490 [Asn]: Bundled PDO SQLite driver contains critical bugs
ID: 33490 User updated by: leon at lost dot co dot nz Reported By: leon at lost dot co dot nz Status: Assigned Bug Type: PDO related Operating System: Linux PHP Version: 5.1.0b2 Assigned To: wez New Comment: Quite true... But it would still be nice to bundle an up-to-date library before we get to 5.1-final. Cheers... Previous Comments: [2005-06-27 16:12:07] [EMAIL PROTECTED] Meanwhile, you are free to build against any version of libsqlite you choose by passing the install prefix to configure. [2005-06-27 14:00:15] leon at lost dot co dot nz Description: The bundled PDO SQLite driver is 3.13, as reported by: PDO::getAttribute(PDO_ATTR_SERVER_VERSION); There have been a number of critical bugs fixed upstream since this release. See http://www.sqlite.org/ I don't see any reason not to upgrade to the latest upstream release: 3.2.2 as of now... -- Edit this bug report at http://bugs.php.net/?id=33490edit=1
