Bug #54860 [Com]: PHP crash when using closures + extract(EXTR_REFS)
Edit report at http://bugs.php.net/bug.php?id=54860edit=1
ID: 54860
Comment by: ninzya at inbox dot lv
Reported by:ninzya at inbox dot lv
Summary:PHP crash when using closures + extract(EXTR_REFS)
Status: Feedback
Type: Bug
Package:Reproducible crash
Operating System: Windows 7
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
Works fine with 5.3 r311342.
Previous Comments:
[2011-05-21 20:07:02] fel...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
I can't reproduce it.
[2011-05-19 14:02:47] ninzya at inbox dot lv
Sorry, extract() has nothing to do with this issue.
I was able to come up with more compact test script with no use of
extract():
$x =new stdClass;
$y =$x;
for( $i =0; $i 2; ++$i) {
$closure =function() use( $y) {
$y-someProperty ='someValue';// crashes on second iteration
};
$closure();
}
This code does not crash PHP 5.3.5. It seems that references + closures
became
broken in 5.3.6.
[2011-05-19 12:03:20] ninzya at inbox dot lv
Description:
See test script.
PHP 5.3.5 is not affected.
Test script:
---
// Initially $Object is not a reference and contains a pointer
// to an stdClass object.
$Object =new stdClass; /**/ echo 'New: '; debug_zval_dump( $Object);
// $Object becomes a reference to the pointer to an stdClass.
$Object =$Object; /**/ echo 'Self-reference: '; debug_zval_dump(
$Object);
// Now we import $Object into closure by value. In theory,
// $Object, that is inside closure, should not be a reference, but
rather
// should be a variable, that points to stdClass (i.e. an equivalent
of
// $ImportedObject in expression $ImportedObject =$Object).
$closure =function() use( $Object) {
// Once you manipulate $Object, you get PHP crashed.
$Object-x =10;
//debug_zval_dump( $Object);
};
// By calling extract() we make $Object to reference a new stdClass
instance.
extract( array( 'Object' =new stdClass), EXTR_REFS);
echo 'After extract: '; debug_zval_dump( $Object);
// now we execute closure and get PHP crashed
$closure();
Expected result:
PHP should not crash.
Actual result:
--
PHP crashes.
If you put die() right before $closure(), then you get following
output:
line 1: New: object(stdClass)#1 (0) refcount(2){
line 2: }
line 3: Self-reference: object(stdClass)#1 (0) refcount(1){
line 4: }
line 5: After extract: object(stdClass)#3 (0) refcount(2){
line 6: }
Some questions regarding that output:
1) why there is refcount(2) in the first line? Isn't the object
referenced only
once and by $Object variable? I would expect to see refcount(1) here. As
you can
see on line 3, refcount seems to become correct after self-referencing
is being
made.
2) why line 5 says object(stdClass)#3, while there were only two (and
not 3)
stdClass objects allocated? If you comment out closure's definition,
then you
get object(stdClass)#2 (an expected output). Does closure clone $Object
when you
say use($Object)? Shouldn't the stdClass object be simply referenced
by the
use($Object)?
--
Edit this bug report at http://bugs.php.net/bug.php?id=54860edit=1
[PHP-BUG] Bug #54905 [NEW]: inconsistant namespace behaviour with DocumentFragment
From:
Operating system: Fedora / Debian
PHP version: 5.3.6
Package: DOM XML related
Bug Type: Bug
Bug description:inconsistant namespace behaviour with DocumentFragment
Description:
In an XML document, when an xmlns attribute is present, all child elements
of that
element are also considered to be in that namespace.
When a DocumentFragment is created and the root element contains an xmlns
attribute this is the behaviour currently displayed by PHP.
However if a documentfragment is appended to an element already present in
the DOM
which contains an xmlns, the appended fragment appears to be assigned a
default
'null' namespace.
Test script:
---
Scenario 1: xmlns is present in the fragment.
?php
const BLAH_NS = 'http://blah.com/blah';
$xml = '
root
foo
bar /
/foo
/root
';
$fragXML = 'content
xmlns='.BLAH_NS.'snehsome/snehgrahhere/grahullione/lilitwo/lilithree/li/ul/content';
$doc = new DOMDocument('1.0','UTF-8');
$doc-formatOutput = true;
$doc-preserveWhiteSpace = false;
$doc-loadXML( $xml );
$xpath = new DOMXPath( $doc );
$barElement = $xpath-query( '//bar' )-item(0);
// create a new element with xmlns=http://blah.com/blah; . The
expectation is that
// every child of this node will be part of this namespace as per the
section on default
// name spaces http://www.w3schools.com/XML/xml_namespaces.asp
// create a new document Fragment
$DOMFragment = $doc-createDocumentFragment();
$DOMFragment-appendXML( $fragXML );
// Attach the fragment to the rest of the document
$barElement-appendChild( $DOMFragment );
// all good so far
echo $doc-saveXML();
// register the bar name space so we can perform a lookup
$xpath-registerNamespace('b', BLAH_NS);
echo \n\n\n;
// this doesn't work
$grahElement = $xpath-query( '//b:grah' )-item(0);
echo Find //b:grah .$grahElement-nodeValue.\n;
// this works
$grahElement = $xpath-query( '//grah' )-item(0);
echo Find //grah .$grahElement-nodeValue.\n;
?
Scenario 2: The xmlns attribute is present on the element the fragment is
attached to
?php
const BLAH_NS = 'http://blah.com/blah';
$xml = '
root
foo
bar /
/foo
/root
';
$fragXML =
'snehsome/snehgrahhere/grahullione/lilitwo/lilithree/li/ul';
$doc = new DOMDocument('1.0','UTF-8');
$doc-formatOutput = true;
$doc-preserveWhiteSpace = false;
$doc-loadXML( $xml );
$xpath = new DOMXPath( $doc );
$barElement = $xpath-query( '//bar' )-item(0);
// create a new element with xmlns=http://blah.com/blah; . The
expectation is that
// every child of this node will be part of this namespace as per the
section on default
// name spaces http://www.w3schools.com/XML/xml_namespaces.asp
$contentElement = $doc-createElementNS( BLAH_NS, 'content' );
$barElement-appendChild( $contentElement );
// create a new document Fragment
$DOMFragment = $doc-createDocumentFragment();
$DOMFragment-appendXML( $fragXML );
// Attach the fragment to the rest of the document
$contentElement-appendChild( $DOMFragment );
// all good so far
echo $doc-saveXML();
// register the bar name space so we can perform a lookup
$xpath-registerNamespace('b', BLAH_NS);
echo \n\n\n;
// this doesn't work
$grahElement = $xpath-query( '//b:grah' )-item(0);
echo Find //b:grah .$grahElement-nodeValue.\n;
// this works
$grahElement = $xpath-query( '//grah' )-item(0);
echo Find //grah .$grahElement-nodeValue.\n;
?
Expected result:
In both cases I would expect the output of:
Find //b:grah here
Find //grah
Actual result:
--
Find //b:grah
Find //grah grahtest
--
Edit bug report at http://bugs.php.net/bug.php?id=54905edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54905r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54905r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54905r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54905r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54905r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54905r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54905r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54905r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54905r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54905r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54905r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54905r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54905r=submittedtwice
register_globals:
[PHP-BUG] Bug #54906 [NEW]: Custom HTTP ErrorDocument cannot be shown with a test php script
From:
Operating system: FreeBSD 8.2
PHP version: 5.3.6
Package: Apache2 related
Bug Type: Bug
Bug description:Custom HTTP ErrorDocument cannot be shown with a test php script
Description:
I found that a test script below won't cause Apache showing custom pages,
but browser's error page,
The same result in 403, 404
Is this a bug? and how to fix this problem?
Thanks a lot
--
stephon
Test script:
---
?php
// Server error
header('HTTP/1.1 500 Internal Server Error');
?
--
Edit bug report at http://bugs.php.net/bug.php?id=54906edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54906r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54906r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54906r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54906r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54906r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54906r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54906r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54906r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54906r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54906r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54906r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54906r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54906r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54906r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54906r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54906r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54906r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54906r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54906r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54906r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54906r=mysqlcfg
[PHP-BUG] Bug #54907 [NEW]: SVN_CAT problem with xxx tags
From:
Operating system: Windows 7
PHP version: Irrelevant
Package: Unknown/Other Function
Bug Type: Bug
Bug description:SVN_CAT problem with xxx tags
Description:
---
From manual page: http://www.php.net/function.svn-cat#See Also
---
svn_cat removes test from original commited text test.
Test script:
---
//file test.sql has contents:
//test
//test
$fileContent = svn_cat('test.sql');
echo 'pre'.$fileContent.'/pre';
Expected result:
test
test
Actual result:
--
test
--
Edit bug report at http://bugs.php.net/bug.php?id=54907edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54907r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54907r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54907r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54907r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54907r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54907r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54907r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54907r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54907r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54907r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54907r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54907r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54907r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54907r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54907r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54907r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54907r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54907r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54907r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54907r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54907r=mysqlcfg
Bug #54727 [Asn-Csd]: ob_flush() before output_reset_rewrite_vars() results in data loss
Edit report at http://bugs.php.net/bug.php?id=54727edit=1
ID: 54727
Updated by: m...@php.net
Reported by:mats dot lindh at gmail dot com
Summary:ob_flush() before output_reset_rewrite_vars()
results in data loss
-Status: Assigned
+Status: Closed
Type: Bug
Package:Output Control
Operating System: *
PHP Version:trunk-SVN-2011-05-13 (SVN)
Assigned To:mike
Block user comment: N
Private report: N
New Comment:
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2011-05-23 12:42:02] m...@php.net
Automatic comment from SVN on behalf of mike
Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=311348
Log: Fix Bug #54727, a re-incarnation of #26862
[2011-05-13 14:00:06] mats dot lindh at gmail dot com
Description:
The test for http://bugs.php.net/bug.php?id=26862 currently fails and
results in the last echo statement (everything after ob_flush() and
output_reset_rewrite_vars()) to get lost.
A variant of the issue was reintroduced after the output buffering
rewrite.
This seems to happen because the output is never handled if there is no
rewrite variables to process and there is no active buffer with
contents. The output chars still needs to returned as handled.
The patch also contains a small change in the test to better
differentiate the two echo statements.
Test script:
---
Based on: ext/session/tests/bug26862.phpt
?php
session_start();
output_add_rewrite_var('var', 'value');
echo 'a href=file-first.phplink/a';
ob_flush();
output_reset_rewrite_vars();
echo 'a href=file-second.phplink/a';
Expected result:
a href=file-first.php?var=valuelink/aa
href=file-second.phplink/a
Actual result:
--
a href=file-first.php?var=valuelink/a
--
Edit this bug report at http://bugs.php.net/bug.php?id=54727edit=1
Bug #51914 [Opn-Fbk]: __autoload Does not Work in error_handler function by some case
Edit report at http://bugs.php.net/bug.php?id=51914edit=1
ID: 51914
Updated by: tony2...@php.net
Reported by:i at walkinraven dot name
Summary:__autoload Does not Work in error_handler function
by some case
-Status: Open
+Status: Feedback
Type: Bug
Package:Scripting Engine problem
Operating System: Ubuntu 8.04
PHP Version:5.2.13
Block user comment: N
Private report: N
New Comment:
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Previous Comments:
[2010-05-26 05:18:04] i at walkinraven dot name
Description:
If your script does as below step, it will cause autoload function
halt:
1. You have set an user-defined error handler function.
2. A statement need autoload.
3. The __autoload function emit an error.
4. The user-defined error handler function need autoload.
Test script:
---
URI: http://docs.google.com/View?id=dgt79v8r_120cwxm5mrg
Expected result:
Should not emit any fatal error
Actual result:
--
Fatal error: Class 'Class_A' not found in /usr/share/php/PEAR.php on
line 569
Call Stack:
0.0002 60296 1. {main}()
/home/winfred/workspace/Test/applications/Bugs/new/index.php:0
0.0003 61216 2. __autoload()
/home/winfred/workspace/Test/applications/Bugs/new/index.php:0
0.0012 176604 3. error_handler()
/home/winfred/workspace/Test/applications/Bugs/new/index.php:0
--
Edit this bug report at http://bugs.php.net/bug.php?id=51914edit=1
[PHP-BUG] Bug #54908 [NEW]: DBLIB segfaults when GROUPing with 0 rows for prepared statements
From:
Operating system: Fedora Rawhide
PHP version: 5.3.6
Package: PDO related
Bug Type: Bug
Bug description:DBLIB segfaults when GROUPing with 0 rows for prepared
statements
Description:
I haven't fully figured out the cause of this problem, but for what I can
narrow it down, it's a bit of a remote case.
What I am experiencing is odd behavior when doing a PDO(DBLIB) prepared
statement on a SELECT query with a GROUP BY clause. As far as I can tell,
when the query would have returned 0 results, the query returns an empty
array, but the next time the query is run, I get the following result
(regardless of what the data should actually be):
array(1) {
[0]=
array(2) {
[!]=
NULL
[0]=
NULL
}
}
After this occurs, any attempt (whether explicit or implicit) to unset the
statement results in a segfault in Zend/zend_alloc.c:2028:
if (ZEND_MM_IS_FREE_BLOCK(next_block)) {
I have also found that this only happens when the first execution of the
prepared statement results in a 0 row query. If the order of the execution
in the test script below is reversed so that a result is returned, the
prepared statement works fine from then on.
Another specific of this bug is that it only occurs with the GROUP BY
clause. The query will work fine if I have an aggregate function, but do
not have the GROUP BY column specified.
I have tried the query in a different query tool, and it works fine.
I also tried the script with the php5.3-201105231230 snapshot, but was
still having the issue.
This problem is similar to Bug #40639, but my problem seems more narrow in
focus. I also do not receive the same segfault as the other bug.
Test script:
---
?php
$db = new PDO('dblib:host=server;dbname=db', 'user', 'pass');
$query = $db-prepare('SELECT COALESCE(SUM(tblTransaction.Amount), 0) FROM
tblTransaction INNER JOIN tblDiscount ON tblTransaction.TransactionTypeID =
tblDiscount.TransactionTypeID AND tblDiscount.DiscountID = :DiscountID
WHERE tblTransaction.Voided IS NULL AND tblTransaction.RegistrationID =
:RegistrationID GROUP BY tblTransaction.RegistrationID');
// This combination does not exist together in the database
$execute = $query-execute(array(':DiscountID' = 1, ':RegistrationID' =
114));
echo \nExecuted: . ($execute ? 'Successful' : 'Failed') . \n;
$results = $query-fetchAll();
var_dump($results);
// This combination does exist together in the database
$execute = $query-execute(array(':DiscountID' = 20, ':RegistrationID' =
114));
echo 'Executed: ' . ($execute ? 'Successful' : 'Failed') . \n;
$results = $query-fetchAll();
var_dump($results);
unset($query);
echo 'Unset';
Expected result:
Executed: Successful
array(0) {
}
Executed: Successful
array(1) {
[0]=
array(2) {
[computed]=
string(4) 5.00
[0]=
string(4) 5.00
}
}
Unset
Actual result:
--
Executed: Successful
array(0) {
}
Executed: Successful
array(1) {
[0]=
array(2) {
[!]=
NULL
[0]=
NULL
}
}
Segmentation fault (core dumped)
--
Edit bug report at http://bugs.php.net/bug.php?id=54908edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54908r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54908r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54908r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54908r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54908r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54908r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54908r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54908r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54908r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54908r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54908r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54908r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54908r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54908r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54908r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54908r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54908r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54908r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54908r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54908r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54908r=mysqlcfg
Bug #54908 [Opn-Fbk]: DBLIB segfaults when GROUPing with 0 rows for prepared statements
Edit report at http://bugs.php.net/bug.php?id=54908edit=1
ID: 54908
Updated by: fel...@php.net
Reported by:StevenHadfield at letu dot edu
Summary:DBLIB segfaults when GROUPing with 0 rows for
prepared statements
-Status: Open
+Status: Feedback
Type: Bug
Package:PDO related
Operating System: Fedora Rawhide
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
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 for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32
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.
Previous Comments:
[2011-05-23 15:18:04] StevenHadfield at letu dot edu
Description:
I haven't fully figured out the cause of this problem, but for what I
can narrow it down, it's a bit of a remote case.
What I am experiencing is odd behavior when doing a PDO(DBLIB) prepared
statement on a SELECT query with a GROUP BY clause. As far as I can
tell, when the query would have returned 0 results, the query returns an
empty array, but the next time the query is run, I get the following
result (regardless of what the data should actually be):
array(1) {
[0]=
array(2) {
[!]=
NULL
[0]=
NULL
}
}
After this occurs, any attempt (whether explicit or implicit) to unset
the statement results in a segfault in Zend/zend_alloc.c:2028:
if (ZEND_MM_IS_FREE_BLOCK(next_block)) {
I have also found that this only happens when the first execution of the
prepared statement results in a 0 row query. If the order of the
execution in the test script below is reversed so that a result is
returned, the prepared statement works fine from then on.
Another specific of this bug is that it only occurs with the GROUP BY
clause. The query will work fine if I have an aggregate function, but do
not have the GROUP BY column specified.
I have tried the query in a different query tool, and it works fine.
I also tried the script with the php5.3-201105231230 snapshot, but was
still having the issue.
This problem is similar to Bug #40639, but my problem seems more narrow
in focus. I also do not receive the same segfault as the other bug.
Test script:
---
?php
$db = new PDO('dblib:host=server;dbname=db', 'user', 'pass');
$query = $db-prepare('SELECT COALESCE(SUM(tblTransaction.Amount), 0)
FROM tblTransaction INNER JOIN tblDiscount ON
tblTransaction.TransactionTypeID = tblDiscount.TransactionTypeID AND
tblDiscount.DiscountID = :DiscountID WHERE tblTransaction.Voided IS NULL
AND tblTransaction.RegistrationID = :RegistrationID GROUP BY
tblTransaction.RegistrationID');
// This combination does not exist together in the database
$execute = $query-execute(array(':DiscountID' = 1, ':RegistrationID'
= 114));
echo \nExecuted: . ($execute ? 'Successful' : 'Failed') . \n;
$results = $query-fetchAll();
var_dump($results);
// This combination does exist together in the database
$execute = $query-execute(array(':DiscountID' = 20, ':RegistrationID'
= 114));
echo 'Executed: ' . ($execute ? 'Successful' : 'Failed') . \n;
$results = $query-fetchAll();
var_dump($results);
unset($query);
echo 'Unset';
Expected result:
Executed: Successful
array(0) {
}
Executed: Successful
array(1) {
[0]=
array(2) {
[computed]=
string(4) 5.00
[0]=
string(4) 5.00
}
}
Unset
Actual result:
--
Executed: Successful
array(0) {
}
Executed: Successful
array(1) {
[0]=
array(2) {
[!]=
NULL
[0]=
NULL
}
}
Segmentation fault (core dumped)
--
Edit this bug report at http://bugs.php.net/bug.php?id=54908edit=1
Bug #54908 [Fbk-Opn]: DBLIB segfaults when GROUPing with 0 rows for prepared statements
Edit report at http://bugs.php.net/bug.php?id=54908edit=1
ID: 54908
User updated by:StevenHadfield at letu dot edu
Reported by:StevenHadfield at letu dot edu
Summary:DBLIB segfaults when GROUPing with 0 rows for
prepared statements
-Status: Feedback
+Status: Open
Type: Bug
Package:PDO related
Operating System: Fedora Rawhide
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
gdb backtrace:
#0 _zend_mm_free_int (heap=0xb2c310, p=0xe1b868) at
/usr/src/debug/php-5.3.6/Zend/zend_alloc.c:2028
#1 0x7fffef1d1b1e in free_statement (stmt=0xe1bb70) at
/usr/src/debug/php-5.3.6/ext/pdo/pdo_stmt.c:2410
#2 0x005d0f3f in zend_objects_store_del_ref_by_handle_ex
(handle=2, handlers=optimized out)
at /usr/src/debug/php-5.3.6/Zend/zend_objects_API.c:220
#3 0x005d0f63 in zend_objects_store_del_ref (zobject=0xe1aa08)
at /usr/src/debug/php-5.3.6/Zend/zend_objects_API.c:172
#4 0x005a09f2 in _zval_dtor (zvalue=optimized out) at
/usr/src/debug/php-5.3.6/Zend/zend_variables.h:35
#5 _zval_ptr_dtor (zval_ptr=0xe1c170) at
/usr/src/debug/php-5.3.6/Zend/zend_execute_API.c:443
#6 _zval_ptr_dtor (zval_ptr=0xe1c170) at
/usr/src/debug/php-5.3.6/Zend/zend_execute_API.c:432
#7 0x005bb931 in zend_hash_del_key_or_index (ht=0x939ec8,
arKey=optimized out, nKeyLength=optimized out, h=optimized out,
flag=optimized out) at
/usr/src/debug/php-5.3.6/Zend/zend_hash.c:500
#8 0x0062b36a in ZEND_UNSET_VAR_SPEC_CV_HANDLER
(execute_data=0x7fffeb09c050) at
/usr/src/debug/php-5.3.6/Zend/zend_vm_execute.h:22511
#9 0x005d1e2b in execute (op_array=0xe1b260) at
/usr/src/debug/php-5.3.6/Zend/zend_vm_execute.h:107
#10 0x71e78d6d in xdebug_execute (op_array=0xe1b260) at
/usr/src/debug/php-pecl-xdebug-2.1.1/xdebug-2.1.1/xdebug.c:1268
#11 0x005affb0 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/src/debug/php-5.3.6/Zend/zend.c:1194
#12 0x0055d3b3 in php_execute_script
(primary_file=0x7fffdd20) at
/usr/src/debug/php-5.3.6/main/main.c:2268
#13 0x0042486e in main (argc=2, argv=0x7fffdf28) at
/usr/src/debug/php-5.3.6/sapi/cli/php_cli.c:1193
Previous Comments:
[2011-05-23 15:21:06] fel...@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 for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32
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.
[2011-05-23 15:18:04] StevenHadfield at letu dot edu
Description:
I haven't fully figured out the cause of this problem, but for what I
can narrow it down, it's a bit of a remote case.
What I am experiencing is odd behavior when doing a PDO(DBLIB) prepared
statement on a SELECT query with a GROUP BY clause. As far as I can
tell, when the query would have returned 0 results, the query returns an
empty array, but the next time the query is run, I get the following
result (regardless of what the data should actually be):
array(1) {
[0]=
array(2) {
[!]=
NULL
[0]=
NULL
}
}
After this occurs, any attempt (whether explicit or implicit) to unset
the statement results in a segfault in Zend/zend_alloc.c:2028:
if (ZEND_MM_IS_FREE_BLOCK(next_block)) {
I have also found that this only happens when the first execution of the
prepared statement results in a 0 row query. If the order of the
execution in the test script below is reversed so that a result is
returned, the prepared statement works fine from then on.
Another specific of this bug is that it only occurs with the GROUP BY
clause. The query will work fine if I have an aggregate function, but do
not have the GROUP BY column specified.
I have tried the query in a different query tool, and it works fine.
I also tried the script with the php5.3-201105231230 snapshot, but was
still having the issue.
This problem is similar to Bug #40639, but my problem seems more narrow
in focus. I also do not receive the same segfault as the other bug.
Test script:
---
?php
$db = new PDO('dblib:host=server;dbname=db', 'user', 'pass');
$query = $db-prepare('SELECT COALESCE(SUM(tblTransaction.Amount), 0)
FROM tblTransaction INNER JOIN tblDiscount ON
tblTransaction.TransactionTypeID = tblDiscount.TransactionTypeID AND
tblDiscount.DiscountID = :DiscountID WHERE tblTransaction.Voided IS NULL
AND tblTransaction.RegistrationID = :RegistrationID GROUP BY
[PHP-BUG] Bug #54909 [NEW]: Relative weekday modifications reset time values.
From:
Operating system: Linux
PHP version: 5.3.6
Package: Date/time related
Bug Type: Bug
Bug description:Relative weekday modifications reset time values.
Description:
Date modifications utilizing the weekdays keyword change the resulting
date to
have zero values for hour/minute/second units. Prior to PHP 5.3.6, the
time
values were unaffected.
Test script:
---
?php
$dt = new DateTime('2011-05-10 12:34:56', new DateTimeZone('UTC'));
$dt-modify('10 weekdays');
echo $dt-format('r');
?
Expected result:
Tue, 24 May 2011 12:34:56 +
Actual result:
--
Tue, 24 May 2011 00:00:00 +
--
Edit bug report at http://bugs.php.net/bug.php?id=54909edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54909r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54909r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54909r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54909r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54909r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54909r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54909r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54909r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54909r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54909r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54909r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54909r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54909r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54909r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54909r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54909r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54909r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54909r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54909r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54909r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54909r=mysqlcfg
[PHP-BUG] Bug #54910 [NEW]: Crash when calling call_user_func with unknown function name
From:
Operating system: Ubuntu 11.04
PHP version: 5.3.6
Package: Reproducible crash
Bug Type: Bug
Bug description:Crash when calling call_user_func with unknown function name
Description:
Firstly the function is_callable(array('B', 'noSuchMethod')) returns true
even
such static method does not exist. This could be caused by class A having
magic
method __call (which shouldn't accept static methods though).
Still because of this the code fails with segmentation fault.
Test script:
---
class A
{
public function __call($method, $args)
{
if (stripos($method, 'get') === 0) {
return $this-get();
}
throw new BadMethodCallException(No such method);
}
protected function get()
{
$class = get_class($this);
$call = array($class, 'noSuchMethod');
if (is_callable($call)) {
call_user_func($call);
}
}
}
class B extends A {}
$input = new B();
echo $input-getEmail();
Expected result:
Script should end with no output.
Actual result:
--
Segmentation fault.
--
Edit bug report at http://bugs.php.net/bug.php?id=54910edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54910r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54910r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54910r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54910r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54910r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54910r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54910r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54910r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54910r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54910r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54910r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54910r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54910r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54910r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54910r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54910r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54910r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54910r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54910r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54910r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54910r=mysqlcfg
Bug #52061 [Com]: memory_limit above 2G
Edit report at http://bugs.php.net/bug.php?id=52061edit=1
ID: 52061
Comment by: jsweeny at gmail dot com
Reported by:mail-phpbugs at fushigi dot de
Summary:memory_limit above 2G
Status: Assigned
Type: Bug
Package:Scripting Engine problem
Operating System: Linux/Centos-5
PHP Version:5.2SVN-2010-06-12 (snap)
Assigned To:pajoye
Block user comment: N
Private report: N
New Comment:
I am having this same problem; but I'm running php version 5.1.6. I
have 12 GB of memory and am running 64-bit Linux. Why did you say that
version 5.1 was okay? Something about walking in an error?
If a fix was created for version 5.2, can one also be created for
version 5.1?
thanks!
Previous Comments:
[2010-06-20 12:58:00] mail-phpbugs at fushigi dot de
i have testet it on my test machines and the memory limit is working
fine :)
thx for the quick fix :)
[2010-06-19 22:48:39] fel...@php.net
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
[2010-06-19 22:47:27] fel...@php.net
Automatic comment from SVN on behalf of felipe
Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=300606
Log: - Fixed bug #52061 (memory_limit above 2G)
# MFH: zend_atol()
[2010-06-12 02:56:41] mail-phpbugs at fushigi dot de
Description:
PHP 5.2 doesn't coun't process memory_limit = 2048M in right way
in 32bit mode it works up to 4G, after that it would cause a fatal
error, this seems ok, because of the memory limitations of 32bit :)
in 64bit its a REAL BUG, because after 2047M the memory limit DOESN'T
MATCH, this means no memory limit is active !
as far as i have seen the memory limit for php51 isn't affectet this way
because it walks in an error as of 2GB
and it seems in php53 the problem is fixed, here i tried to set limits
up to 8GB and all worked fine.
The test script is from http://news.php.net/php.internals/48607 , but i
think is shows the problem very well :)
is it possible to fix this, so it will behave as php-5.3 ?
or have the same matching as in 32bit version, so there is a limit if
someone setting a too high value ?
i have found this problem as i wanted to get a customer from an old
php-5.2.13 32bit machine on a newer php-5.2.13 64bit machine :(
32bit 5.2:
Running 40 times with a 16383 bytes long string (' ...')
0 - 0.000s:0.1 / 0.2 MB
1 - 1.294s: 166.7 / 177.5 MB
2 - 2.453s: 333.2 / 355.1 MB
3 - 3.988s: 499.7 / 532.4 MB
4 - 5.700s: 666.3 / 709.5 MB
5 - 7.614s: 832.8 / 886.9 MB
6 - 9.838s: 999.3 / 1'064.0 MB
7 - 11.592s:1'165.9 / 1'241.3 MB
8 - 12.943s:1'332.4 / 1'418.6 MB
9 - 19.795s:1'498.9 / 1'595.7 MB
PHP Fatal error: Allowed memory size of -2147483648 bytes exhausted
(tried to allocate 40961 bytes) in /tmp/php-memtest.php on line 32
64bit 5.2:
Running 40 times with a 16383 bytes long string (' ...')
0 - 0.000s:0.1 / 0.2 MB
1 - 0.110s: 167.0 / 177.8 MB
2 - 0.221s: 333.8 / 355.1 MB
3 - 0.335s: 500.5 / 532.2 MB
4 - 0.449s: 667.3 / 709.7 MB
5 - 0.560s: 834.1 / 887.1 MB
6 - 0.672s:1'000.9 / 1'064.2 MB
7 - 0.782s:1'167.7 / 1'241.7 MB
8 - 0.891s:1'334.5 / 1'418.8 MB
9 - 1.000s:1'501.3 / 1'596.0 MB
10 - 1.109s:1'668.1 / 1'773.3 MB
11 - 1.219s:1'834.9 / 1'950.4 MB
12 - 1.328s:2'001.7 / 2'127.5 MB
13 - 1.436s:2'168.5 / 2'304.9 MB
14 - 1.543s:2'335.3 / 2'482.2 MB
15 - 1.651s:2'502.1 / 2'659.3 MB
16 - 1.758s:2'668.9 / 2'836.6 MB
17 - 1.864s:2'835.7 / 3'013.7 MB
18 - 1.969s:3'002.5 / 3'190.9 MB
19 - 2.079s:3'169.3 / 3'368.2 MB
20 - 2.189s:3'336.0 / 3'545.5 MB
21 - 2.300s:3'502.8 / 3'722.6 MB
22 - 2.411s:3'669.6 / 3'900.0 MB
23 - 2.519s:3'836.4 / 4'077.1 MB
24 - 2.628s:4'003.2 / 4'254.2 MB
25 - 2.737s:4'170.0 / 4'431.5 MB
26 - 2.845s:4'336.8 / 4'608.6 MB
27 - 2.953s:4'503.6 / 4'786.0 MB
28 - 3.061s:4'670.4 / 4'963.3 MB
29 - 3.169s:4'837.2 / 5'140.4 MB
30 - 3.277s:5'004.0 / 5'317.5 MB
[PHP-BUG] Bug #54911 [NEW]: Access to a undefined member in inherit SoapClient may cause Segmentation Fault
From:
Operating system: Linux
PHP version: 5.3.6
Package: Reproducible crash
Bug Type: Bug
Bug description:Access to a undefined member in inherit SoapClient may cause
Segmentation Fault
Description:
If you try to access an undefined variable or constant in an extended
SoapClient, it will cause PHP crash due to a Segmentation Fault.
Test script:
---
?php
class XSoapClient extends SoapClient {
function __doRequest($request, $location, $action, $version) {
echo self::$crash;
// echo parent::$crash;
// echo self::crash;
// echo parent::crash;
}
}
$client = new XSoapClient(null, array('uri'='', 'location'=''));
$client-__soapCall('', array());
?
Expected result:
An error like, Fatal error: Access to undeclared static property:
XSoapClient::$crash...
Actual result:
--
$ sapi/cli/php ../crash.php
Segmentation fault
# gdb backtrace...
Starting program: /home/erik/php-5.3.6/sapi/cli/php ../crash.php
[Thread debugging using libthread_db enabled]
Program received signal SIGSEGV, Segmentation fault.
0x0843c238 in zval_delref_p (zval_ptr=0xbfffcf68, __zend_filename=0x87cc4e8
/home/erik/php-5.3.6/Zend/zend_vm_execute.h,
__zend_lineno=609) at /home/erik/php-5.3.6/Zend/zend.h:385
385 return --pz-refcount__gc;
(gdb) bt
#0 0x0843c238 in zval_delref_p (zval_ptr=0xbfffcf68,
__zend_filename=0x87cc4e8 /home/erik/php-5.3.6/Zend/zend_vm_execute.h,
__zend_lineno=609) at /home/erik/php-5.3.6/Zend/zend.h:385
#1 _zval_ptr_dtor (zval_ptr=0xbfffcf68, __zend_filename=0x87cc4e8
/home/erik/php-5.3.6/Zend/zend_vm_execute.h, __zend_lineno=609)
at /home/erik/php-5.3.6/Zend/zend_execute_API.c:437
#2 0x08479ff8 in ZEND_HANDLE_EXCEPTION_SPEC_HANDLER
(execute_data=0x8920a60) at
/home/erik/php-5.3.6/Zend/zend_vm_execute.h:609
#3 0x08478793 in execute (op_array=0x88f2be0) at
/home/erik/php-5.3.6/Zend/zend_vm_execute.h:107
#4 0x0844bae6 in zend_execute_scripts (type=8, retval=0x0, file_count=3)
at /home/erik/php-5.3.6/Zend/zend.c:1194
#5 0x083e102e in php_execute_script (primary_file=0xb324) at
/home/erik/php-5.3.6/main/main.c:2268
#6 0x08509d35 in main (argc=2, argv=0xb4b4) at
/home/erik/php-5.3.6/sapi/cli/php_cli.c:1193
--
Edit bug report at http://bugs.php.net/bug.php?id=54911edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54911r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54911r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54911r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54911r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54911r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54911r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54911r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54911r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54911r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54911r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54911r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54911r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54911r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54911r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54911r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54911r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54911r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54911r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54911r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54911r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54911r=mysqlcfg
Req #38508 [Com]: Addition of Magic __toArray() function
Edit report at http://bugs.php.net/bug.php?id=38508edit=1
ID: 38508
Comment by: spark at limao dot com dot br
Reported by:doublecompile at gmail dot com
Summary:Addition of Magic __toArray() function
Status: Closed
Type: Feature/Change Request
Package:Feature/Change Request
PHP Version:*
Block user comment: N
Private report: N
New Comment:
Because of the magic __toString I was able to write a String class with
the same methods as the Java String class.
I was trying to write an Array class to map the one in Adobe AS3, but
then I came across the lack of __toArray.
I don't want a __toArray, or even a toString
I want classes with reasonable methods and not lots of functions with no
naming rules nor parameter order standard.
I know it may sound rude but that's how I feel when I see a language
getting so far and still not following any coding convetion.
Previous Comments:
[2006-08-20 11:12:22] he...@php.net
Why not simply have a method asArray() maybe even as par of an
interface:
interface ArrayConversion
{
function asArray();
}
See, we have __toString as it is supported in language constructs like
echo, print and other internal functions. But we decided against an
autoconversion for arrays already. So itwill never be supported in any
language construct. That said there is no needed for this and nothing
you would win against the above interface. In fact you would make it php
more complex because you'd add just one more magic feature.
[2006-08-19 00:40:17] doublecompile at gmail dot com
Description:
Doing this:
$newarray = (array)$object;
will take the properties of an object and assign them as the values of
keys in an array.
As of PHP 5.2, doing this:
$stringified = (string)$object;
will call the magic __toString() function for a user-specified
formatting of the object as a string.
It would be a great addition to call a magic __toArray() function if an
object is cast as an array, instead of converting its public members to
array elements. (For instance, the class might not have public
members). Classes without the function could use the default method of
mapping property names to array keys.
Just my two cents.
Reproduce code:
---
?php
class magicExample
{
public $aoeu = htns;
function __toArray()
{
return array('foo'='bar');
}
}
$test = new magicExample();
$array = (array)$test;
print_r($array); // should show foo=bar, not aoeu=htns
?
--
Edit this bug report at http://bugs.php.net/bug.php?id=38508edit=1
Bug #26368 [Com]: Returns a Fatal error when using assign-ops
Edit report at http://bugs.php.net/bug.php?id=26368edit=1
ID: 26368
Comment by: cindy dot dolan at yahoo dot com
Reported by:webmaster at x7chat dot com
Summary:Returns a Fatal error when using assign-ops
Status: Bogus
Type: Bug
Package:Arrays related
Operating System: Linux, Windows
PHP Version:4.3.3
Block user comment: N
Private report: N
New Comment:
I have the same issue at PHP 5.3.5, and the same fix.
Looping through the output of a database query, I collect data on two
things - CPU Memory - into two arrays. Each is initialized
identically.
Data is collected like: $cpu[$cntr] .= some more xml data; The
memory data is collected identically: $mem[$cntr] .= some more xml
data;
When I comment out the memory-related array data collection, the code
runs fine.
When I include it, I get this crazy error.
When I change the syntax to:
$mem[$cntr] = $mem[$cntr] . new data;
it runs fine.
Previous Comments:
[2004-09-23 01:41:03] penfield888 at yahoo dot com
Actually, I have error_reporting set to E_ALL, no error suppression
operators, all variables carefully initialized. I get the error on
occasion on one server, not on others. In a very simple situation, I
get the same error on code like this
$var['idx'] = '';
$var['idx'] .= more string;
Others who have had the error seem to have had goodluck fixing it simply
by changing to
$var['idx'] = $var['idx'] . more string;
which should change nothing.
[2003-11-23 21:21:34] sni...@php.net
You have some problem in your script. Get rid of '@' and set
error_reporting(E_ALL); and you'll most likely find out what is wrong.
There is no bug here, this is expected behaviour.
[2003-11-23 15:03:14] webmaster at x7chat dot com
Description:
A certain script I wrote uses the following line of code:
$USER['TEMP'] .= !;
When I run this some servers (Programmed on Redhat Linux 9 with PHP
4.3.3 and it works fine, tested on another Linux server using PHP 4.3.3
and it returns the error) it returns the following error message:
Fatal error: Cannot use assign-op operators with overloaded objects nor
string offsets in
(FILE PATH) on line (LINE NUMBER)
I have asked many different programmers about it and nobody has an
answer as to why it causes an error on code that is correct. According
to PHP documentation the syntax of it is correct.
Another person who has had this problem has documented it here:
http://www.faqchest.com/prgm/php-l/php-02/php-0205/php-020581/php02052416_25320.html.
I distribute the script for free and I have had at least 4 different
users report that they are having this problem.
The variable $USER['TEMP'] has been defined before and is not null.
Reproduce code:
---
$q = DoQuery(SELECT * FROM $SERVER[TBL_PREFIX]users WHERE
username='$USER[NAME]');
$USER['TEMP'] = $row[13];
$k = 1; $i = 0; $s = 0; $r[0] = ;
$USER['TEMP'] .= !;
while($k){
$sub = substr($USER['TEMP'],$i,1);
if($sub == !){
$k = 0;
break;
}
if($sub == ,){
$s++;
}else{
@$r[$s] .= $sub;
}
$i++;
}
Expected result:
I would expect it to add ! to $USER['TEMP'] every time it goes through
the while loop, on some servers it does but on others it returns the
error even if they are the same type of server running the same version
of PHP.
Actual result:
--
On some servers it works correctly and on others it says:
Fatal error: Cannot use assign-op operators with overloaded objects nor
string offsets in
(FILE PATH) on line (LINE NUMBER)
--
Edit this bug report at http://bugs.php.net/bug.php?id=26368edit=1
Bug #54676 [Com]: Current php dev snapshort doesn't handle soap services at all
Edit report at http://bugs.php.net/bug.php?id=54676edit=1 ID: 54676 Comment by: xuytrpoiuyter at inbox dot ru Reported by:xuytrpoiuyter at inbox dot ru Summary:Current php dev snapshort doesn't handle soap services at all Status: Open Type: Bug Package:SOAP related Operating System: Linux PHP Version:5.3SVN-2011-05-06 (snap) Block user comment: N Private report: N New Comment: still not working :(( Previous Comments: [2011-05-06 17:23:36] xuytrpoiuyter at inbox dot ru Description: Current php 5.3 development snapshort has stopped handling soap web services. PHP 5.3.6 works fine. Test script: --- $service = new SoapClient($wsdl_url); Expected result: a correctly functioning SoapClient object Actual result: -- Exception: Error Fetching http headers -- Edit this bug report at http://bugs.php.net/bug.php?id=54676edit=1
[PHP-BUG] Bug #54912 [NEW]: filter/logical_filters.c:685:32: warning: use of logical || with constant op.
From:
Operating system: All
PHP version: 5.3SVN-2011-05-24 (SVN)
Package: Filter related
Bug Type: Bug
Bug description:filter/logical_filters.c:685:32: warning: use of logical ||
with constant op.
Description:
Hi:
There is some buggy/supicious code:
./ext/filter/logical_filters.c:685:32: warning: use of logical || with
constant
operand; switch to bitwise | or remove constant
[-Wconstant-logical-operand]
if (flags (FILTER_FLAG_IPV4 || FILTER_FLAG_IPV6)) {
^
Test script:
---
Attached is a patch to clear the problem separating it in two operations.
Expected result:
No warning
Actual result:
--
./ext/filter/logical_filters.c:685:32: warning: use of logical || with
constant
operand; switch to bitwise | or remove constant
[-Wconstant-logical-operand]
--
Edit bug report at http://bugs.php.net/bug.php?id=54912edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54912r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54912r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54912r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54912r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54912r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54912r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54912r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54912r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54912r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54912r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54912r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54912r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54912r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54912r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54912r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54912r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54912r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54912r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54912r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54912r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54912r=mysqlcfg
[PHP-BUG] Bug #54914 [NEW]: Don't work shared module php5-interbase
From:
Operating system: Freebsd 8.2
PHP version: 5.3.6
Package: InterBase related
Bug Type: Bug
Bug description:Don't work shared module php5-interbase
Description:
If i build lang/php5-extensions with module interbase then don't work
connect firebird.
If build lang/php5 with argument in MakeFile --with-interbase=/usr/local
then connect it's work.
Test script:
---
?php
$link=ibase_connect('test:base_test.gdb','user','user','win1251',0,1,'main');
?
Actual result:
--
In the course of debugging by means of GDB I have pressed Ctrl-C because
the program hangs up, can be goes in cycles.
(gdb) run temp.php
Starting program: /usr/local/bin/php temp.php
[New LWP 100068]
[New Thread 80171b1c0 (LWP 100068)]
^C
Program received signal SIGINT, Interrupt.
[Switching to Thread 80171b1c0 (LWP 100068)]
0x00080228b3ca in __error () from /lib/libthr.so.3
(gdb) bt
#0 0x00080228b3ca in __error () from /lib/libthr.so.3
#1 0x00080228b0bc in __error () from /lib/libthr.so.3
#2 0x000802285f5a in pthread_mutex_getprioceiling () from
/lib/libthr.so.3
#3 0x000802286b4d in pthread_mutex_trylock () from /lib/libthr.so.3
#4 0x0008013489c9 in _malloc_prefork () from /lib/libc.so.7
#5 0x00080134b011 in calloc () from /lib/libc.so.7
#6 0x000802285d78 in pthread_mutexattr_init () from /lib/libthr.so.3
#7 0x000802286004 in pthread_mutex_getprioceiling () from
/lib/libthr.so.3
#8 0x000802286b4d in pthread_mutex_trylock () from /lib/libthr.so.3
#9 0x0008013489c9 in _malloc_prefork () from /lib/libc.so.7
#10 0x00080134b631 in malloc () from /lib/libc.so.7
#11 0x000802287c85 in pthread_kill () from /lib/libthr.so.3
#12 0x00080228157d in pthread_create () from /lib/libthr.so.3
#13 0x000801c7c3ad in ThreadStart::start () from
/usr/local/lib/libfbclient.so.2
#14 0x000801c7c419 in gds__thread_start () from
/usr/local/lib/libfbclient.so.2
#15 0x000801c80eaf in (anonymous namespace)::YEntry::YEntry () from
/usr/local/lib/libfbclient.so.2
#16 0x000801c8d983 in isc_attach_database () from
/usr/local/lib/libfbclient.so.2
#17 0x000801b3b5a1 in _php_ibase_attach_db () from
/usr/local/lib/php/20090626-debug/interbase.so
#18 0x000801b3bc14 in _php_ibase_connect () from
/usr/local/lib/php/20090626-debug/interbase.so
#19 0x000801b3bf1b in zif_ibase_connect () from
/usr/local/lib/php/20090626-debug/interbase.so
#20 0x0066463c in zend_do_fcall_common_helper_SPEC
(execute_data=0x8058c0098) at zend_vm_execute.h:316
#21 0x0066a79e in ZEND_DO_FCALL_SPEC_CONST_HANDLER
(execute_data=0x8058c0098) at zend_vm_execute.h:1606
#22 0x0066360a in execute (op_array=0x80163cce0) at
zend_vm_execute.h:107
#23 0x0062a07d in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/ports/lang/php5/work/php-5.3.6/Zend/zend.c:1266
#24 0x005a77d2 in php_execute_script (primary_file=0x7fffe9c0)
at /usr/ports/lang/php5/work/php-5.3.6/main/main.c:2283
#25 0x0072436a in main (argc=2, argv=0x7fffeb80) at
/usr/ports/lang/php5/work/php-5.3.6/sapi/cli/php_cli.c:1197
--
Edit bug report at http://bugs.php.net/bug.php?id=54914edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54914r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54914r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54914r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54914r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54914r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54914r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54914r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54914r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54914r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54914r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54914r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54914r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54914r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54914r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54914r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54914r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54914r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54914r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54914r=float
No Zend
