Req #55736 [Opn->Csd]: Added EXPECT_EXTERNAL section to run-tests.php
Edit report at https://bugs.php.net/bug.php?id=55736&edit=1 ID: 55736 Updated by: m...@php.net Reported by:tim at digicol dot de Summary:Added EXPECT_EXTERNAL section to run-tests.php -Status: Open +Status: Closed Type: Feature/Change Request Package:Testing related PHP Version:5.3.8 -Assigned To: +Assigned To:mike Block user comment: N Private report: N New Comment: Merged in master as 5f41cb18beb9437df73c382b5a9689d43c357628 Previous Comments: [2011-09-20 09:31:44] tim at digicol dot de Sorry, typo in summary. It's EXPECT_EXTERNAL, not FILE_EXTERNAL. [2011-09-20 09:21:53] tim at digicol dot de Description: In the .phpt files used with run-tests.php, I'd like an option to read the expected output from external files. For consistency with the FILE / FILE_EXTERNAL section naming, I'd call this feature EXPECT_EXTERNAL. The attached patch (against run-tests.php of PHP 5.3.8) implements this functionality. Would you mind adding it as a standard feature? Reason: We often expect relatively large XML output from our tests. Having to paste it into the EXPECT section makes the .phpt file large, and the XML is easier to handle in a separate file (I can run xmllint on it). Also, I'd like to reuse one test's expected output as the input for another test, which works great with external files. Test script: --- [digicol@dcxcentosvmware php-5.3.8]$ cat tmp.phpt --TEST-- Demo --FILE-- --EXPECT_EXTERNAL-- expected.txt [digicol@dcxcentosvmware php-5.3.8]$ cat expected.txt 3.1415926535898 [digicol@dcxcentosvmware php-5.3.8]$ php run-tests.php.expect_external -p `which php` tmp.phpt = PHP : /usr/local/bin/php PHP_SAPI: cli PHP_VERSION : 5.3.4 ZEND_VERSION: 2.3.0 PHP_OS : Linux - Linux dcxcentosvmware.digicol.local 2.6.18-194.26.1.el5 #1 SMP Tue Nov 9 12:54:20 EST 2010 x86_64 INI actual : /usr/local/lib/php.ini More .INIs : CWD : /usr/local/src/php-5.3.8 Extra dirs : VALGRIND: Not used = Running selected tests. PASS Demo [tmp.phpt] = Number of tests :1 1 Tests skipped :0 ( 0.0%) Tests warned:0 ( 0.0%) ( 0.0%) Tests failed:0 ( 0.0%) ( 0.0%) Expected fail :0 ( 0.0%) ( 0.0%) Tests passed:1 (100.0%) (100.0%) - Time taken :0 seconds = -- Edit this bug report at https://bugs.php.net/bug.php?id=55736&edit=1
Req #53785 [Opn->Csd]: Way to query a X.509 certificate fingerprint
Edit report at https://bugs.php.net/bug.php?id=53785&edit=1
ID: 53785
Updated by: m...@php.net
Reported by:BenBE at geshi dot org
Summary:Way to query a X.509 certificate fingerprint
-Status: Open
+Status: Closed
Type: Feature/Change Request
Package:OpenSSL related
Operating System: Debian
PHP Version:5.3.5
-Assigned To:
+Assigned To:mike
Block user comment: N
Private report: N
New Comment:
Feature by Tjerk Meesters in master.
Previous Comments:
[2012-01-27 09:29:41] msn at searchy dot nl
The fingerprint is nothing more than the md5 or sha1 sum of the certificate.
When you take ther certificate, strip it of the begin and end tag, base64
decode the content and md5 that, you'll get the fingerprint.
Sample code:
$newcert = preg_replace("/-BEGIN CERTIFICATE-|-END
CERTIFICATE-/","",$cert);
$b64 = base64_decode($newcert);
echo "MD5 fingerprint: " . md5($b64) . "\n";
[2011-01-19 06:38:49] BenBE at geshi dot org
Description:
When reading a X.509 certificate file (or fetching the certificate from an SSL
connection) there is no straight forward way to query the certificate's
fingerprint as shown by browsers when viewing the site's certificate.
The output of openssl_x509_parse doesn't contain the fingerprint while
openssl_x509_export might contain it in a hard to parse string representation.
--
Edit this bug report at https://bugs.php.net/bug.php?id=53785&edit=1
Bug #65729 [Opn->Csd]: CN_match gives false positive
Edit report at https://bugs.php.net/bug.php?id=65729&edit=1 ID: 65729 Updated by: m...@php.net Reported by:datib...@php.net Summary:CN_match gives false positive -Status: Open +Status: Closed Type: Bug Package:OpenSSL related Operating System: Linux PHP Version:master-Git-2013-09-21 (Git) -Assigned To: +Assigned To:mike Block user comment: N Private report: N New Comment: Merged. Previous Comments: [2013-09-21 08:27:27] datib...@php.net Description: When the CN_match option is used to verify "foo.test.com.sg" and the server certificate CN is "*.test.com" it will succeed erroneously. Test script: --- $context = stream_context_create(['ssl' => [ 'verify_peer' => true, 'allow_self_signed' => true, 'CN_match' => 'foo.test.com.sg', ]]); $s = file_get_contents($url, 'rt', $context); var_dump($s); Expected result: Warning: file_get_contents(): Peer certificate CN=`*.test.com' did not match expected CN=`foo.test.com.sg' in /path/to/script.php on line 12 Warning: file_get_contents(): Failed to enable crypto in /Users/tjerk/work/ssl/ssl.php on line 11 Warning: file_get_contents(https://localhost:4433): failed to open stream: operation failed in /path/to/script.php on line 11 bool(false) Actual result: -- No errors. -- Edit this bug report at https://bugs.php.net/bug.php?id=65729&edit=1
Bug #51076 [Ver->Csd]: race condition in shtool's mkdir -p implementation
Edit report at https://bugs.php.net/bug.php?id=51076&edit=1 ID: 51076 Updated by: m...@php.net Reported by:geissert at debian dot org Summary:race condition in shtool's mkdir -p implementation -Status: Verified +Status: Closed Type: Bug Package:Compile Failure Operating System: * PHP Version:5.3SVN-2010-02-18 (SVN) Block user comment: N Private report: N New Comment: Automatic comment on behalf of mike Revision: http://git.php.net/?p=php-src.git;a=commit;h=f32d2ac3aaa7d4af7c348b00ebebb9ae64955704 Log: fix bug #51076 (race condition in shtool's mkdir -p) Previous Comments: [2013-10-07 20:50:41] geiss...@php.net Not really. My change was reverted by jani by updating to the latest version of shtool because local changes are not liked around here... Anyway, I think it's time to deassign it from me as upstream is pretty much dead. After multiple attempts to get it fixed upstream by myself and by the Debian maintainer there hasn't been any success. Let's see who gets rids of the road blocks and how long it takes. [2013-10-07 16:54:30] fviard at lacie dot com Hi, So, after all, anyone to commit again the fix? Thank you [2013-10-01 14:11:38] m...@php.net Looks like I have to apologize for being an asshole myself, some may even think I'm the only asshole here. [2013-10-01 13:55:06] m...@php.net And you make me angry by wasting my time. It was just a template when marking a bug as duplicate. Stop calling people and do something yourself. You do not have to apologize for being an asshole, just don't be an asshole. [2013-10-01 12:58:34] fviard at lacie dot com Hi, Today m...@php.net made me angry by posting a crappy comment on my 2,5years old bug report #54205 without even fixing the issue. This issue was so old that I completely forgot it. But now, I'm stupefied to notice that after 2 years, that issue that is resolvable with only a 5lines patch (easy to apply) is still not resolved. What are you doing? Mike, sorry to be offensive, but do you prefer harassing people on old bugs or fixing them? So, please close this bug soon! Thank you! 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 https://bugs.php.net/bug.php?id=51076 -- Edit this bug report at https://bugs.php.net/bug.php?id=51076&edit=1
Bug #62634 [Opn->Ana]: Incorrect serialization with circular references
Edit report at https://bugs.php.net/bug.php?id=62634&edit=1
ID: 62634
Updated by: m...@php.net
Reported by:phplists at stanvassilev dot com
Summary:Incorrect serialization with circular references
-Status: Open
+Status: Analyzed
Type: Bug
Package:Scripting Engine problem
Operating System: Any
PHP Version:5.4.5
Block user comment: N
Private report: N
Previous Comments:
[2013-03-16 18:09:15] ni...@php.net
The reason this happens is that serialize accepts by value, and as such the
outer array will be a separated and will be different from the one that is
references from within the array.
This can be fixed by marking the serialize argument as ZEND_SEND_PREFER_REF.
Not sure if this should be done or not.
[2012-07-25 13:25:23] f...@php.net
Maybe related to https://bugs.php.net/bug.php?id=62189
[2012-07-22 21:58:45] phplists at stanvassilev dot com
There's a small error in my code example, please replace this line:
$duplicate = unserialize(serialize($x));
With this line:
$duplicate = unserialize(serialize($original));
[2012-07-22 21:54:54] phplists at stanvassilev dot com
Description:
The documentation says references and circular references should serialize
properly. I've found that serialize would first copy the referenced variable,
before detecting the reference.
This not only doubles the serialized output, but produced incorrect copy when
unserialized.
Test script:
---
$original = array('hello');
$original[] = & $original;
echo serialize($original);
// Output (notice the duplication):
// "a:2:{i:0;s:5:"hello";i:1;a:2:{i:0;s:5:"hello";i:1;R:3;}}"
$duplicate = unserialize(serialize($x));
// Now I modify both the original and the duplicate in an identical way.
// But I get different results, because the duplicate points to a copy of
// itself, instead of pointing to itself.
$original[0] = 'world';
$duplicate[0] = 'world';
var_dump($original);
// Produces (notice it says "world" both times, i.e. it points to itself):
// array(2) { [0]=> string(5) "world" [1]=> &array(2) { [0]=> string(5) "world"
[1]=> *RECURSION* } }
var_dump($duplicate);
// Produces (notice the second time it says "hello" i.e. it's a copy):
// array(2) { [0]=> string(5) "world" [1]=> &array(2) { [0]=> string(5) "hello"
[1]=> *RECURSION* } }
Expected result:
There should be NO copies of "hello" left:
array(2) { [0]=> string(5) "world" [1]=> &array(2) { [0]=> string(5) "world"
[1]=>
*RECURSION* } }
There should be NO duplication in the serialized output:
"a:2:{i:0;s:5:"hello";i:1;???;}" (Fill-in the "???" appropriately :) )
Actual result:
--
A copy of "hello" is left:
array(2) { [0]=> string(5) "world" [1]=> &array(2) { [0]=> string(5) "hello"
[1]=>
*RECURSION* } }
There is duplication in the serialized output:
"a:2:{i:0;s:5:"hello";i:1;a:2:{i:0;s:5:"hello";i:1;R:3;}}"
--
Edit this bug report at https://bugs.php.net/bug.php?id=62634&edit=1
Bug #63481 [Asn->Csd]: Segmentation fault caused by unserialize()
Edit report at https://bugs.php.net/bug.php?id=63481&edit=1 ID: 63481 Updated by: m...@php.net Reported by:aurelijus at astdev dot lt Summary:Segmentation fault caused by unserialize() -Status: Assigned +Status: Closed Type: Bug Package:Reproducible crash Operating System: RHEL 6 & Mac OS X 10.7.4 PHP Version:5.4.8 Assigned To:mike Block user comment: N Private report: N New Comment: Thank you for your bug report. This issue has already been fixed in the latest released version of PHP, which you can download at http://www.php.net/downloads.php Previous Comments: [2013-08-30 09:04:25] arjen at react dot com Thanx! The testcase in the original bugreport by aurelijus at astdev dot lt is also fixed on 5.4.20, don't know by which commit. Create new issue for calling 'parent::serialize()' issue, which still crashes: https://bugs.php.net/bug.php?id=65591 This issues can be closed. [2013-08-19 22:13:10] m...@php.net See bug #65481 [2013-07-29 18:11:56] m...@php.net Yes, please. I already have a possible fix for the second issue. [2013-06-06 09:57:11] arjen at react dot com I believe these are different issues, the backtrace is quite different. Got the following results using php-5.4.15 from php.net: Original report: https://gist.github.com/anonymous/5720457 Backtrace of https://gist.github.com/aurelijus/4713758: https://gist.github.com/anonymous/5720464 I tried reducing the original testcase, got a segfault but again the backtrace is quite different. Testscript http://3v4l.org/3WCpP (crashes >= 5.4.0) Backtrace at https://gist.github.com/anonymous/5720491 Should I create a seperate issue for it? [2013-03-08 15:44:18] zach dot quintana at gmail dot com I'm also experiencing a similar bug, but will unserializing a class that doesn't implement serializable. Need the code? 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 https://bugs.php.net/bug.php?id=63481 -- Edit this bug report at https://bugs.php.net/bug.php?id=63481&edit=1
Bug #64146 [Ver->Csd]: serialize incorrectly saving objects when they are cloned
Edit report at https://bugs.php.net/bug.php?id=64146&edit=1 ID: 64146 Updated by: m...@php.net Reported by:slusarz at curecanti dot org Summary:serialize incorrectly saving objects when they are cloned -Status: Verified +Status: Closed Type: Bug Package:Variables related Operating System: Linux PHP Version:5.4.11 Block user comment: N Private report: N New Comment: Automatic comment on behalf of mike Revision: http://git.php.net/?p=php-src.git;a=commit;h=8973390541faaadfdfc0f838421f037060188e5e Log: fix bug #64146 (serialize incorrectly saving objects when they are cloned) Previous Comments: [2013-02-07 22:58:23] m...@php.net Using zend_objects_get_address() instead of the object handle fixes; but triggers bug #62836 [2013-02-07 22:57:27] m...@php.net The following patch has been added/updated: Patch Name: zend_objects_get_address Revision: 1360277847 URL: https://bugs.php.net/patch-display.php?bug=64146&patch=zend_objects_get_address&revision=1360277847 [2013-02-07 21:35:26] m...@php.net Obviously a flaw in the way an object is identified in the engine/in the serializer. Since the cloned objects only live for the time of serialization, both have the same object handle and will be identified as the *same*. Not sure why unserialize barfs on it, though. [2013-02-07 19:37:35] ni...@php.net @slusarz: Github changed the Gist URLs to include the owner's name too. I guess they didn't consider users having number-names while doing that ^^ [2013-02-07 17:18:06] slusarz at curecanti dot org Strange... Since that is the link github provides when you click on "share". Anyway, try this instead: https://gist.github.com/slusarz/4709613 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 https://bugs.php.net/bug.php?id=64146 -- Edit this bug report at https://bugs.php.net/bug.php?id=64146&edit=1
Bug #65724 [Opn->Nab]: unserialize doesn't always restore referenced objects
Edit report at https://bugs.php.net/bug.php?id=65724&edit=1
ID: 65724
Updated by: m...@php.net
Reported by:niko dot sams at gmail dot com
Summary:unserialize doesn't always restore referenced
objects
-Status: Open
+Status: Not a bug
Type: Bug
Package:*General Issues
Operating System: Linux
PHP Version:5.5.4
Block user comment: N
Private report: N
New Comment:
We have a recursive context for Serializable, thus if you unserialize unrelated
strings in the unserialize callback, you literally throw bricks into the stream.
Previous Comments:
[2013-09-20 15:16:01] bixuehujin at gmail dot com
Had a test on commit
@8f146c2(https://github.com/php/php-src/commit/8f146c2bb0dcba3307f08a839554be056e660f34),
segfault occurred.
[2013-09-20 12:34:47] niko dot sams at gmail dot com
Description:
when doing another unserialize that creates objects in an
Serializable::unserialize implementation things break, the 'parent' isn't
unserialized correctly.
ok: PHP 5.3.3-7+squeeze14
ok: PHP 5.3.10-1ubuntu3.6
fail: PHP 5.4.4-14+deb7u2
fail: PHP 5.5.3
See phpt test script:
http://paste.kde.org/p83ce39d0/
Test script:
---
class Bar {}
class Foo implements Serializable {
public $test;
public function __construct($test) { $this->test = $test; }
public function serialize()
{
return $this->test;
}
public function unserialize($serialized)
{
//the following line causes problems
unserialize('O:3:"Bar":1:{s:4:"bar1";O:3:"Bar":0:{}}');
$this->test = $serialized;
}
}
$foo1 = new Foo('foo1');
$foo2 = new Foo('foo2');
$foo3 = new Foo('foo3');
$ar = array(
array(
'instance' => $foo1,
),
array(
'instance' => $foo2,
),
array(
'instance' => $foo3,
'parent' => $foo2
)
);
$ar = serialize($ar);
$ar = unserialize($ar);
print_r($ar);
Expected result:
[parent] => Foo Object ( [test] => foo2 ) )
Actual result:
--
[parent] => foo2
--
Edit this bug report at https://bugs.php.net/bug.php?id=65724&edit=1
Bug #65806 [Opn->Nab]: unserialize fails with object which is referenced multiple times
Edit report at https://bugs.php.net/bug.php?id=65806&edit=1
ID: 65806
Updated by: m...@php.net
Reported by:sysadmin at interexa dot de
Summary:unserialize fails with object which is referenced
multiple times
-Status: Open
+Status: Not a bug
Type: Bug
Package:*General Issues
Operating System: linux
PHP Version:5.4.20
Block user comment: N
Private report: N
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
The serialization context is reset and non-recursive in __sleep and __wakeup,
so if you serialize something in __sleep, you have to unserialize it in
__wakeup.
Previous Comments:
[2013-10-02 07:56:18] sysadmin at interexa dot de
Description:
Running the testscript fails. The second reference to Object A is null after
unserialize.
This happens in PHP 5.4.x as well as PHP 5.5.4.
Maybe this bug is related to bug 65724.
Test script:
---
_obj = $obj;
$this->_serialized = serialize($this->_obj);
}
public function get()
{
return unserialize($this->_serialized);
}
public function __sleep()
{
$this->_serialized = serialize($this->_obj);
return array(
"\0" . __CLASS__ . "\0_serialized",
);
}
}
echo "SCRIPT START" . PHP_EOL;
$objA = new myObjA();
$objB = new myObjB();
$objC = new myObjC();
$objB->attrA = new ArrayIterator();
$objB->attrB = $objA;
$objC->attrC = $objB;
$objC->attrD = $objA;
$list = new myList($objC);
echo 'check ' . check($list->get()) . PHP_EOL;
file_put_contents('serialize.dmp', serialize($list));
echo "start serialize/unserialize" . PHP_EOL;
$newList = unserialize(serialize($list));
echo "finish serialize/unserialize" . PHP_EOL;
//after unserialize the property myObjC::attrD is null instead of expected
object
echo 'check ' . check($newList->get()) . PHP_EOL;
echo "SCRIPT END" . PHP_EOL ;
function check(myObjC $obj) {
if (!is_object($obj->attrC)) {
return 'failed (myObjC::attrC => ' . var_export($obj->attrC, true) .
')';
}
if (!is_object($obj->attrD)) {
return 'failed (myObjC::attrD => ' . var_export($obj->attrD, true) .
')';
}
return 'successful';
}
Expected result:
SCRIPT START
check successful
start serialize/unserialize
finish serialize/unserialize
check successful
SCRIPT END
Actual result:
--
SCRIPT START
check successful
start serialize/unserialize
finish serialize/unserialize
check failed (myObjC::attrD => NULL)
SCRIPT END
--
Edit this bug report at https://bugs.php.net/bug.php?id=65806&edit=1
Req #53358 [Csd->ReO]: API queries in php.ini
Edit report at https://bugs.php.net/bug.php?id=53358&edit=1 ID: 53358 Updated by: m...@php.net Reported by:pophal at tubit dot tu-berlin dot de Summary:API queries in php.ini -Status: Closed +Status: Re-Opened Type: Feature/Change Request Package:PHP options/info functions PHP Version:* Assigned To:mike Block user comment: N Private report: N New Comment: Sorry, there actually is a PR for that: See bug #65681 and PR #466 https://github.com/php/php-src/pull/466 Previous Comments: [2013-09-30 12:16:28] m...@php.net We already have SAPI INIs. [2010-11-19 17:47:53] pophal at tubit dot tu-berlin dot de Description: I would rather appreciate a php ini section analogous to [HOST=] querying the SAPI, e.g. [SAPI=CLI] extension = php-gtk2.so in order to prevent the extension from being loaded when PHP is running as apache module or cgi. This would be helpful for distributions with like php.ini regardless of SAPI, in contrast to debian with its API-depending php.ini location. A workaround is a modified shebang line: #!/usr/bin/php -d extension=php_gtk2.so but this cannot be considered a good solution. Maybe this is not only php-gtk related. -- Edit this bug report at https://bugs.php.net/bug.php?id=53358&edit=1
Bug #64230 [Opn->Csd]: XMLReader does not suppress errors.
Edit report at https://bugs.php.net/bug.php?id=64230&edit=1
ID: 64230
Updated by: m...@php.net
Reported by:evert at rooftopsolutions dot nl
Summary:XMLReader does not suppress errors.
-Status: Open
+Status: Closed
Type: Bug
Package:XML Reader
Operating System: OS X 10.8
PHP Version:5.4.11
Block user comment: N
Private report: N
New Comment:
Automatic comment on behalf of mike
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=f6ff3a28d60c24dea2a05344d9b7eb823f09b4e5
Log: Fixed bug #64230 (XMLReader does not suppress errors)
Previous Comments:
[2013-02-18 00:44:55] evert at rooftopsolutions dot nl
Description:
Hi!
I would expect XML parsing errors to be suppressed when calling the
XMLReader::xml() with the LIBXML_NOERROR and LIBXML_NOWARNING options passed.
In addition, libxml_get_errors() also does not get populated with any xml
errors regardless of the settings used.
This makes it very hard to catch errors in an OOP-friendly way. The only true
option to handle errors, is to use set_error_handler(), but this is a bad
practice for libraries to use, as this modifies a global state.
Using libxml_use_internal_errors(true); has no further effect.
Test script:
---
XML;
libxml_use_internal_errors(true);
$reader = new XMLReader();
$reader->xml($xml, null, LIBXML_NOERROR | LIBXML_NOWARNING);
$reader->read();
print_r(libxml_get_errors());
Expected result:
No PHP errors thrown, and an error showing up in print_r
Actual result:
--
PHP Warning: XMLReader::read(): An Error Occured while reading in
/Users/evert/code/xml/errortest.php on line 11
PHP Stack trace:
PHP 1. {main}() /Users/evert/code/xml/errortest.php:0
PHP 2. XMLReader->read() /Users/evert/code/xml/errortest.php:11
Warning: XMLReader::read(): An Error Occured while reading in
/Users/evert/code/xml/errortest.php on line 11
Call Stack:
0.0003 226624 1. {main}() /Users/evert/code/xml/errortest.php:0
0.0005 227616 2. XMLReader->read()
/Users/evert/code/xml/errortest.php:11
Note that when the LIBXML constants, and libxml_use_internal_errors() are not
used, a 4 distinct PHP warnings are thrown. This would suggest that libxml
errors are indeed suppressed; but there's an error mechanism in XMLReader as
well.
--
Edit this bug report at https://bugs.php.net/bug.php?id=64230&edit=1
Bug #65827 [Nab]: error passing mysqli_fetch_assoc results back
Edit report at https://bugs.php.net/bug.php?id=65827&edit=1
ID: 65827
Updated by: m...@php.net
Reported by:ilantipov at gmail dot com
Summary:error passing mysqli_fetch_assoc results back
Status: Not a bug
Type: Bug
Package:MySQLi related
Operating System: Ubuntu 12.04.1 LTS
PHP Version:5.4.20
Block user comment: N
Private report: N
New Comment:
You've a dangling semi-colon in your while statement.
Previous Comments:
[2013-10-03 16:41:18] ilantipov at gmail dot com
Ok. I try to reconstruct it other way
$query = "SELECT t.forum_id, count(topic_id) AS count_sticky FROM phpbb_topics
as t, phpbb_prices_forums as f WHERE t.forum_id=f.forum_id AND f.forum_id IN
(509, 545, 25, 45, 543, 20, 35, 487, 223, 288, 224, 256) AND topic_type=1 and
topic_sticky_flag > 0 GROUP BY t.forum_id HAVING count_sticky <5";
$result = mysqli_query($link, $query) ;
print_r(mysqli_fetch_assoc($result));
print_r(mysqli_fetch_assoc($result));
gives:
Array
(
[forum_id] => 256
[count_sticky] => 4
)
Array
(
[forum_id] => 543
[count_sticky] => 1
)
this code works as well
$query = "SELECT t.forum_id, count(topic_id) AS count_sticky FROM phpbb_topics
as t, phpbb_prices_forums as f WHERE t.forum_id=f.forum_id AND f.forum_id IN
(509, 545, 25, 45, 543, 20, 35, 487, 223, 288, 224, 256) AND topic_type=1 and
topic_sticky_flag > 0 GROUP BY t.forum_id HAVING count_sticky <5";
$result = mysqli_query($link, $query) ;
$row2 = mysqli_fetch_assoc($result);
print_r($row2);
$row2 = mysqli_fetch_assoc($result);
print_r($row2);
output:
Array
(
[forum_id] => 256
[count_sticky] => 4
)
Array
(
[forum_id] => 543
[count_sticky] => 1
)
BUT
$query = "SELECT t.forum_id, count(topic_id) AS count_sticky FROM phpbb_topics
as t, phpbb_prices_forums as f WHERE t.forum_id=f.forum_id AND f.forum_id IN
(509, 545, 25, 45, 543, 20, 35, 487, 223, 288, 224, 256) AND topic_type=1 and
topic_sticky_flag > 0 GROUP BY t.forum_id HAVING count_sticky <5";
$result = mysqli_query($link, $query) ;
echo "now ready to get row\n";
while($row2 = mysqli_fetch_assoc($result));
{
echo "got row\n";
print($row2);
echo gettype($row2);
}
output is:
now ready to get row
got row
NULL
So here I used only php with no 3rd party sofware or functions. And this IS a
PHP bug.
Hope this additional hode will make it clear. Thank you for your attention.
[2013-10-03 16:01:20] m...@php.net
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.
[2013-10-03 15:43:58] ilantipov at gmail dot com
php configure options ./configure --enable-fpm --enable-libxml
--with-mcrypt --enable-mbstring --with-gd --with-mysql-sock
--with-mysqli=mysqlnd --with-pdo-mysql=mysqlnd --with-mysql=mysqlnd
--enable-sockets --with-iconv --with-gettext --with-zlib
--with-freetype-dir=/usr --with-jpeg-dir=/usr --prefix=/usr/local/php-fpm
--with-config-file-path=/usr/local/php-fpm/etc
--with-config-file-scan-dir=/usr/local/php-fpm/etc/conf.d
--with-fpm-user=www-data --with-fpm-group=www-data --disable-simplexml
--disable-xmlreader --disable-xmlwriter --disable-tokenizer
--without-sqlite3 --without-pdo-sqlite --with-curl
[2013-10-03 15:10:02] ilantipov at gmail dot com
Description:
mysqli_fetch_assoc($query_id) gives results, but
$row2 = $db->sql_fetchrow($result));
print_r($row2);
does not
Test script:
---
I am using phpbb3 while running a query
when I use this code
$query = "SELECT t.forum_id, count(topic_id) AS count_sticky FROM phpbb_topics
as t, phpbb_prices_forums as f WHERE t.forum_id=f.forum_id AND f.forum_id IN
(509, 545, 25, 45, 543, 20, 35, 487, 223, 288, 224, 256) AND topic_type=1 and
topic_sticky_flag > 0 GROUP BY t.forum_id HAVING count_sticky <5";
if ($result = mysqli_query($link, $query)) {
while ($row = mysqli_fetch_row($result)) {
printf ("%s (%s)\n", $row[0], $row[1]);
}
}
I get
256 (4)
543 (1)
Which is ok. But when I'm using this code
$result = $db->sql_query($sql);
while($row2 = $db->sql_fetchrow($result));
{
print($row2);
}
I get nothing. And gettype($row2) gives NULL
$db->sql_fetchrow in minimal configuration to reproduce a bug is:
function sql
Bug #65827 [Opn->Nab]: error passing mysqli_fetch_assoc results back
Edit report at https://bugs.php.net/bug.php?id=65827&edit=1
ID: 65827
Updated by: m...@php.net
Reported by:ilantipov at gmail dot com
Summary:error passing mysqli_fetch_assoc results back
-Status: Open
+Status: Not a bug
Type: Bug
Package:MySQLi related
Operating System: Ubuntu 12.04.1 LTS
PHP Version:5.4.20
Block user comment: N
Private report: N
New Comment:
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.
Previous Comments:
[2013-10-03 15:43:58] ilantipov at gmail dot com
php configure options ./configure --enable-fpm --enable-libxml
--with-mcrypt --enable-mbstring --with-gd --with-mysql-sock
--with-mysqli=mysqlnd --with-pdo-mysql=mysqlnd --with-mysql=mysqlnd
--enable-sockets --with-iconv --with-gettext --with-zlib
--with-freetype-dir=/usr --with-jpeg-dir=/usr --prefix=/usr/local/php-fpm
--with-config-file-path=/usr/local/php-fpm/etc
--with-config-file-scan-dir=/usr/local/php-fpm/etc/conf.d
--with-fpm-user=www-data --with-fpm-group=www-data --disable-simplexml
--disable-xmlreader --disable-xmlwriter --disable-tokenizer
--without-sqlite3 --without-pdo-sqlite --with-curl
[2013-10-03 15:10:02] ilantipov at gmail dot com
Description:
mysqli_fetch_assoc($query_id) gives results, but
$row2 = $db->sql_fetchrow($result));
print_r($row2);
does not
Test script:
---
I am using phpbb3 while running a query
when I use this code
$query = "SELECT t.forum_id, count(topic_id) AS count_sticky FROM phpbb_topics
as t, phpbb_prices_forums as f WHERE t.forum_id=f.forum_id AND f.forum_id IN
(509, 545, 25, 45, 543, 20, 35, 487, 223, 288, 224, 256) AND topic_type=1 and
topic_sticky_flag > 0 GROUP BY t.forum_id HAVING count_sticky <5";
if ($result = mysqli_query($link, $query)) {
while ($row = mysqli_fetch_row($result)) {
printf ("%s (%s)\n", $row[0], $row[1]);
}
}
I get
256 (4)
543 (1)
Which is ok. But when I'm using this code
$result = $db->sql_query($sql);
while($row2 = $db->sql_fetchrow($result));
{
print($row2);
}
I get nothing. And gettype($row2) gives NULL
$db->sql_fetchrow in minimal configuration to reproduce a bug is:
function sql_fetchrow($query_id = false)
{
return mysqli_fetch_assoc($query_id);
}
If I rewrite my code to
$result = $db->sql_query($sql);
print_r($db->sql_fetchrow($result));
print_r($db->sql_fetchrow($result));
I get
Array
(
[forum_id] => 256
[count_sticky] => 4
)
Array
(
[forum_id] => 543
[count_sticky] => 1
)
The other variant of code:
$result = $db->sql_query($sql);
$row2 = $db->sql_fetchrow($result);
print_r($row2);
$row2 = $db->sql_fetchrow($result);
print_r($row2);
Gives good results as well. It works as acpected.
So the bug occures only in this case - when passing back results to 'while'
loop as a result of other function. All other queries work perfect on a
production server. And I have the same issues on 2 servers with PHP 5.4.17 and
PHP 5.4.20 running.
Any other info can be sent if needed.
--
Edit this bug report at https://bugs.php.net/bug.php?id=65827&edit=1
Bug #55285 [Opn->Csd]: XMLReader::getAttribute/No/Ns methods inconsistency
Edit report at https://bugs.php.net/bug.php?id=55285&edit=1
ID: 55285
Updated by: m...@php.net
Reported by:evoloshchuk at gmail dot com
Summary:XMLReader::getAttribute/No/Ns methods inconsistency
-Status: Open
+Status: Closed
Type: Bug
Package:XML Reader
Operating System: Mac OS X 10.6.3
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
Automatic comment on behalf of mike
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=c7b1d76eb9d09b0331272143e44e5024468b0fea
Log: fix bug #55285 XMLReader::getAttribute/No/Ns methods inconsistency
Previous Comments:
[2011-07-26 12:18:24] evoloshchuk at gmail dot com
Description:
There are three methods available to retrieve an attribute - getAttribute,
getAttributeNo, getAttributeNs.
It seems to be natural to expect the similar kind of behavior from them in case
when no attribute by given parameters is found.
Which is not the case - first one returns NULL, the rest - string(0) "".
Test script:
---
xml('');
$reader->read();
var_dump($reader->getAttribute('x'));
var_dump($reader->getAttributeNs('x', 'http://example.com'));
var_dump($reader->getAttributeNo(2));
?>
Expected result:
NULL
NULL
NULL
Actual result:
--
NULL
string(0) ""
string(0) ""
--
Edit this bug report at https://bugs.php.net/bug.php?id=55285&edit=1
Bug #61587 [Opn->Nab]: XMLReader - invalid schema error using ampersands
Edit report at https://bugs.php.net/bug.php?id=61587&edit=1
ID: 61587
Updated by: m...@php.net
Reported by:ryan dot brothers at gmail dot com
Summary:XMLReader - invalid schema error using ampersands
-Status: Open
+Status: Not a bug
Type: Bug
Package:XML Reader
Operating System: Linux
PHP Version:5.3.10
Block user comment: N
Private report: N
New Comment:
I'm not an (lib)xml expert, but using LIBXML_NOENT as parsing options for the
XMLReader aligns the behaviour:
$xmlreader->xml($xml, null, LIBXML_NOENT);
Previous Comments:
[2012-03-31 22:59:01] ryan dot brothers at gmail dot com
Description:
In the following test script, the example xml is valid against the supplied
schema. DOMDocument displays no schema errors as expected, but XMLReader
displays a schema violation. I was expecting XMLReader to not report any
schema violations.
Test script:
---
';
$schema = '
http://www.w3.org/2001/XMLSchema";>
';
// create temp file with schema
$schema_file = tempnam(sys_get_temp_dir(), '');
file_put_contents($schema_file, $schema);
// test with DOMDocument
$dom = new DOMDocument;
$dom->loadXML($xml);
$dom->schemaValidate($schema_file);
// test with XMLReader
$xmlreader = new XMLReader;
$xmlreader->xml($xml);
$xmlreader->setSchema($schema_file);
while ($xmlreader->read() == true);
$xmlreader->close();
// delete temp file
unlink($schema_file);
Expected result:
No output
Actual result:
--
Warning: XMLReader::read(): Element 'user', attribute 'name': [facet
'enumeration'] The value 'a & b' is not an element of the set {'a & b'}. in
test.php on line 38
Warning: XMLReader::read(): Element 'user', attribute 'name': 'a & b' is
not a valid value of the local atomic type. in test.php on line 38
--
Edit this bug report at https://bugs.php.net/bug.php?id=61587&edit=1
Bug #61957 [Opn->Nab]: XMLReader::open(): Unable to open source data i
Edit report at https://bugs.php.net/bug.php?id=61957&edit=1
ID: 61957
Updated by: m...@php.net
Reported by:dean dot sanderson at 3dgroupuk dot com
Summary:XMLReader::open(): Unable to open source data i
-Status: Open
+Status: Not a bug
Type: Bug
Package:XML Reader
Operating System: Windows
PHP Version:5.3.12
Block user comment: N
Private report: N
New Comment:
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.
Previous Comments:
[2012-05-06 14:05:10] dean dot sanderson at 3dgroupuk dot com
Sorry i did try this before. But to double check i did it again using
urlencode. Still the same error.
Url give was:
http://images.gwales.com/cgi-bin/xmlif?userid=1&password=canolfan&sql=SELECT%20*%20FROM%20(SELECT%20isbn,%20price_vat,pub_code,available,title,author,publication_date,link_to_marketing,medium,prod_lang_code,c1.CATEGORY_DESCRIPTION%20text_category,c2.CATEGORY_DESCRIPTION%20text_sub_category,DESC1,DESC2,PROD_SIZE,PAGES,%20row_number()%20OVER%20(ORDER%20BY%20ISBN)%20rn%20FROM%20PRODUCTS,%20CATEGORIES%20c1,%20CATEGORIES%20c2%20WHERE%20INVALID='N'%20AND%20ORDER_ALLOWED_OME='Y'%20AND%20c1.CATEGORY=PRODUCTS.CATEGORY%20AND%20c2.CATEGORY=PRODUCTS.SUB_CATEGORY)%20WHERE%20rn%20BETWEEN%201%20and%205%20ORDER%20BY%20rn
[2012-05-06 10:44:37] paj...@php.net
Encode the URI correctly and it should work fine.
[2012-05-06 01:15:04] dean dot sanderson at 3dgroupuk dot com
Description:
It seems this function doesn't like long url's
$z = new XMLReader;
$z->open("http://images.gwales.com/cgi-bin/xmlif?userid=1&password=canolfan&sql=SELECT
* FROM (SELECT isbn,
price_vat,pub_code,available,title,author,publication_date,link_to_marketing,medium,prod_lang_code,c1.CATEGORY_DESCRIPTION
text_category,c2.CATEGORY_DESCRIPTION
text_sub_category,DESC1,DESC2,PROD_SIZE,PAGES, row_number() OVER (ORDER BY
ISBN) rn FROM PRODUCTS, CATEGORIES c1, CATEGORIES c2 WHERE INVALID='N' AND
ORDER_ALLOWED_OME='Y' AND c1.CATEGORY=PRODUCTS.CATEGORY AND
c2.CATEGORY=PRODUCTS.SUB_CATEGORY) WHERE rn BETWEEN 1 and 10 ORDER BY rn");
returns
XMLReader::open(): Unable to open source data
this error has started to apear since upgrading from php 5.2 to 5.3
Test script:
---
Tried
$z = new XMLReader;
$z->open("http://www.w3schools.com/xml/cd_catalog.xml";);
works fine.
--
Edit this bug report at https://bugs.php.net/bug.php?id=61957&edit=1
Bug #60511 [Opn->Fbk]: XMLReader chokes on mid-size 'single line' documents
Edit report at https://bugs.php.net/bug.php?id=60511&edit=1 ID: 60511 Updated by: m...@php.net Reported by:r dot altenburg at eti dot uva dot nl Summary:XMLReader chokes on mid-size 'single line' documents -Status: Open +Status: Feedback Type: Bug Package:XML Reader Operating System: Mac OS X 10.6.8 PHP Version:5.3.8 Block user comment: N Private report: N New Comment: Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. Looks fine here, the script spends lots of time in preg_replace. Previous Comments: [2011-12-13 15:36:55] r dot altenburg at eti dot uva dot nl Expected result should be a completely parsed XML file of course... [2011-12-13 15:35:45] r dot altenburg at eti dot uva dot nl Description: I must say in honesty that I have only verified in 5.3.6 and 5.2.17, I have no option to verify in the very latest versions. I have created a script that parses large XML files. Essentially these files are single line documents without returns between the tags. When running the script (see URL), I get a timeout after processing just a few nodes. Incidentally I had a copy of the same XML file at hand that had been formatted for readability in BBEdit. To my surprise this version was parsed to the very end! Test script: --- Test script http://test.etibioinformatics.nl/xmlreader/index.php.zip Two version of the same XML file http://test.etibioinformatics.nl/xmlreader/xml.zip Expected result: Timeout -- Edit this bug report at https://bugs.php.net/bug.php?id=60511&edit=1
Bug #51936 [Asn->Csd]: Crash with clone xmlreader
Edit report at https://bugs.php.net/bug.php?id=51936&edit=1
ID: 51936
Updated by: m...@php.net
Reported by:Keisial at gmail dot com
Summary:Crash with clone xmlreader
-Status: Assigned
+Status: Closed
Type: Bug
Package:XML Reader
PHP Version:5.3.2
Assigned To:rrichards
Block user comment: N
Private report: N
New Comment:
Automatic comment on behalf of mike
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=dc3d360a0ff8c17cb2ce2030813d30b578249be9
Log: typo: really fix bug #51936Crash with clone xmlreader
Previous Comments:
[2010-05-27 20:20:27] johan...@php.net
#0 0xfd7ffb7e92c4 in xmlTextReaderNext () from /lib/64/libxml2.so.2
#1 0x008661f9 in zim_xmlreader_next (ht=0, return_value=0xd77f88,
return_value_ptr=0x0, this_ptr=0xd79b48, return_value_used=0)
at
/export/home/johannes/src/php/src/php/php-src/branches/PHP_5_3/ext/xmlreader/php_xmlreader.c:842
#2 0x0093b02e in zend_do_fcall_common_helper_SPEC (
execute_data=0x1025500)
at
/export/home/johannes/src/php/src/php/php-src/branches/PHP_5_3/Zend/zend_vm_execute.h:313
#3 0x0093bc9d in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (
execute_data=0x1025500)
at
/export/home/johannes/src/php/src/php/php-src/branches/PHP_5_3/Zend/zend_vm_execute.h:418
#4 0x0093a31d in execute (op_array=0xd77c68)
at
/export/home/johannes/src/php/src/php/php-src/branches/PHP_5_3/Zend/zend_vm_execute.h:104
#5 0x0090c86a in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at
/export/home/johannes/src/php/src/php/php-src/branches/PHP_5_3/Zend/zend.c:1194
#6 0x008a0c6c in php_execute_script (primary_file=0xfd7fffdff690)
at
/export/home/johannes/src/php/src/php/php-src/branches/PHP_5_3/main/main.c:2233
#7 0x009e0fe6 in main (argc=1, argv=0xfd7fffdff768)
at
/export/home/johannes/src/php/src/php/php-src/branches/PHP_5_3/sapi/cli/php_cli.c:1192
[2010-05-27 20:02:39] Keisial at gmail dot com
Description:
Trying to use a cloned xmlreader results in a crash (original one can be used
fine).
php 5.3.2
libxml2 2.7.7-1
Test script:
---
xml("");
$xmlreader->next();
$xmlreader2 = clone $xmlreader;
$xmlreader2->next();
Actual result:
--
Program received signal SIGSEGV, Segmentation fault in
xmlTextReaderNext__internal_alias ()
--
Edit this bug report at https://bugs.php.net/bug.php?id=51936&edit=1
Bug #60633 [Opn]: build warning
Edit report at https://bugs.php.net/bug.php?id=60633&edit=1 ID: 60633 Updated by: m...@php.net Reported by:fedora at famillecollet dot com Summary:build warning Status: Open Type: Bug Package:BC math related Operating System: GNU/Linux (Fedora 16) PHP Version:5.4SVN-2012-01-01 (snap) Block user comment: N Private report: N New Comment: Haha, I couldn't either... :) Anyway the lib source is full of PHP macros, so I think it's pretty fine if you fix those at hand! Previous Comments: [2013-10-03 06:27:04] r...@php.net @Mike, I can't find upstream for this library... So I don't know if we can fix those "trivial" build warning in the php tree (the reason why I kept this bug open, while I can have commit the patch) [2013-10-02 09:39:06] m...@php.net Nevermind the last comment. [2013-10-02 09:27:26] m...@php.net Do we already patch this lib, or is it untouched? [2012-01-01 08:32:23] fedora at famillecollet dot com Description: Build warning Test script: --- make Expected result: No warning Actual result: -- /home/rpmbuild/BUILD/php5.4-201112300630/ext/bcmath/libbcmath/src/recmul.c: In function '_bc_rec_mul': /home/rpmbuild/BUILD/php5.4-201112300630/ext/bcmath/libbcmath/src/recmul.c:186:14: warning: variable 'v0len' set but not used [-Wunused-but-set-variable] /home/rpmbuild/BUILD/php5.4-201112300630/ext/bcmath/libbcmath/src/recmul.c:186:7: warning: variable 'u0len' set but not used [-Wunused-but-set-variable] -- Edit this bug report at https://bugs.php.net/bug.php?id=60633&edit=1
Bug #64340 [ReO]: sockets tests failed
Edit report at https://bugs.php.net/bug.php?id=64340&edit=1 ID: 64340 Updated by: m...@php.net Reported by:re...@php.net Summary:sockets tests failed Status: Re-Opened Type: Bug Package:Sockets related Operating System: Mac OSX 10.8 PHP Version:5.5.0alpha5 Assigned To:laruence Block user comment: N Private report: N New Comment: Any update on this? Previous Comments: [2013-03-05 11:34:00] larue...@php.net there is one workaround: #ifdef __APPLE__ #define IPV6_PKTINFOIPV6_2292PKTINFO #define IPV6_HOPLIMIT IPV6_2292HOPLIMIT #define IPV6_NEXTHOPIPV6_2292NEXTHOP #define IPV6_HOPOPTSIPV6_2292HOPOPTS #define IPV6_DSTOPTSIPV6_2292DSTOPTS #define IPV6_RTHDR IPV6_2292RTHDR #define IPV6_PKTOPTIONS IPV6_2292PKTOPTIONS #endif will keep finding more better solution [2013-03-05 10:47:57] re...@php.net Hi, the attached patch is intend to fix IPV6_PKTINFO failure, the commit didn't contain all of the fix. but only the macro define. The patch isn't break build. but the partially applied patch. only define __APPLE_USE_RFC is not enough. the rest of the changes should be applied too. I couldn't figure out a better solution which didn't require header inclusion order, since the macro itself required to be defined first. [2013-03-05 06:05:33] larue...@php.net I revert the previous fix, since the build broken. I am wondering, if don't fix that, what's the problem is? thanks [2013-03-05 06:04:06] larue...@php.net Automatic comment on behalf of laruence Revision: http://git.php.net/?p=php-src.git;a=commit;h=3f67d5ae434236be1db2ee54baf85725ac7b6a56 Log: Revert "Fixed Bug #64340 (sockets tests failed) Patch by Reeze" [2013-03-05 05:58:56] larue...@php.net Automatic comment on behalf of laruence Revision: http://git.php.net/?p=php-src.git;a=commit;h=3f67d5ae434236be1db2ee54baf85725ac7b6a56 Log: Revert "Fixed Bug #64340 (sockets tests failed) Patch by Reeze" 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 https://bugs.php.net/bug.php?id=64340 -- Edit this bug report at https://bugs.php.net/bug.php?id=64340&edit=1
Bug #63570 [Asn]: Bogus warning 'Operation now in progress'
Edit report at https://bugs.php.net/bug.php?id=63570&edit=1 ID: 63570 Updated by: m...@php.net Reported by:kakserpompoyaitsam at gmail dot com Summary:Bogus warning 'Operation now in progress' Status: Assigned Type: Bug Package:Sockets related Operating System: linux PHP Version:5.4.8 Assigned To:cataphract Block user comment: N Private report: N New Comment: Gustavo? Looks good to me. Previous Comments: [2013-06-24 18:08:17] fel...@php.net Gustavo, what do you think about the patch? [2012-12-03 11:57:06] osma...@php.net I've uploaded a simple patch. But I'd rather do it via exceptions as in other languages like Python. [2012-12-03 11:54:03] osma...@php.net The following patch has been added/updated: Patch Name: ignore-warnings-for-nonblocking Revision: 1354535643 URL: https://bugs.php.net/patch-display.php?bug=63570&patch=ignore-warnings-for-nonblocking&revision=1354535643 [2012-11-28 12:41:30] osma...@php.net The following patch has been added/updated: Patch Name: ignore-EINPROGRESS-warning-nonblocking-2 Revision: 1354106490 URL: https://bugs.php.net/patch-display.php?bug=63570&patch=ignore-EINPROGRESS-warning-nonblocking-2&revision=1354106490 [2012-11-28 12:40:08] osma...@php.net The following patch has been added/updated: Patch Name: ignore-EINPROGRESS-warning-nonblocking Revision: 1354106408 URL: https://bugs.php.net/patch-display.php?bug=63570&patch=ignore-EINPROGRESS-warning-nonblocking&revision=1354106408 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 https://bugs.php.net/bug.php?id=63570 -- Edit this bug report at https://bugs.php.net/bug.php?id=63570&edit=1
Bug #65808 [Ver->Csd]: the socket_connect() won't work with IPv6 address
Edit report at https://bugs.php.net/bug.php?id=65808&edit=1
ID: 65808
Updated by: m...@php.net
Reported by:wzis at hotmail dot com
Summary:the socket_connect() won't work with IPv6 address
-Status: Verified
+Status: Closed
Type: Bug
Package:Sockets related
Operating System: Linux
PHP Version:5.5.4
Assigned To: mike
Block user comment: N
Private report: N
New Comment:
Automatic comment on behalf of mike
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=9209c19f8f7eef807cb457b32d3ab517ff8dc178
Log: fix bug #65808 the socket_connect() won't work with IPv6 address
Previous Comments:
[2013-10-02 10:11:47] wzis at hotmail dot com
Description:
No matter give fe80::a00:27ff:fe3d:af20 or fe80::a00:27ff:fe3d:af20%eth0 as the
address, the socket_connect will just fail.
>From strace and the PHP source code, what I found is the sin6_scope_id always
>equals to 0, while with telnet when passed in fe80::a00:27ff:fe3d:af20%eth0,
>from strace, we got sin6_scope_id=if_nametoindex("eth0"). So the
>socket_connect code needs be changed for proper IPv6 support.
Test script:
---
#!/usr/bin/php
Expected result:
If you run the script with
./phpscript 2606:4100:3880:1250::100 80
You should see "Connected to 2606:4100:3880:1250::100 port 80"
Actual result:
--
PHP Warning: socket_connect(): unable to connect [22]: Invalid argument in
phpscript on line 4.
--
Edit this bug report at https://bugs.php.net/bug.php?id=65808&edit=1
Bug #65808 [Opn->Ver]: the socket_connect() won't work with IPv6 address
Edit report at https://bugs.php.net/bug.php?id=65808&edit=1
ID: 65808
Updated by: m...@php.net
Reported by:wzis at hotmail dot com
Summary:the socket_connect() won't work with IPv6 address
-Status: Open
+Status: Verified
Type: Bug
Package:Sockets related
Operating System: Linux
PHP Version:5.5.4
-Assigned To:
+Assigned To: mike
Block user comment: N
Private report: N
Previous Comments:
[2013-10-02 10:11:47] wzis at hotmail dot com
Description:
No matter give fe80::a00:27ff:fe3d:af20 or fe80::a00:27ff:fe3d:af20%eth0 as the
address, the socket_connect will just fail.
>From strace and the PHP source code, what I found is the sin6_scope_id always
>equals to 0, while with telnet when passed in fe80::a00:27ff:fe3d:af20%eth0,
>from strace, we got sin6_scope_id=if_nametoindex("eth0"). So the
>socket_connect code needs be changed for proper IPv6 support.
Test script:
---
#!/usr/bin/php
Expected result:
If you run the script with
./phpscript 2606:4100:3880:1250::100 80
You should see "Connected to 2606:4100:3880:1250::100 port 80"
Actual result:
--
PHP Warning: socket_connect(): unable to connect [22]: Invalid argument in
phpscript on line 4.
--
Edit this bug report at https://bugs.php.net/bug.php?id=65808&edit=1
Bug #65812 [Fbk]: Func returns NULL if last stmt is 'Exception' or 'die' inside unreachable else
Edit report at https://bugs.php.net/bug.php?id=65812&edit=1
ID: 65812
Updated by: m...@php.net
Reported by:florian dot mueller at hostpoint dot ch
Summary:Func returns NULL if last stmt is 'Exception' or
'die' inside unreachable else
Status: Feedback
Type: Bug
Package:CGI/CLI related
Operating System: freebsd 9.2
PHP Version:5.5.4
Block user comment: N
Private report: N
New Comment:
Disable opcache while you're at it.
Previous Comments:
[2013-10-02 12:20:17] ni...@php.net
I can't reproduce this on Ubuntu, so this is either FreeBSD specific or has
something to do with your environment. Could you try running your script with
`php-cgi -n` and see if the problem persists?
[2013-10-02 12:00:03] florian dot mueller at hostpoint dot ch
Description:
Important: The problem occurs only with php-cgi binary and not with php binary.
The problem is, that the following snipped returns NULL instead of true. My
guess is, that it has to do with a) if($variable) and b) the fact that "throw
new Exception" is the last expression before return.
function testMinimal(){
$foo = true;
if($foo){
echo '';
} else {
throw new Exception('foo');
}
return true;
}
A attached a test script with several cases.
For example this one returns NULL as well:
function testMinimalDie(){
$foo = true;
if($foo){
echo '';
} else {
die();
}
return true;
}
whereas those two work:
function testMinimalNoVar(){
if(true){
echo '';
} else {
throw new Exception('foo');
}
return true;
}
function testMinimalHack(){
$foo = true;
if($foo){
echo '';
} else {
throw new Exception('foo');
}
$someUnrelatedVariable=1;
return true;
}
Test script:
---
Expected result:
testMinimal bool(true)
testMinimalOk bool(true)
testMinimalNoEx bool(true)
testMinimalDie bool(true)
testMinimalDivZero bool(true)
testMinimalNoVar bool(true)
testMinimalEEE bool(true)
testMinimalEE bool(true)
testMinimalReturnFalse bool(true)
testMinimalHack bool(true)
Actual result:
--
testMinimal NULL
testMinimalOk bool(true)
testMinimalNoEx bool(true)
testMinimalDie NULL
testMinimalDivZero bool(true)
testMinimalNoVar bool(true)
testMinimalEEE NULL
testMinimalEE NULL
testMinimalReturnFalse bool(true)
testMinimalHack bool(true)
--
Edit this bug report at https://bugs.php.net/bug.php?id=65812&edit=1
Bug #55160 [Opn->Nab]: Unexpected result on bccomp when using any decimal comma locale
Edit report at https://bugs.php.net/bug.php?id=55160&edit=1 ID: 55160 Updated by: m...@php.net Reported by:everton at faccat dot br Summary:Unexpected result on bccomp when using any decimal comma locale -Status: Open +Status: Not a bug Type: Bug Package:BC math related Operating System: Ubuntu 10.04 LTS 64bits PHP Version:trunk-SVN-2011-07-08 (snap) Block user comment: N Private report: N New Comment: Nevertheless it is expected behaviour. Argument type of these functions is string. This is a bug report about an unexpected result not a feature request to implement some magic non-locale-aware string cast. Sorry :) Previous Comments: [2013-10-02 10:07:14] ni...@php.net @mike PHP's shitty float to string cast shouldn't impede the workings of bcmath. We've had this problem in the past several times (with stuff like JSON etc) and the solution is to use some custom printf modifier for this. [2013-10-02 09:29:09] m...@php.net This is actually expected behaviour because bcmath operates on strings and PHP casts numbers to strings according to locale. [2011-07-08 08:36:47] everton at faccat dot br added OS additional information [2011-07-08 08:27:56] everton at faccat dot br Description: Unexpected result on bccomp when using any decimal comma locale. If an operand is a fraction, and the other is zero, the result seems to be wrong. Test script: --- Expected result: C 1.1 1 en_DK.UTF-8 1,1 1 pt_BR.UTF-8 1,1 1 Actual result: -- C 1.1 1 en_DK.UTF-8 1,1 0 pt_BR.UTF-8 1,1 0 -- Edit this bug report at https://bugs.php.net/bug.php?id=55160&edit=1
Bug #60633 [Fbk->Opn]: build warning
Edit report at https://bugs.php.net/bug.php?id=60633&edit=1 ID: 60633 Updated by: m...@php.net Reported by:fedora at famillecollet dot com Summary:build warning -Status: Feedback +Status: Open Type: Bug Package:BC math related Operating System: GNU/Linux (Fedora 16) PHP Version:5.4SVN-2012-01-01 (snap) Block user comment: N Private report: N New Comment: Nevermind the last comment. Previous Comments: [2013-10-02 09:27:26] m...@php.net Do we already patch this lib, or is it untouched? [2012-01-01 08:32:23] fedora at famillecollet dot com Description: Build warning Test script: --- make Expected result: No warning Actual result: -- /home/rpmbuild/BUILD/php5.4-201112300630/ext/bcmath/libbcmath/src/recmul.c: In function '_bc_rec_mul': /home/rpmbuild/BUILD/php5.4-201112300630/ext/bcmath/libbcmath/src/recmul.c:186:14: warning: variable 'v0len' set but not used [-Wunused-but-set-variable] /home/rpmbuild/BUILD/php5.4-201112300630/ext/bcmath/libbcmath/src/recmul.c:186:7: warning: variable 'u0len' set but not used [-Wunused-but-set-variable] -- Edit this bug report at https://bugs.php.net/bug.php?id=60633&edit=1
Bug #55160 [Opn->Nab]: Unexpected result on bccomp when using any decimal comma locale
Edit report at https://bugs.php.net/bug.php?id=55160&edit=1 ID: 55160 Updated by: m...@php.net Reported by:everton at faccat dot br Summary:Unexpected result on bccomp when using any decimal comma locale -Status: Open +Status: Not a bug Type: Bug Package:BC math related Operating System: Ubuntu 10.04 LTS 64bits PHP Version:trunk-SVN-2011-07-08 (snap) Block user comment: N Private report: N New Comment: This is actually expected behaviour because bcmath operates on strings and PHP casts numbers to strings according to locale. Previous Comments: [2011-07-08 08:36:47] everton at faccat dot br added OS additional information [2011-07-08 08:27:56] everton at faccat dot br Description: Unexpected result on bccomp when using any decimal comma locale. If an operand is a fraction, and the other is zero, the result seems to be wrong. Test script: --- Expected result: C 1.1 1 en_DK.UTF-8 1,1 1 pt_BR.UTF-8 1,1 1 Actual result: -- C 1.1 1 en_DK.UTF-8 1,1 0 pt_BR.UTF-8 1,1 0 -- Edit this bug report at https://bugs.php.net/bug.php?id=55160&edit=1
Bug #60633 [Opn->Fbk]: build warning
Edit report at https://bugs.php.net/bug.php?id=60633&edit=1 ID: 60633 Updated by: m...@php.net Reported by:fedora at famillecollet dot com Summary:build warning -Status: Open +Status: Feedback Type: Bug Package:BC math related Operating System: GNU/Linux (Fedora 16) PHP Version:5.4SVN-2012-01-01 (snap) Block user comment: N Private report: N New Comment: Do we already patch this lib, or is it untouched? Previous Comments: [2012-01-01 08:32:23] fedora at famillecollet dot com Description: Build warning Test script: --- make Expected result: No warning Actual result: -- /home/rpmbuild/BUILD/php5.4-201112300630/ext/bcmath/libbcmath/src/recmul.c: In function '_bc_rec_mul': /home/rpmbuild/BUILD/php5.4-201112300630/ext/bcmath/libbcmath/src/recmul.c:186:14: warning: variable 'v0len' set but not used [-Wunused-but-set-variable] /home/rpmbuild/BUILD/php5.4-201112300630/ext/bcmath/libbcmath/src/recmul.c:186:7: warning: variable 'u0len' set but not used [-Wunused-but-set-variable] -- Edit this bug report at https://bugs.php.net/bug.php?id=60633&edit=1
Bug #63338 [Opn->Csd]: php_stream_url_wrap_http_ex() function
Edit report at https://bugs.php.net/bug.php?id=63338&edit=1
ID: 63338
Updated by: m...@php.net
Reported by:phpor dot net at gmail dot com
Summary:php_stream_url_wrap_http_ex() function
-Status: Open
+Status: Closed
Type: Bug
Package:HTTP related
Operating System: all
PHP Version:5.4.8
-Assigned To:
+Assigned To:mike
Block user comment: N
Private report: N
New Comment:
Fixed in recent versions.
Previous Comments:
[2012-10-23 08:50:19] phpor dot net at gmail dot com
Description:
in function php_stream_url_wrap_http_ex has some codes like :
-- ext/standard/http_fopen_wrapper.c
php_stream *php_stream_url_wrap_http_ex(php_stream_wrapper *wrapper, char
*path,
char *mode, int options, char **opened_path, php_stream_context *context, int
redirect_max, int flags STREAMS_DC TSRMLS_DC) /* {{{ */
{
...
if (*e != '\n') {
do { /* partial header */
php_stream_get_line(stream,
http_header_line, HTTP_HEADER_BLOCK_SIZE, &http_header_line_length);
e = http_header_line +
http_header_line_length - 1;
} while (*e != '\n');
continue;
}
...
}
-
in this code block , it not check the result of php_stream_get_line(...) ; if
the stream lost connect at this time ,and the http header line not end ,then it
will be cycle forever.
Test script:
---
--- server.php
--- end
--- client.php
http://localhost:9090/";);
exit;
?>
--- end
start server.php :
#mkfifo /tmp/fifo
#nc -l localhost -p 9090 /tmp/fifo
start client.php :
#php client.php
now , the client.php will cycle forever
Expected result:
expect return fail
Actual result:
--
the client.php will cycle forever
--
Edit this bug report at https://bugs.php.net/bug.php?id=63338&edit=1
Bug #65671 [Opn]: Remove "experimental" status from six pg_* functions
Edit report at https://bugs.php.net/bug.php?id=65671&edit=1 ID: 65671 Updated by: m...@php.net Reported by:krewecherl at gmail dot com Summary:Remove "experimental" status from six pg_* functions Status: Open Type: Bug Package:PostgreSQL related PHP Version:Irrelevant -Assigned To: +Assigned To:yohgaki Block user comment: N Private report: N New Comment: Yasuo, what's your thought on this? Previous Comments: [2013-09-13 21:30:38] krewecherl at gmail dot com Description: The following six functions have been added in PHP 4.3: - pg_convert() - pg_delete() - pg_insert() - pg_meta_data() - pg_select() - pg_update() They been marked as EXPERIMENTAL for close to eleven years now, effectively preventing anybody from using them outside of test environments. Ten years is too long for an experiment. The functions should either be removed from PHP, or moved to a PECL extension, or documented as safe to use. All of them perform useful tasks, so my personal preference would be the latter option. -- Edit this bug report at https://bugs.php.net/bug.php?id=65671&edit=1
Bug #65199 [Opn]: pg_copy_from() modifies input array variable
Edit report at https://bugs.php.net/bug.php?id=65199&edit=1
ID: 65199
Updated by: m...@php.net
Reported by:thuejk at gmail dot com
Summary:pg_copy_from() modifies input array variable
Status: Open
Type: Bug
Package:PostgreSQL related
Operating System: Linux (all?)
PHP Version:5.5.0
-Assigned To:
+Assigned To:yohgaki
Block user comment: N
Private report: N
New Comment:
Yasuo, can you have a look, please? Probably just a separation issue.
Previous Comments:
[2013-07-03 23:04:57] thuejk at gmail dot com
Description:
The variable holding the array of values I pass to pg_copy_from() is modified
by
pg_copy_from() (ints are changed to strings). Even though there is no pass-by-
reference involved.
This bug also exists in PHP 5.2 at least.
Test script:
---
Expected result:
The two var_dump()s should return identical outputs.
Actual result:
--
t@t ~/php/php-5.5.0> ./sapi/cli/php ~/test.php
array(3) {
[0]=>
int(1)
[1]=>
int(2)
[2]=>
int(3)
}
array(3) {
[0]=>
string(1) "1"
[1]=>
string(1) "2"
[2]=>
string(1) "3"
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=65199&edit=1
Bug #58782 [Opn->Wfx]: installation from pecl failed
Edit report at https://bugs.php.net/bug.php?id=58782&edit=1 ID: 58782 Updated by: m...@php.net Reported by:mac dot komarov at gmail dot com Summary:installation from pecl failed -Status: Open +Status: Wont fix Type: Bug -Package:phar +Package:*General Issues Operating System: Linux (Fedora 11) PHP Version:5.2.9 Block user comment: N Private report: N New Comment: PECL PHAR package is obsolete. Previous Comments: [2012-07-03 16:00:00] ralphschind...@php.net Seeing as though 5.2.x is not supported, it seems like we can close this as "won't fix", no? [2009-07-31 04:20:09] mac dot komarov at gmail dot com Description: Trying to upgrade from 1.2.3 to 2.0.0. [root@mosquito php.d]# pecl upgrade phar WARNING: "pear/bz2" is deprecated in favor of "channel://http://php.net/bzip2/ext/bz2"; Did not download optional dependencies: pecl/bz2, pecl/hash, use --alldeps to download automatically downloading phar-2.0.0.tgz ... Starting to download phar-2.0.0.tgz (450,821 bytes) done: 450,821 bytes 28 source files, building running: phpize Configuring for: PHP Api Version: 20041225 Zend Module Api No: 20060613 Zend Extension Api No: 220060519 building in /var/tmp/pear-build-root/phar-2.0.0 running: /var/tmp/phar/configure checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for a sed that does not truncate output... /bin/sed checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking how to run the C preprocessor... gcc -E checking for icc... no checking whether gcc and cc understand -c and -o together... yes checking for system library directory... lib checking if compiler supports -R... no checking if compiler supports -Wl,-rpath,... yes checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu checking for PHP prefix... /usr checking for PHP includes... -I/usr/include/php -I/usr/include/php/main -I/usr/include/php/TSRM -I/usr/include/php/Zend -I/usr/include/php/ext -I/usr/include/php/ext/date/lib checking for PHP extension directory... /usr/lib/php/modules checking for PHP installed headers prefix... /usr/include/php checking if debug is enabled... no checking if zts is enabled... no checking for re2c... no configure: WARNING: You will need re2c 0.13.4 or later if you want to regenerate PHP parsers. checking for gawk... gawk checking for phar archive support... yes, shared checking for phar openssl support... no checking for a sed that does not truncate output... (cached) /bin/sed checking for fgrep... /bin/grep -F checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B checking the name lister (/usr/bin/nm -B) interface... BSD nm checking whether ln -s works... yes checking the maximum length of command line arguments... 1966080 checking whether the shell understands some XSI constructs... yes checking whether the shell understands "+="... yes checking for /usr/bin/ld option to reload object files... -r checking for objdump... objdump checking how to recognize dependent libraries... pass_all checking for ar... ar checking for strip... strip checking for ranlib... ranlib checking command to parse /usr/bin/nm -B output from gcc object... ok checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for dlfcn.h... yes checking for objdir... .libs checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC -DPIC checking if gcc PIC flag -fPIC -DPIC works... yes checking if gcc static flag -static works... no checking if gcc supports -c -o file.o... yes checking if gcc supports -c -o file.o... (cached) yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping li
Bug #63589 [Opn->Nab]: XMLWriter handling of double-quotes not consistent with other libxml extensions
Edit report at https://bugs.php.net/bug.php?id=63589&edit=1
ID: 63589
Updated by: m...@php.net
Reported by:franck at cassedanne dot com
Summary:XMLWriter handling of double-quotes not consistent
with other libxml extensions
-Status: Open
+Status: Not a bug
Type: Bug
Package:XML Writer
Operating System: BSD, Linux, OSX
PHP Version:5.3.19, 5.4.9
Block user comment: N
Private report: N
New Comment:
It just forwards the call to libxml's xmlwriter, so nothing we can do about it.
Previous Comments:
[2012-11-23 19:35:32] franck at cassedanne dot com
The same issue is present on PHP 5.4.9
[2012-11-23 18:56:09] franck at cassedanne dot com
Description:
XMLWriter differs in its handling of double-quotes when compared to other libxml
based PHP extensions.
Double-quotes using XMLWriter are converted to htmlentities (i.e. '"').
Using SimpleXML or DOMDocument double-quotes stay unconverted.
It seems to me that XMLWriter should not be converting double-quotes either.
Tidy seems to also agree -- try the following in a CLI:
$ echo """ | tidy -xml -q
Maybe introducing a flag/constant such as ENT_NOQUOTES to toggle the conversion
of
these on and off might be pertinent.
Test script:
---
openMemory();
$x->startDocument('1.0', 'UTF-8');
$x->writeElement('tag', '"');
$x->endDocument();
echo $x->flush();
Expected result:
"
Actual result:
--
"
--
Edit this bug report at https://bugs.php.net/bug.php?id=63589&edit=1
Bug #63639 [Opn->Nab]: posix_isatty and posix_ttyname weird var handling
Edit report at https://bugs.php.net/bug.php?id=63639&edit=1
ID: 63639
Updated by: m...@php.net
Reported by:antronin at gmail dot com
Summary:posix_isatty and posix_ttyname weird var handling
-Status: Open
+Status: Not a bug
Type: Bug
Package:POSIX related
Operating System: Ubuntu 12.10
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Expecting integer parameters the arguments get converted, so:
true -> 1 -> STDOUT
false/'str'/array() -> 0 -> STDIN
Previous Comments:
[2012-11-28 21:55:52] antronin at gmail dot com
Description:
---
>From manual page: http://www.php.net/function.posix-isatty
---
Although documentation says "Returns TRUE if fd is an open descriptor connected
to a terminal and FALSE otherwise." clearly this is not the case.
It also returns TRUE if the parameter is not a file descriptor at all except is
it is an integer < 3.
Test script:
---
var_dump(posix_isatty(true));
var_dump(posix_isatty(false));
var_dump(posix_isatty('str'));
var_dump(posix_isatty(array()));
var_dump(posix_isatty(42));
for ($i=0; $i<50; $i++) {
var_dump(posix_isatty($i));
}
Expected result:
(bool)false
(bool)false
(bool)false
(bool)false
(bool)false
(bool)false x50
Actual result:
--
(bool)true
(bool)true
(bool)true
(bool)true
(bool)false
(bool)true
(bool)true
(bool)true
(bool)false x47
--
Edit this bug report at https://bugs.php.net/bug.php?id=63639&edit=1
Bug #64241 [Opn->Nab]: ISO 8601 not implemented correctly
Edit report at https://bugs.php.net/bug.php?id=64241&edit=1
ID: 64241
Updated by: m...@php.net
Reported by:florin dot asavoaie at gmail dot com
Summary:ISO 8601 not implemented correctly
-Status: Open
+Status: Not a bug
Type: Bug
Package:XMLRPC-EPI related
PHP Version:5.4.11
Block user comment: N
Private report: N
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
>From the XMLRPC spec (Update 1/21/99)
http://xmlrpc.scripting.com/spec#update3
> What timezone should be assumed for the
> dateTime.iso8601 type? UTC? localtime?
> Don't assume a timezone. It should be
> specified by the server in its
> documentation what assumptions it makes
> about timezones.
Previous Comments:
[2013-02-18 23:19:16] florin dot asavoaie at gmail dot com
Description:
ISO 8601 states the following: "If no UTC relation information is given with a
time representation, the time is assumed to be in local time.".
xmlrpc_decode and xmlrpc_decode_request functions do not conform with this
standard because, when they decode the time that is formatted in ISO 8601
format
and no timezone information is present, the time always gets converted to UTC,
when it should actually be considered local time.
Test script:
---
20120810T12:03:12';
$xml2 =
'20120810T12:03:12+02:00';
$xml3 =
'20120810T12:03:12Z';
echo date ('c', time ()) . PHP_EOL;
$date1 = xmlrpc_decode ($xml1);
$date2 = xmlrpc_decode ($xml2);
$date3 = xmlrpc_decode ($xml3);
var_dump ($date1, $date2, $date3);
Expected result:
2013-02-19T01:04:17+02:00
object(stdClass)#1 (3) {
["scalar"]=>
string(17) "20120810T12:03:12"
["xmlrpc_type"]=>
string(8) "datetime"
["timestamp"]=>
int(1344592992)
}
object(stdClass)#2 (3) {
["scalar"]=>
string(23) "20120810T12:03:12+02:00"
["xmlrpc_type"]=>
string(8) "datetime"
["timestamp"]=>
int(1344592992)
}
object(stdClass)#3 (3) {
["scalar"]=>
string(18) "20120810T12:03:12Z"
["xmlrpc_type"]=>
string(8) "datetime"
["timestamp"]=>
int(1344600192)
}
Actual result:
--
2013-02-19T01:04:17+02:00
object(stdClass)#1 (3) {
["scalar"]=>
string(17) "20120810T12:03:12"
["xmlrpc_type"]=>
string(8) "datetime"
["timestamp"]=>
int(1344600192)
}
object(stdClass)#2 (3) {
["scalar"]=>
string(23) "20120810T12:03:12+02:00"
["xmlrpc_type"]=>
string(8) "datetime"
["timestamp"]=>
int(1344592992)
}
object(stdClass)#3 (3) {
["scalar"]=>
string(18) "20120810T12:03:12Z"
["xmlrpc_type"]=>
string(8) "datetime"
["timestamp"]=>
int(1344600192)
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=64241&edit=1
Bug #58863 [Opn->Wfx]: Reconnect support broken
Edit report at https://bugs.php.net/bug.php?id=58863&edit=1
ID: 58863
Updated by: m...@php.net
Reported by:marion dot jeff at gmail dot com
Summary:Reconnect support broken
-Status: Open
+Status: Wont fix
Type: Bug
-Package:PDO_MYSQL
+Package:*General Issues
Operating System: *nix (Centos 4/5, Arch)
PHP Version:5.2.8
Block user comment: N
Private report: N
New Comment:
PECL PDO packages are obsolete.
Previous Comments:
[2011-07-01 05:24:55] sinomad123 at gmail dot com
I've got the same problem,too. PDO class does not have a reconnect
function.When reading the source, I found the broken code. So I have to make
some change as below:
mysql_driver.c:
-
594
(added) long reconnect = pdo_attr_bval(driver_options,
PDO_MYSQL_ATTR_RECONNECT, 0 TSRMLS_CC);
595
639 //#ifdef MYSQL_OPT_RECONNECT
640 /* since 5.0.3, the default for this option is 0 if not specified.
641 * we want the old behaviour */
642 if( reconnect ){
643 long reconnect = 1;
644 mysql_options(H->server, MYSQL_OPT_RECONNECT, (const char*)&reconnect);
645 }
646 //#endif
php_pdo_mysql_int.h
---
159 PDO_MYSQL_ATTR_INIT_COMMAND,
(added) MYSQL_OPT_RECONNECT,
pdo_mysql.c
---
72 REGISTER_PDO_CLASS_CONST_LONG("MYSQL_ATTR_INIT_COMMAND",
(long)PDO_MYSQL_ATTR_INIT_COMMAND);
(added) REGISTER_PDO_CLASS_CONST_LONG("MYSQL_OPT_RECONNECT",
(long)PDO_MYSQL_OPT_RECONNECT);
implemention of function pdo_attr_bval:(in pdo/php_pdo_driver.h)
--
static inline long pdo_attr_bval(zval *options, enum pdo_attribute_type
option_name, long defval TSRMLS_DC)
{
zval **v;
if (options && SUCCESS == zend_hash_index_find(Z_ARRVAL_P(options),
option_name, (void**)&v)) {
convert_to_boolean_ex(v);
return Z_BVAL_PP(v);
}
return defval;
}
after make&install, you can use pdo_options to set MYSQL_OPT_RECONNECT:
$conn = new PDO('mysql:host=xxx', 'xx',
'xx',array(PDO::MYSQL_OPT_RECONNECT=>true));
hope this will help.
[2011-06-05 04:02:50] marion dot jeff at gmail dot com
Reopening as there hasn't been any follow-up or comment.
[2011-05-30 17:31:10] marion dot jeff at gmail dot com
Johannes,
If the current PDO stance on the issue is that you don't want to allow for even
an optional enablement of the underlying MySQL OPT_RECONNECT behavior that's
your prerogative.
However, it seems the exact opposite decision was made in the past by the
PDO_MYSQL maintainers when they chose to add code which explicitly enabled
auto-reconnect behavior in the driver following the MySQL 5.0.3 change to the
OPT_RECONNECT default. The existence of that code is the basis for this bug.
That code is in fact broken. Lines 639-646 in the PHP 5.4 branch are not just
dead code which is impossible to ever reach but both the code and comment are
very misleading. Additionally there is another block up code (633-638) which
makes the same mistake of trying to ifdef based on one of the MYSQL_OPT_ enums,
which are not available to the preprocessor and so will always fail to match.
If the project has changed it's mind about the reconnect behavior and wants it
to be intentionally off that is fine by me but please fix the code so it
represents this decision and ideally add some documentation about the behavior
change that occurred.
Feel free to contact me off list to discuss.
[2011-05-26 08:27:24] johannes at schlueters dot de
Doing a magic reconnect without notice to the user is bad as the connection
looses its state (prepared statements become invalid, session variables are
lost, temporary tables go away, ...)
A manual reconnect also won't be implemented as MySQL specific feature. Please
report it at bugs.php.net as general PDO request if you think this is really
think this is useful.
[2011-01-13 20:47:57] datib...@php.net
Just came across this ticket when I realized that PDO doesn't
have a reconnect method and assumed it was done "magically";
so I was surprised that this still doesn't work in 5.3.4
It would be really nice if this behaviour could be governed
via a PDO:: parameter, specifically for MySQL or otherwise.
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
https://bugs.php.net/bug.php?id=58863
--
Edit this bug report at https://bugs.php.net/bug.php?id=58863&edit=1
Bug #62181 [Opn->NoF]: wddx_serialize_value() returns wrong string
Edit report at https://bugs.php.net/bug.php?id=62181&edit=1
ID: 62181
Updated by: m...@php.net
Reported by:clemens at gutweiler dot net
Summary:wddx_serialize_value() returns wrong string
-Status: Open
+Status: No Feedback
Type: Bug
Package:WDDX related
Operating System: Linux
PHP Version:5.4.3
Block user comment: N
Private report: N
New Comment:
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.
Previous Comments:
[2012-05-30 15:00:17] sjon at hortensius dot net
I cannot reproduce this bug using a vanilla 5.4.3 version, could you check if
disabling your extensions fixes this?
http://3v4l.org/nH7LO
[2012-05-29 11:05:34] clemens at gutweiler dot net
Description:
wddx_serialize_value() returns wrong string, associative key elements are wrong
interpreted in the output
the resulting string could not be interpreted by wddx_deserialize()
Test script:
---
var_dump(wddx_serialize_value(array("foo"=>1)));
PHP 5.3.8
string(118) "1"
PHP 5.4.3
string(117) "1"
var_dump(wddx_serialize_value(array("foo"=>1,"bar"=>"barstr")));
PHP 5.3.8
string(163) "1barstr"
PHP 5.4.3
string(140) "1barstr"
--
Edit this bug report at https://bugs.php.net/bug.php?id=62181&edit=1
Bug #51968 [Opn->Csd]: dns_get_record() [function.dns-get-record]: res_nsend() failed
Edit report at https://bugs.php.net/bug.php?id=51968&edit=1
ID: 51968
Updated by: m...@php.net
Reported by:php at hm2k dot org
Summary:dns_get_record() [function.dns-get-record]:
res_nsend() failed
-Status: Open
+Status: Closed
Type: Bug
Package:*Network Functions
PHP Version:5.3.2
-Assigned To:
+Assigned To:mike
Block user comment: N
Private report: N
New Comment:
Fixed since 5.3+
Previous Comments:
[2013-02-18 20:53:37] h...@php.net
What feedback were you expecting?
[2013-02-18 00:34:18] php-bugs at lists dot php dot net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
[2011-10-07 11:59:27] b1gag3 at hotmail dot de
using error suppression (@dns_get_record('example.com')) works, even it doesn't
solve the problem...
[2011-09-26 10:04:56] m dot alsemany at gmail dot com
even if I make an Exception
this error come !!
the only way to hide is just close the reporting from php.ini :(
[2010-10-12 13:57:38] boyan at peychev dot net
Hello,
I have this problem too:
Warning: dns_get_record() [function.dns-get-record]: res_nsend() failed in .
Example problematic domains:
dns_get_record('gtvip.com.cn', DNS_NS);
dns_get_record('fztuan.tk', DNS_NS);
dns_get_record('forumgeeks.vv.cc', DNS_NS);
dns_get_record('en91.tk', DNS_NS);
dns_get_record('serverdns.ce.ms', DNS_NS);
PHP Version: 5.2.6-1+lenny9 with Suhosin-Patch 0.9.6.2 (cli) (built: Aug 4
2010
03:25:57)
OS: Debian 5.0.6
Regards,
Boyan Peychev
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
https://bugs.php.net/bug.php?id=51968
--
Edit this bug report at https://bugs.php.net/bug.php?id=51968&edit=1
Bug #64016 [Opn->Wfx]: file_get_contents does not fill up $http_response_header via HEAD method
Edit report at https://bugs.php.net/bug.php?id=64016&edit=1
ID: 64016
Updated by: m...@php.net
Reported by:anil at saog dot net
Summary:file_get_contents does not fill up
$http_response_header via HEAD method
-Status: Open
+Status: Wont fix
Type: Bug
Package:*URL Functions
Operating System: Centos 6.2
PHP Version:5.4.11
Block user comment: N
Private report: N
New Comment:
This feature has been removed from PHP-5.5
Previous Comments:
[2013-02-20 16:56:01] mattsch at gmail dot com
$http_response_header is undefined after doing a file_get_contents on a url on
php 5.3.21 as well.
[2013-01-18 11:19:42] anil at saog dot net
Description:
PHP is compiled with option "--with-curlwrappers". Whenever a HEAD request
issued with "file_get_contents", "$http_response_header" is not filled-up but
upon calling "get_headers()", variable "$http_response_header" auto-magically
filled up.
Test script:
---
$url = 'http://www.google.com';
$ctx = stream_context_create();
stream_context_set_option($ctx, array('http' => array('method' =>
'HEAD','timeout' => 60)));
$res = file_get_contents($url, false, $ctx);
var_dump($http_response_header); // NULL
get_headers($url);
var_dump($http_response_header); // filled up correctly
Expected result:
"$http_response_header" filled-up correctly
Actual result:
--
"$http_response_header" is always NULL
--
Edit this bug report at https://bugs.php.net/bug.php?id=64016&edit=1
Bug #54740 [Nab]: Ternary operator will not work with return by reference
Edit report at https://bugs.php.net/bug.php?id=54740&edit=1
ID: 54740
Updated by: m...@php.net
Reported by:dukeofgaming at gmail dot com
Summary:Ternary operator will not work with return by
reference
Status: Not a bug
Type: Bug
Package:Scripting Engine problem
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
I meant the documentation "Note:" (warning) not the user-contributed note.
Previous Comments:
[2013-10-01 20:35:33] marrch dot caat at gmail dot com
I thoroughly read the article you mentioned, Mike, but still don't understand
why the following code fails to compile:
$link = isset($i) ? (& $arr[$i]) : null;
- while the following works fine:
$link = &$arr[$i];
In this case, &$arr[$i] is a legal reference assignment, so the first code
should behave equal to
if (isset($i)) {
$link = &$arr[$i];
} else {
$link = null;
}
- but this code works fine, and mentioned above isn't even compiled. What's
wrong with it?
[2013-10-01 14:42:02] m...@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Check the second note here:
http://php.net/manual/en/language.references.return.php
[2012-08-27 14:17:44] marrch dot caat at gmail dot com
This is a general problem with reference inside ternary operator. For ex., the
following script fails with the same error:
$link = isset($i) ? (& $arr[$i]) : null;
- while the following works fine:
$link = & $arr[$i];
[2011-05-15 22:59:17] dukeofgaming at gmail dot com
Description:
PHP fails to parse a returned by reference value when using the ternary
operator.
The test script provided illustrates a case of when it is absolutely necessary
to return by reference; if the "&" is removed then the output would be a fatal
error: "Fatal error: Cannot use [] for reading in <...>"
Test script:
---
$value = ($condition)?(
$some_value
):(&$object->Collection[]);
Expected result:
No errors, should be the equivalent of having:
if($condition){
$value = $some_value;
}else{
$value = &$object->Collection[];
}
Actual result:
--
Parse error: syntax error, unexpected '&' in <...>
--
Edit this bug report at https://bugs.php.net/bug.php?id=54740&edit=1
Bug #65571 [Sus->Nab]: Compiling fails with - missing binary operator before token "extern"
Edit report at https://bugs.php.net/bug.php?id=65571&edit=1 ID: 65571 Updated by: m...@php.net Reported by:tony dot ar dot wright at bt dot com Summary:Compiling fails with - missing binary operator before token "extern" -Status: Suspended +Status: Not a bug Type: Bug Package:Compile Failure Operating System: SuSE 9 PHP Version:5.5.3 Block user comment: N Private report: N New Comment: Sorry for my ignorance, but (for me) 1.875 does not lie between 2.4 and 2.7 Previous Comments: [2013-10-01 15:47:58] pascal at nobus dot be I updated to bison-1.875 (compiled from source), but this didn't matter indeed. The problem appeared in php-5.4.19 and was not there in php-5.4.18. I could build it just fine from complete source tarball. [2013-10-01 15:35:25] m...@php.net If you build release tarballs, the bison version should not matter, though. [2013-10-01 15:29:19] pascal at nobus dot be apologies for my previous post, I was on the wrong server # flex -V flex version 2.5.4 # bison -V bison (GNU Bison) 1.35 I'll try to get a later bison-version [2013-10-01 15:21:54] m...@php.net Looks like you have to use bison2.4 - 2.7 to build from a source checkout. [2013-10-01 15:05:47] pascal at nobus dot be For the slackware-OS: (also php-5.4.20 has this problem) # flex -V flex 2.5.33 # bison -V bison (GNU Bison) 2.3 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 https://bugs.php.net/bug.php?id=65571 -- Edit this bug report at https://bugs.php.net/bug.php?id=65571&edit=1
Bug #53460 [Opn->Fbk]: glob() returns false for a pattern that matches zero files
Edit report at https://bugs.php.net/bug.php?id=53460&edit=1
ID: 53460
Updated by: m...@php.net
Reported by:cameel2+php at gmail dot com
Summary:glob() returns false for a pattern that matches zero
files
-Status: Open
+Status: Feedback
Type: Bug
-Package:*Directory Services problems
+Package:Filesystem function related
Operating System: Arch Linux
PHP Version:5.3.3
Block user comment: N
Private report: N
New Comment:
Check your open_basedir. Arch has it enabled by default.
Please enable error_reporting and display_errors before reporting a bug in the
future.
Previous Comments:
[2011-01-09 18:12:57] cameel2+php at gmail dot com
Right. But in that case the script would be printing both 'false' and 'array'.
It prints only 'false'.
I have just added var_dump() at the end of the test case and now the output is:
false
bool(false)
BTW: I am using PHP 5.3.5 now.
[2011-01-09 17:56:43] 13550 at free dot fr
"array() == false" is true because array is empty
try var_dump($glob) to be sure that glob does not return an array
[2010-12-03 17:41:27] cameel2+php at gmail dot com
Yeah, I meant that since I tested it under Apache first and that directory is
located in /srv/http, i.e. in the root directory of the server.
But you're right - for php being run from command line I should have used
relative path. Still, when I remove the leading slash and run
cd /srv/http; php test.php
the result is still false.
This is a contrived example anyway. Originally I have noticed it in a more
complex path.
If I do
touch /srv/http/phpMyAdmin/a.file
the script starts printing 'array'.
[2010-12-03 12:53:57] paj...@php.net
Are you sure you mean $glob = glob('/phpMyAdmin/*'); and not $glob =
glob('phpMyAdmin/*');? The sooner is an absolute path '/phpMyAdmin/', where the
2nd path is relative (to CWD).
[2010-12-03 05:56:59] cameel2+php at gmail dot com
Description:
On my system the glob() returns false if there are no files matching the
pattern even though the documentation
(http://php.net/manual/en/function.glob.php) states that it should return an
empty array.
PHP version: 5.3.3
The only things I have changed in php.ini are open_basedir
(/srv/http/:/home/:/usr/share/webapps:/etc/webapps:/tmp/:/usr/share/pear/:/usr/share/symfony)
and enabling of several extensions (mcrypt, mysql, pdo, pdo_sqlite).
I've seen similar bugs reported and closed a few years ago: #29928
Test script:
---
Expected result:
glob() should return an empty array if no files match the pattern.
Actual result:
--
The script prints 'false' when run on my box (both under Apache 2.2.17 and with
php from command line).
--
Edit this bug report at https://bugs.php.net/bug.php?id=53460&edit=1
Bug #65571 [Sus]: Compiling fails with - missing binary operator before token "extern"
Edit report at https://bugs.php.net/bug.php?id=65571&edit=1 ID: 65571 Updated by: m...@php.net Reported by:tony dot ar dot wright at bt dot com Summary:Compiling fails with - missing binary operator before token "extern" Status: Suspended Type: Bug Package:Compile Failure Operating System: SuSE 9 PHP Version:5.5.3 Block user comment: N Private report: N New Comment: If you build release tarballs, the bison version should not matter, though. Previous Comments: [2013-10-01 15:29:19] pascal at nobus dot be apologies for my previous post, I was on the wrong server # flex -V flex version 2.5.4 # bison -V bison (GNU Bison) 1.35 I'll try to get a later bison-version [2013-10-01 15:21:54] m...@php.net Looks like you have to use bison2.4 - 2.7 to build from a source checkout. [2013-10-01 15:05:47] pascal at nobus dot be For the slackware-OS: (also php-5.4.20 has this problem) # flex -V flex 2.5.33 # bison -V bison (GNU Bison) 2.3 [2013-10-01 14:36:01] m...@php.net What are your flex/bison versions? [2013-09-09 12:33:28] pascal at nobus dot be I had the same problem on php-5.4.19 This on a slackware-10.1 Tried the snapshot (php5.4-201309091030), and it seems to be fixed there? However I have no idea with what change the bug is fixed. 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 https://bugs.php.net/bug.php?id=65571 -- Edit this bug report at https://bugs.php.net/bug.php?id=65571&edit=1
Bug #63257 [Opn->Nab]: checkdate(): Wrong if year is two digits and year is 2000
Edit report at https://bugs.php.net/bug.php?id=63257&edit=1
ID: 63257
Updated by: m...@php.net
Reported by:php at skay dot se
Summary:checkdate(): Wrong if year is two digits and year is
2000
-Status: Open
+Status: Not a bug
Type: Bug
Package:*Calendar problems
Operating System: Unix
PHP Version:5.3.10
Block user comment: N
Private report: N
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Previous Comments:
[2012-10-11 11:25:58] ewgraf at gmail dot com
Seems not a bug.
>From manual:
> 'year' The year is between 1 and 32767 inclusive.
int from "00" will be 0
[2012-10-10 22:22:19] php at skay dot se
Description:
---
>From manual page: http://www.php.net/function.checkdate
---
If year is 2000 the function will return TRUE (provided the rest is valid) -
Thats good!
But if year is 00 the function will always return FALSE
Test script:
---
echo checkdate("01", "01", "2000");
echo checkdate("01", "01", "00");
Expected result:
TRUE
TRUE
Actual result:
--
TRUE
FALSE
[2012-10-10 22:17:13] php at skay dot se
Description:
---
>From manual page: http://www.php.net/function.checkdate
---
PHP version 5.3.10
If year is 2000 the function will return TRUE (provided the rest is valid) -
Thats good!
But if year is 00 the function will always return FALSE
Test script:
---
echo checkdate("01", "01", "2000");
echo checkdate("01", "01", "00");
Expected result:
TRUE
TRUE
Actual result:
--
TRUE
FALSE
--
Edit this bug report at https://bugs.php.net/bug.php?id=63257&edit=1
Bug #62284 [Opn->Fbk]: getimagesize does not work with all supported images
Edit report at https://bugs.php.net/bug.php?id=62284&edit=1
ID: 62284
Updated by: m...@php.net
Reported by:dnied at tiscali dot it
Summary:getimagesize does not work with all supported images
-Status: Open
+Status: Feedback
Type: Bug
Package:GetImageSize related
Operating System: Linux, i386
PHP Version:5.3.13
Block user comment: N
Private report: N
New Comment:
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 ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
I get "Error generating thumbnail".
Previous Comments:
[2012-06-10 15:47:47] dnied at tiscali dot it
Yes, I can get the non-working image with my browser and with wget.
Your comment made me think of a config issue, so I tried an original, untouched
php.ini file with all extensions enabled (not that my own php.ini was really
tweaked). Still, no go. I do get a couple of warnings for 2 missing libs, but
they look unrelated to me (one is a spell-checking lib, the other is SQLite3 --
neither is documented as a dependency to getimagesize):
PHP Warning: PHP Startup: Unable to load dynamic library
'/usr/lib/php/extensions/enchant.so' - /usr/lib/php/extensions/enchant.so:
cannot open shared object file: No such file or directory in Unknown on line 0
Warning: PHP Startup: Unable to load dynamic library
'/usr/lib/php/extensions/enchant.so' - /usr/lib/php/extensions/enchant.so:
cannot open shared object file: No such file or directory in Unknown on line 0
PHP Warning: PHP Startup: Unable to load dynamic library
'/usr/lib/php/extensions/sqlite3.so' - /usr/lib/php/extensions/sqlite3.so:
cannot open shared object file: No such file or directory in Unknown on line 0
Warning: PHP Startup: Unable to load dynamic library
'/usr/lib/php/extensions/sqlite3.so' - /usr/lib/php/extensions/sqlite3.so:
cannot open shared object file: No such file or directory in Unknown on line 0
[2012-06-10 15:17:09] larue...@php.net
I can not reproduce this, is the network to wikimedia okey?
[2012-06-10 14:01:16] dnied at tiscali dot it
Description:
The getimagesize function does not work with some (allegedly supported) images.
I could not observe this on images stored locally, so it only seems to affect
images retrieved via the http wrapper.
FWIW, URL length doesn't seem to affect this: I tried a shortened URL for the
image that didn't work, and it still didn't work.
Test script:
---
~> php -r '$imgInfo =
getimagesize("http://upload.wikimedia.org/wikipedia/commons/thumb/d/d9/Disney_Concert_Hall_by_Carol_Highsmith_edit2.jpg/767px-Disney_Concert_Hall_by_Carol_Highsmith_edit2.jpg";);
print_r($imgInfo);'
~>
~>
~> php -r '$imgInfo =
getimagesize("https://bugs.php.net/images/logo.gif";);print_r($imgInfo);'
Array
(
[0] => 130
[1] => 67
[2] => 1
[3] => width="130" height="67"
[bits] => 8
[channels] => 3
[mime] => image/gif
)
~>
Expected result:
An array of image properties, for both images
Actual result:
--
A boolean false on the 1st image, the expected array of image properties on the
2nd one.
--
Edit this bug report at https://bugs.php.net/bug.php?id=62284&edit=1
Bug #65571 [Fbk->Sus]: Compiling fails with - missing binary operator before token "extern"
Edit report at https://bugs.php.net/bug.php?id=65571&edit=1 ID: 65571 Updated by: m...@php.net Reported by:tony dot ar dot wright at bt dot com Summary:Compiling fails with - missing binary operator before token "extern" -Status: Feedback +Status: Suspended Type: Bug Package:Compile Failure Operating System: SuSE 9 PHP Version:5.5.3 Block user comment: N Private report: N New Comment: Looks like you have to use bison2.4 - 2.7 to build from a source checkout. Previous Comments: [2013-10-01 15:05:47] pascal at nobus dot be For the slackware-OS: (also php-5.4.20 has this problem) # flex -V flex 2.5.33 # bison -V bison (GNU Bison) 2.3 [2013-10-01 14:36:01] m...@php.net What are your flex/bison versions? [2013-09-09 12:33:28] pascal at nobus dot be I had the same problem on php-5.4.19 This on a slackware-10.1 Tried the snapshot (php5.4-201309091030), and it seems to be fixed there? However I have no idea with what change the bug is fixed. [2013-08-28 09:37:25] tony dot ar dot wright at bt dot com Description: I installed 5.5.2 ok but when I tried to install 5.5.3 I get the error message: In file included from Zend/zend_language_scanner.l:40: Zend/zend_language_parser.h:40:1: missing binary operator before token "extern" make: *** [Zend/zend_language_scanner.lo] Error 1 Configure options used: './configure' '--with-apxs2=/usr/local/apache2/bin/apxs' '--enable-ftp' '--witho ut-ldap' '--enable-sockets' '--with-gd' '--with-freetype-dir' '--without-mcrypt' '--with-zlib-dir' '--with-png-dir' '--with-oci8=/export/oracle/product/10.2.0/d b_1' '--with-openssl' -- Edit this bug report at https://bugs.php.net/bug.php?id=65571&edit=1
Bug #62003 [Opn->Csd]: LDAP compile failure
Edit report at https://bugs.php.net/bug.php?id=62003&edit=1 ID: 62003 Updated by: m...@php.net Reported by:aconnor at ait dot ie Summary:LDAP compile failure -Status: Open +Status: Closed Type: Bug Package:Compile Failure Operating System: Ubuntu server 12.04 PHP Version:5.4.3 -Assigned To: +Assigned To:mike Block user comment: N Private report: N New Comment: Ok, we'll suppose it's fixed then. Previous Comments: [2013-10-01 14:33:26] aconnor at ait dot ie Hi Mike, At the time I wasn't trying to build with oci8 at the time. I eventually got around this error after alot of trial and error I found then solution in a different version of ldap. I was trying to compile with openldap- stable-20120311 (2.4.30), I downloaded and compiled openldap-2.4.31 and this allowed me to compile php 5.4.3. I now have multiple successful ldap connections running on the front end of our server. Sorry I didn't post these comments earlier, I didn't realise others were having a similar issue. This was my solution but it only be a work-around as there could be a bug. Regards, Anthony [2013-10-01 14:15:57] m...@php.net See bug #61450 -- a fix is in the works. I'm inclined to mark this as duplicate. @aconnor: Were you trying to build ldap and oci8 at the same time, too? [2012-12-05 14:15:39] fernando dot wendt at gmail dot com When compiling PHP 5.4.9, trying to enable both oci8 (instantclient, 11.2) and ldap modules, it points the same issue, and fails. The little bit diff is that once you point --with-ldap, it seems to compile it, but - by a misunderstood behavior, it uses the ldap.h from instantclient sdk file! Of course, make fails. Reading at OTN forum, theres is a thread where some people does not recommend compiling them togheter: the suggest is to compile PHP with ldap, and install oci8 with PECL, after [https://forums.oracle.com/forums/thread.jspa? messageID=10319335]. Works to me: i was needing ldap at first. oci8, will be added after. Best regards [2012-06-28 13:41:19] macolinovo at gmail dot com I'm also with same problem [2012-05-11 10:42:37] aconnor at ait dot ie Description: I am trying configure php 5.4.3 from source on a ubuntu 12.04 server build using this switch --with-ldap=/usr i get this error: configure: error: Cannot find ldap libraries in /usr/lib. So i change to --with-ldap=/usr/lib Then i get this error: configure: error: Cannot find ldap.h So i find ldap.h in /usr/include I created a sym link for the /include directory in the /usr/lib directory, so the config might see ldap.h. I have tried ln -s /usr/include/ /usr/lib and ln -s /usr/include/ldap.h /usr/lib/ but i still get the same error. also: Permissions on the directory /usr/lib: drwxr-xr-x 53 root root 4096 May 11 09:06 lib I chmod 777 the ldap.h file. Then ran ln -s /usr/include/ldap.h /usr/lib/ i also tried ln -s /usr/include/ldap.h . Both create the link it appears as : lrwxrwxrwx 1 root root 19 May 11 09:00 ldap.h -> /usr/include/ldap.h But still the same error -- Edit this bug report at https://bugs.php.net/bug.php?id=62003&edit=1
Bug #62396 [Opn->Csd]: 'make test' crashes starting with 5.3.14 (missing gzencode())
Edit report at https://bugs.php.net/bug.php?id=62396&edit=1 ID: 62396 Updated by: m...@php.net Reported by:long at ku dot edu Summary:'make test' crashes starting with 5.3.14 (missing gzencode()) -Status: Open +Status: Closed Type: Bug Package:Compile Failure Operating System: Red Hat Enterprise Linux AS rele PHP Version:5.3.14 Block user comment: N Private report: N New Comment: Automatic comment on behalf of mike Revision: http://git.php.net/?p=php-src.git;a=commit;h=cd1cab3f4726751a0476ac8701ce09cc37cb36df Log: fix bug #62396 'make test' crashes starting with 5.3.14 (missing gzencode()) Previous Comments: [2013-03-19 16:39:55] long at ku dot edu I'm stilling seeing this error in 5.3.23 contrary to previous post. [2013-01-07 09:58:51] meths at btinternet dot com I found this bug report after encountering it on 5.4.x and I duplicated the issue seen with 5.3.14 at the time. I can confirm with my latest attempts that this seems fixed in 5.3.x but is still occurring with 5.4.x as of 5.4.10. [2012-06-22 15:24:53] long at ku dot edu Description: When I run 'make test' it now crashes: PASS SOAP Server 17: user fault (through return) [ext/soap/tests/server017.phpt] PASS SOAP Server 18: user fault (through throw) [ext/soap/tests/server018.phpt] PHP Fatal error: Call to undefined function gzencode() in /apps/home/long/src/php5.3-201206221330/run-tests.php on line 1712 Fatal error: Call to undefined function gzencode() in /apps/home/long/src/php5.3-201206221330/run-tests.php on line 1712 [long@wbtstap php5.3-201206221330]$ This did not happen in 5.3.13 and earlier. Here is the config.nice that was used: #! /bin/sh # # Created by configure CFLAGS='-O3' \ CXXFLAGS='-O3' \ LIBS='-lssl -lncurses' \ './configure' \ '--enable-discard-path' \ '--with-openssl=shared' \ '--with-zlib=shared' \ '--enable-bcmath' \ '--with-bz2=shared' \ '--enable-calendar' \ '--with-curl=shared' \ '--enable-dba=shared' \ '--with-gdbm=shared' \ '--with-db4=shared' \ '--enable-dbase' \ '--enable-exif' \ '--enable-ftp' \ '--with-gd=shared' \ '--enable-gd-native-ttf' \ '--enable-gd-jis-conv' \ '--with-gettext=shared' \ '--with-gmp=shared' \ '--with-imap=shared' \ '--with-kerberos' \ '--with-imap-ssl' \ '--with-ldap' \ '--enable-mbstring' \ '--with-mysql=/usr' \ '--with-ncurses=shared' \ '--with-oci8' \ '--with-pspell=shared' \ '--with-readline=shared' \ '--enable-shmop' \ '--with-snmp=shared' \ '--enable-sockets' \ '--with-sqlite=shared' \ '--with-pdo-sqlite=shared' \ '--enable-sysvmsg' \ '--enable-sysvsem' \ '--enable-sysvshm' \ '--enable-wddx' \ '--with-freetype-dir' \ '--with-jpeg-dir' \ '--with-xpm-dir' \ '--enable-cgi' \ '--with-mysqli' \ '--enable-pdo=shared' \ '--with-pdo-mysql=shared' \ '--with-pdo-oci=shared' \ '--with-tidy' \ '--enable-soap=shared' \ '--enable-zip' \ "$@" Expected result: 'make test' should not bomb out, errors should be trapped, etc. Actual result: -- ... PASS SOAP Server 17: user fault (through return) [ext/soap/tests/server017.phpt] PASS SOAP Server 18: user fault (through throw) [ext/soap/tests/server018.phpt] PHP Fatal error: Call to undefined function gzencode() in /apps/home/long/src/php5.3-201206221330/run-tests.php on line 1712 Fatal error: Call to undefined function gzencode() in /apps/home/long/src/php5.3-201206221330/run-tests.php on line 1712 [long@wbtstap php5.3-201206221330]$ -- Edit this bug report at https://bugs.php.net/bug.php?id=62396&edit=1
Bug #54740 [Opn->Nab]: Ternary operator will not work with return by reference
Edit report at https://bugs.php.net/bug.php?id=54740&edit=1
ID: 54740
Updated by: m...@php.net
Reported by:dukeofgaming at gmail dot com
Summary:Ternary operator will not work with return by
reference
-Status: Open
+Status: Not a bug
Type: Bug
-Package:Compile Failure
+Package:Scripting Engine problem
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Check the second note here:
http://php.net/manual/en/language.references.return.php
Previous Comments:
[2012-08-27 14:17:44] marrch dot caat at gmail dot com
This is a general problem with reference inside ternary operator. For ex., the
following script fails with the same error:
$link = isset($i) ? (& $arr[$i]) : null;
- while the following works fine:
$link = & $arr[$i];
[2011-05-15 22:59:17] dukeofgaming at gmail dot com
Description:
PHP fails to parse a returned by reference value when using the ternary
operator.
The test script provided illustrates a case of when it is absolutely necessary
to return by reference; if the "&" is removed then the output would be a fatal
error: "Fatal error: Cannot use [] for reading in <...>"
Test script:
---
$value = ($condition)?(
$some_value
):(&$object->Collection[]);
Expected result:
No errors, should be the equivalent of having:
if($condition){
$value = $some_value;
}else{
$value = &$object->Collection[];
}
Actual result:
--
Parse error: syntax error, unexpected '&' in <...>
--
Edit this bug report at https://bugs.php.net/bug.php?id=54740&edit=1
Bug #65571 [Opn->Fbk]: Compiling fails with - missing binary operator before token "extern"
Edit report at https://bugs.php.net/bug.php?id=65571&edit=1 ID: 65571 Updated by: m...@php.net Reported by:tony dot ar dot wright at bt dot com Summary:Compiling fails with - missing binary operator before token "extern" -Status: Open +Status: Feedback Type: Bug Package:Compile Failure Operating System: SuSE 9 PHP Version:5.5.3 Block user comment: N Private report: N New Comment: What are your flex/bison versions? Previous Comments: [2013-09-09 12:33:28] pascal at nobus dot be I had the same problem on php-5.4.19 This on a slackware-10.1 Tried the snapshot (php5.4-201309091030), and it seems to be fixed there? However I have no idea with what change the bug is fixed. [2013-08-28 09:37:25] tony dot ar dot wright at bt dot com Description: I installed 5.5.2 ok but when I tried to install 5.5.3 I get the error message: In file included from Zend/zend_language_scanner.l:40: Zend/zend_language_parser.h:40:1: missing binary operator before token "extern" make: *** [Zend/zend_language_scanner.lo] Error 1 Configure options used: './configure' '--with-apxs2=/usr/local/apache2/bin/apxs' '--enable-ftp' '--witho ut-ldap' '--enable-sockets' '--with-gd' '--with-freetype-dir' '--without-mcrypt' '--with-zlib-dir' '--with-png-dir' '--with-oci8=/export/oracle/product/10.2.0/d b_1' '--with-openssl' -- Edit this bug report at https://bugs.php.net/bug.php?id=65571&edit=1
Bug #65595 [Opn->Fbk]: ext/standard/.libs/basic_functions.o:(.data+0xbf08): undefined reference to `zi
Edit report at https://bugs.php.net/bug.php?id=65595&edit=1 ID: 65595 Updated by: m...@php.net Reported by:g dot fischer at ah-online dot com Summary:ext/standard/.libs/basic_functions.o:(.data+0xbf08): undefined reference to `zi -Status: Open +Status: Feedback Type: Bug Package:Compile Failure Operating System: linux, debian 6 PHP Version:5.4.19, 5.5.3 Block user comment: N Private report: N New Comment: Sorry, but how should we consistently fix bugs with a trialware compiler? I'd be happy though, to apply a portable patch! Thank you. Previous Comments: [2013-08-30 15:36:33] g dot fischer at ah-online dot com both affected versions added [2013-08-30 15:34:33] g dot fischer at ah-online dot com Description: system: === debian 6, pgi 2012 options used: = ./configure --enable-fastcgi --disable-ipv6 --with-openssl --with-mysql=/usr/local/mysql --with-mysql-sock --enable-sockets --with-curl --prefix=/usr/local/php553 --enable-shmop this occurs with 5.4.19 as well as with 5.5.3 upon final linking. 5.3.27 is not affected. nothing new it seems. the following report i found shows the same error with the intel compiler http://forum.nginx.org/read.php?25,58334 Expected result: link without error Actual result: -- ext/standard/.libs/basic_functions.o:(.data+0xbf08): undefined reference to `zif_sscanf' make: *** [sapi/cli/php] Error 2 make: *** Waiting for unfinished jobs make: *** [sapi/cgi/php-cgi] Error 2 -- Edit this bug report at https://bugs.php.net/bug.php?id=65595&edit=1
Req #64492 [Opn->Csd]: ./configure fails under bison 2.7 environment
Edit report at https://bugs.php.net/bug.php?id=64492&edit=1 ID: 64492 Updated by: m...@php.net Reported by:user at zuse dot jp Summary:./configure fails under bison 2.7 environment -Status: Open +Status: Closed Type: Feature/Change Request Package:Compile Failure Operating System: OSX 10.7 PHP Version:master-Git-2013-03-22 (Git) -Assigned To: +Assigned To:mike Block user comment: N Private report: N Previous Comments: [2013-03-27 18:55:48] s...@php.net The PHP test suite runs fine with (hand built) bison 2.7 on Oracle Linux 5.9. The fix for https://bugs.php.net/bug.php?id=64503 means that 2.3 and earlier are no longer usable. I verified this, as did laruence (on IRC he retracted his email that claimed it was usable). Rasmus is OK with dropping support for 2.3 (see http://news.php.net/php.internals/66810). These older versions should be removed from Zend/acinclude.m4 Note in https://bugs.php.net/bug.php?id=64503 Remi says 2.4.1 is OK. I haven't seen any results for 2.4. [2013-03-23 13:38:52] paj...@php.net Then we need to fix the code for 2.6+. Right now it fails for ZTS with 2.6.1 already. [2013-03-23 13:15:21] m...@php.net We might add it to master, I'm using 2.7 all-time here, too. [2013-03-22 16:29:08] paj...@php.net I would suggest to use older versions for now, latest versions are not yet tested and can create issues. [2013-03-22 16:21:28] user at zuse dot jp Description: Please add build support for bison 2.7 environment. Test script: --- $ bison --version bison (GNU Bison) 2.7 $ autoreconf -i && ./configure configure: WARNING: bison versions supported for regeneration of the Zend/PHP parsers: 1.28 1.35 1.75 1.875 2.0 2.1 2.2 2.3 2.4 2.4.1 2.4.2 2.4.3 2.5 2.5.1 2.6 2.6.1 2.6.2 (found: 2.7). configure: error: bison is required to build PHP/Zend when building a GIT checkout! -- Edit this bug report at https://bugs.php.net/bug.php?id=64492&edit=1
Bug #62003 [Opn->Fbk]: LDAP compile failure
Edit report at https://bugs.php.net/bug.php?id=62003&edit=1 ID: 62003 Updated by: m...@php.net Reported by:aconnor at ait dot ie Summary:LDAP compile failure -Status: Open +Status: Feedback Type: Bug Package:Compile Failure Operating System: Ubuntu server 12.04 PHP Version:5.4.3 Block user comment: N Private report: N New Comment: See bug #61450 -- a fix is in the works. I'm inclined to mark this as duplicate. @aconnor: Were you trying to build ldap and oci8 at the same time, too? Previous Comments: [2012-12-05 14:15:39] fernando dot wendt at gmail dot com When compiling PHP 5.4.9, trying to enable both oci8 (instantclient, 11.2) and ldap modules, it points the same issue, and fails. The little bit diff is that once you point --with-ldap, it seems to compile it, but - by a misunderstood behavior, it uses the ldap.h from instantclient sdk file! Of course, make fails. Reading at OTN forum, theres is a thread where some people does not recommend compiling them togheter: the suggest is to compile PHP with ldap, and install oci8 with PECL, after [https://forums.oracle.com/forums/thread.jspa? messageID=10319335]. Works to me: i was needing ldap at first. oci8, will be added after. Best regards [2012-06-28 13:41:19] macolinovo at gmail dot com I'm also with same problem [2012-05-11 10:42:37] aconnor at ait dot ie Description: I am trying configure php 5.4.3 from source on a ubuntu 12.04 server build using this switch --with-ldap=/usr i get this error: configure: error: Cannot find ldap libraries in /usr/lib. So i change to --with-ldap=/usr/lib Then i get this error: configure: error: Cannot find ldap.h So i find ldap.h in /usr/include I created a sym link for the /include directory in the /usr/lib directory, so the config might see ldap.h. I have tried ln -s /usr/include/ /usr/lib and ln -s /usr/include/ldap.h /usr/lib/ but i still get the same error. also: Permissions on the directory /usr/lib: drwxr-xr-x 53 root root 4096 May 11 09:06 lib I chmod 777 the ldap.h file. Then ran ln -s /usr/include/ldap.h /usr/lib/ i also tried ln -s /usr/include/ldap.h . Both create the link it appears as : lrwxrwxrwx 1 root root 19 May 11 09:00 ldap.h -> /usr/include/ldap.h But still the same error -- Edit this bug report at https://bugs.php.net/bug.php?id=62003&edit=1
Bug #51076 [Asn]: race condition in shtool's mkdir -p implementation
Edit report at https://bugs.php.net/bug.php?id=51076&edit=1 ID: 51076 Updated by: m...@php.net Reported by:geissert at debian dot org Summary:race condition in shtool's mkdir -p implementation Status: Assigned Type: Bug Package:Compile Failure Operating System: * PHP Version:5.3SVN-2010-02-18 (SVN) Assigned To:geissert Block user comment: N Private report: N New Comment: Looks like I have to apologize for being an asshole myself, some may even think I'm the only asshole here. Previous Comments: [2013-10-01 13:55:06] m...@php.net And you make me angry by wasting my time. It was just a template when marking a bug as duplicate. Stop calling people and do something yourself. You do not have to apologize for being an asshole, just don't be an asshole. [2013-10-01 12:58:34] fviard at lacie dot com Hi, Today m...@php.net made me angry by posting a crappy comment on my 2,5years old bug report #54205 without even fixing the issue. This issue was so old that I completely forgot it. But now, I'm stupefied to notice that after 2 years, that issue that is resolvable with only a 5lines patch (easy to apply) is still not resolved. What are you doing? Mike, sorry to be offensive, but do you prefer harassing people on old bugs or fixing them? So, please close this bug soon! Thank you! [2013-10-01 12:30:15] m...@php.net Related To: Bug #54205 [2010-02-18 08:34:49] j...@php.net -Status: Closed +Status: Assigned Not fixed. [2010-02-18 00:31:15] geiss...@php.net -Status: Open +Status: Closed 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. 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 https://bugs.php.net/bug.php?id=51076 -- Edit this bug report at https://bugs.php.net/bug.php?id=51076&edit=1
Bug #61951 [Opn->Fbk]: "make install" script fails when prefix dir is a symbolic link
Edit report at https://bugs.php.net/bug.php?id=61951&edit=1 ID: 61951 Updated by: m...@php.net Reported by:stolen dot data dot net at gmail dot com Summary:"make install" script fails when prefix dir is a symbolic link -Status: Open +Status: Feedback Type: Bug Package:Compile Failure Operating System: Any PHP Version:5.4.2 Block user comment: N Private report: N New Comment: Please try using this snapshot: http://snaps.php.net/php5.4-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Works fine here. $ make install Installing PHP CLI binary:/tmp/php-5.4/sym/bin/ Installing PHP CLI man page: /tmp/php-5.4/sym/php/man/man1/ Installing PHP CGI binary:/tmp/php-5.4/sym/bin/ Installing PHP CGI man page: /tmp/php-5.4/sym/php/man/man1/ Installing build environment: /tmp/php-5.4/sym/lib/php/build/ Installing header files: /tmp/php-5.4/sym/include/php/ Installing helper programs: /tmp/php-5.4/sym/bin/ program: phpize program: php-config Installing man pages: /tmp/php-5.4/sym/php/man/man1/ page: phpize.1 page: php-config.1 $ cat config.nice #! /bin/sh # # Created by configure '/home/mike/src/php-5.4/configure' \ '--cache-file=config.cache' \ '--disable-all' \ '--prefix=/tmp/php-5.4/sym' \ "$@" $ ls -ld sym lrwxrwxrwx 1 mike users 4 1. Okt 15:07 sym -> real $ ls -ld real drwxr-xr-x 6 mike users 120 1. Okt 15:55 real Previous Comments: [2012-05-07 19:25:36] stolen dot data dot net at gmail dot com Specifically, the PHP Makefile fails when the destination of the symbolic link doesn't end with a trailing slash. This will cause the new Makefile to fail...: drwxr-xr-x 9 root wheel 512 May 7 21:21 php542 lrwxr-xr-x 1 root wheel7 May 7 21:10 php -> php542 ...but the Makefile bug doesn't manifest itself in this case: drwxr-xr-x 9 root wheel 512 May 7 21:21 php542 lrwxr-xr-x 1 root wheel7 May 7 21:10 php -> php542/ (Note the trailing slash at the end of the symbolic link destination...) [2012-05-05 11:00:50] stolen dot data dot net at gmail dot com Description: I've been using a symbolic link scheme for the prefix destination dir of PHP/Apache/etc. software that I compile myself for over ten years now, to easily and quickly switch between releases in case of problems showing up when I move to a new version: # ls -l /usr/opt drwxr-xr-x 6 root wheel 512 Mar 20 2011 php536 drwxr-xr-x 6 root wheel 512 Dec 11 12:44 php538 drwxr-xr-x 16 root wheel 512 May 5 11:02 php542 lrwxr-xr-x 1 root wheel6 May 5 11:02 php -> php542 ... ./configure --prefix=/usr/opt/php --other-flags If something goes wrong, I just shut down the servers, change the symbolical link, restart... You get the idea... It is not a problem with any earlier version of PHP, but as of PHP 5.4.0 something changed in the "install" portion of the Makefile that breaks this handy practice: # make install Installing PHP CLI binary:/usr/opt/php/bin/ Installing PHP CLI man page: /usr/opt/php/php/man/man1/ mkdir: /usr/opt/php/php: File exists mkdir: /usr/opt/php/php/man: Too many levels of symbolic links mkdir: /usr/opt/php/php/man/man1: Too many levels of symbolic links *** Error code 1 Stop in /usr/opt/php-5.4.2 (line 243 of Makefile). And when I take a look at what the install script has been doing: # cd /usr/opt/php # ls -l total 4 drwxr-xr-x 2 root wheel 512 May 5 13:43 bin lrwxr-xr-x 1 root wheel3 May 5 11:02 php -> php For some reason, when the prefix dir is a symbolic link, the 5.4.x Makefile creates a symbolic link to itself inside the prefix dir. Note also that the timestamp of the symbolic is identical to the actual symbolic link I make for the prefix destination, as if the Makefile tries to copy the directory into itself. The problem is easily solved by entering the prefix dir, removing the broken link that the install script creates and just "mkdir php", then resuming "make install" again. This shouldn't be needed, obviously. The script shouldn't fail just because the prefix happens to be a symbolic link to an actual destination sitting in the same directory - there are no technical complications caused by this handy practice. -- Edit this bug report at https://bugs.php.net/bug.php?id=61951&edit=1
Bug #51076 [Asn]: race condition in shtool's mkdir -p implementation
Edit report at https://bugs.php.net/bug.php?id=51076&edit=1 ID: 51076 Updated by: m...@php.net Reported by:geissert at debian dot org Summary:race condition in shtool's mkdir -p implementation Status: Assigned Type: Bug Package:Compile Failure Operating System: * PHP Version:5.3SVN-2010-02-18 (SVN) Assigned To:geissert Block user comment: N Private report: N New Comment: And you make me angry by wasting my time. It was just a template when marking a bug as duplicate. Stop calling people and do something yourself. You do not have to apologize for being an asshole, just don't be an asshole. Previous Comments: [2013-10-01 12:58:34] fviard at lacie dot com Hi, Today m...@php.net made me angry by posting a crappy comment on my 2,5years old bug report #54205 without even fixing the issue. This issue was so old that I completely forgot it. But now, I'm stupefied to notice that after 2 years, that issue that is resolvable with only a 5lines patch (easy to apply) is still not resolved. What are you doing? Mike, sorry to be offensive, but do you prefer harassing people on old bugs or fixing them? So, please close this bug soon! Thank you! [2013-10-01 12:30:15] m...@php.net Related To: Bug #54205 [2010-02-18 08:34:49] j...@php.net -Status: Closed +Status: Assigned Not fixed. [2010-02-18 00:31:15] geiss...@php.net -Status: Open +Status: Closed 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-02-18 00:30:13] s...@php.net Automatic comment from SVN on behalf of geissert Revision: http://svn.php.net/viewvc/?view=revision&revision=295225 Log: Fix race condition in shtool's mkdir -p implementation (bug #51076) 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 https://bugs.php.net/bug.php?id=51076 -- Edit this bug report at https://bugs.php.net/bug.php?id=51076&edit=1
Bug #61300 [Opn->Fbk]: segfault in assignment
Edit report at https://bugs.php.net/bug.php?id=61300&edit=1 ID: 61300 Updated by: m...@php.net Reported by:fbableus at yahoo dot fr Summary:segfault in assignment -Status: Open +Status: Feedback Type: Bug Package:Compile Failure Operating System: ARM PHP Version:5.4 Block user comment: N Private report: N New Comment: Please try using this snapshot: http://snaps.php.net/php5.4-latest.tar.gz For Windows: http://windows.php.net/snapshots/ There've been some ARM fixes recently, can you try a current snapshot, please? Previous Comments: [2013-01-11 21:46:17] fbableus at yahoo dot fr Successful compilation with --enable-debug on php 5.4.11RC1 (fails on 5.4.10) but still failing without the flag. Maybe related to https://bugs.php.net/bug.php?id=51216 [2013-01-03 12:33:05] bergere50 at yahoo dot fr I compile natively on my arm nas and I have the same issue. Can't install, can't run tests and when I run your same it crashes with segfault even if the code is unreachable. No output is performed apart 'Segmentation fault'. [2012-12-31 14:31:47] fbableus at yahoo dot fr The following code produces segfault (php 5.4.10): [2012-12-31 09:32:54] fbableus at yahoo dot fr The cli binary runs but when using tab key in interactive mode, segfault occurs. Apache handler fails too. [2012-03-06 12:42:57] fbableus at yahoo dot fr Description: When compiling php 5.4.0 under ARMV5tel (gcc 3.4.2) the make install command fails while attempting to install pear. make test even fails with segfault before any output. Compiling without any optimization (-O0 option) is successfull. Expected result: Successfull installation. Actual result: -- Segmentation fault -- Edit this bug report at https://bugs.php.net/bug.php?id=61300&edit=1
Bug #60772 [Opn->Fbk]: DB4/DB5 configure library lookup broken --build=x86_64-linux-gnu is passed
Edit report at https://bugs.php.net/bug.php?id=60772&edit=1
ID: 60772
Updated by: m...@php.net
Reported by:david at davidfavor dot com
Summary:DB4/DB5 configure library lookup broken
--build=x86_64-linux-gnu is passed
-Status: Open
+Status: Feedback
Type: Bug
Package:Compile Failure
Operating System: Ubuntu 11.10
PHP Version:5.3.9
Block user comment: N
Private report: N
New Comment:
How about --with-libdir=lib/x86_64-linux-gnu?
Previous Comments:
[2012-01-16 19:25:57] david at davidfavor dot com
Description:
First DB4/DB5 library lookup is far to simple.
Lookups are done for /usr/lib/libdb.a then /usr/lib/libdb.so in that order.
First problem is there's no consideration of 'shared', which if specified
should
reverse the search looking for .so before .a as they usually both exist.
Second problem is when --build=x86_64-linux-gnu (or any other value) is passed
no consideration is given. This means /usr/lib/x86_64-linux-gnu libraries are
ignored.
Neither --with-libdir=/usr/lib/x86_64-linux-gnu or --libdir=x86_64-linux-gnu
have any effect.
Third problem is diagnostics as many systems may have multiple copies of DB
installed. Be great to echo the info out of /usr/include/db.h as in...
DB_VERSION_{MAJOR,RELEASE,MINOR,PATCH} to clarify what's occurring.
Probably logic similar to libcurl is a good place to start.
Ugly fix is ln -s /usr/lib/x86_64-linux-gnu/libdb-5.1.so /usr/lib/.
Expected result:
Use all /usr/lib/(--build) libraries if --build is specified.
Actual result:
--
--build is ignored.
--
Edit this bug report at https://bugs.php.net/bug.php?id=60772&edit=1
Bug #55108 [Opn->Nab]: Unable to compile with MySQL
Edit report at https://bugs.php.net/bug.php?id=55108&edit=1 ID: 55108 Updated by: m...@php.net Reported by:s21122012 at yahoo dot com Summary:Unable to compile with MySQL -Status: Open +Status: Not a bug Type: Bug Package:Compile Failure Operating System: Mac OS X 10.6.8 PHP Version:5.4.0alpha1 Block user comment: N Private report: N New Comment: Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to "Open". Again, thank you for your continued support of PHP. Previous Comments: [2011-11-07 20:09:04] rpickard at gmail dot com Hi all, I had this problem trying to compile php 5.3.8 on OS X 10.7.2 (Lion) with MySQL 5.5.17 against Apache 2.2.21. I found a solution that would allow the build to complete here: https://github.com/adamv/homebrew-alt/issues/53 The solution is to set a EXTRA_CFLAGS value of -lresolv. In my case with the bash command export EXTRA_CFLAGS=-lresolv and then re-do make. There was no need to do make clean or distclean. After compiling all tests passed. Hope this helps, -p. [2011-09-01 22:30:46] matt dot fellows at onegeek dot com dot au I had the same issue with php 5.3.8 on Lion, but unfortunately I'm unable to use the mysqlnd option due to the fact that the database I'm connecting to is MySQL v3. Assuming a default MySQL installation (5.5.15 using either image or source), I was able to solve the issue with the following command: sudo install_name_tool -id /usr/local/mysql/lib/libmysqlclient.18.dylib /usr/local/mysql/lib/libmysqlclient.dylib Hope this helps someone. Cheers, Matt [2011-08-29 23:10:02] aaronh at bind dot com Same issue here running Lion Server / 10.7.1 and php-5.3.8 with the mysql binary. mysql-5.5.15-osx10.6-x86_64.tar.gz Darwin 6c1.sjc.6connect.com 11.0.1 Darwin Kernel Version 11.0.1: Thu Jul 28 02:01:39 PDT 2011; root:xnu-1699.23.4~1/RELEASE_X86_64 x86_64 Using built-in specs. Target: i686-apple-darwin11 Configured with: /private/var/tmp/llvmgcc42/llvmgcc42-2335.15~25/src/configure - -disable-checking --enable-werror --prefix=/Developer/usr/llvm-gcc-4.2 -- mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-prefix=llvm- - -program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib -- build=i686-apple-darwin11 --enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42- 2335.15~25/dst-llvmCore/Developer/usr/local --program-prefix=i686-apple- darwin11- --host=x86_64-apple-darwin11 --target=i686-apple-darwin11 --with-gxx- include-dir=/usr/include/c++/4.2.1 Thread model: posix gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00) [2011-07-01 18:12:31] s21122012 at yahoo dot com Thank you for your reply! I used the binary package when I posted the issue, but I had tried with a version compiled by myself before and the result was the same. Here is the file you requested (it was compiled using only the --prefix, --with-apxs2, --with- mysql and --with-mysqli flags): http://dl.dropbox.com/u/4460937/php_config.h I have been able to compile it with MySQL support using the native driver (mysqlnd), as suggested by you. I would also like to mention that I had similar errors with PHP 5.3.6 in the past. I am not sure if the conflict was between the same macros, though. [2011-07-01 16:22:28] johan...@php.net These might be caused by conflicts in the usage of either HAVE_DNS_SEARCH or HAVE_RES_NSEARCH between MySQL libs and PHP. Did you use MySQL binary packages or did you compile MySQL yourself? I have no Mac at hand, could you please send me the file main/php_config.h from the failing build? - Thanks. (As remark: You could build PHP using mysqlnd instead of libmysql by using --with-mysql=mysqlnd --with-mysqli=mysqlnd - but your issue should be fixed anyways.) 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 https://bugs.php.net/bug.php?id=55108 -- Edit this bug report at https://bugs.php.net/bug.php?id=55108&edit=1
Bug #61057 [Opn->Fbk]: PHP 5.3.10 fails to cross compile when FPM is enabled (ptrace)
Edit report at https://bugs.php.net/bug.php?id=61057&edit=1 ID: 61057 Updated by: m...@php.net Reported by:d dot albano at gmail dot com Summary:PHP 5.3.10 fails to cross compile when FPM is enabled (ptrace) -Status: Open +Status: Feedback Type: Bug Package:Compile Failure Operating System: Linux PHP Version:5.3.10 Block user comment: N Private report: N New Comment: What is the outcome of the test? Previous Comments: [2012-02-12 21:34:13] d dot albano at gmail dot com I'm cross compiling because i'm building a set of images for boards like alix, routerboards and, when it will be out, raspberry pi too. I know that it may sound strange, but i don't want to put an entire distribution on the alix my 30mb systems works perfectly and has everything i need. Thank you, i'll do a test. [2012-02-12 21:27:44] ras...@php.net Why are you cross-compiling to the same architecture? You may be able to solve this simply by using a newer version of autoconf to generate the configure script. As a quick test, try building the latest PHP 5.4 with a recent version of autoconf installed. (use ./buildconf --force to force re-generation of the configure script) For PHP 5.3 the latest you can use is autoconf-2.59 For PHP 5.4 the oldest you can use is autoconf-2.59 [2012-02-12 21:06:43] hotseason007 at gmail dot com I also reach it ,but php.net don't regard it as a bug ! here is my report: https://bugs.php.net/bug.php?id=61063 I have fix and Here is the guid: https://github.com/Qzi/webstore/wiki the page attaches the patch enjoy it !! [2012-02-11 17:15:22] d dot albano at gmail dot com Description: I'm trying to cross compile php 5.3.10 (build x86, host x86, target x86) but when i enable FPM i get the following error checking whether ptrace works... configure: error: can not run test program while cross compiling I know that FPM is experimental, btw the bug is related to configure script and not to FPM itself. Wihtout fpm, enabling only cgi and cli works fine Here more output, starting from SAPI modules Configuring SAPI modules checking for AOLserver support... no checking for Apache 1.x module support via DSO through APXS... no checking for Apache 1.x module support... no checking whether to enable Apache charset compatibility option... no checking for Apache 2.0 filter-module support via DSO through APXS... no checking for Apache 2.0 handler-module support via DSO through APXS... no checking for Apache 1.x (hooks) module support via DSO through APXS... no checking for Apache 1.x (hooks) module support... no checking whether to enable Apache charset compatibility option... no checking for Caudium support... no checking for CLI build... yes checking for Continuity support... no checking for embedded SAPI library support... no checking for FPM build... yes checking for setenv... yes checking for clearenv... yes checking for setproctitle... no checking for library containing socket... none required checking for library containing inet_addr... none required checking for errno.h... yes checking for fcntl.h... yes checking for stdio.h... yes checking for stdlib.h... yes checking for unistd.h... yes checking for sys/uio.h... yes checking for sys/select.h... yes checking for sys/socket.h... yes checking for sys/time.h... yes checking for arpa/inet.h... yes checking for netinet/in.h... yes checking for prctl... yes checking for clock_gettime... yes checking for ptrace... yes checking whether ptrace works... configure: error: can not run test program while cross compiling make[1]: *** [/home/daniele/sviluppo/clew.js/br-rootfs/build/php- 5.3.10/.stamp_configured] Errore 1 make: *** [all] Errore 2 Expected result: it should go ahead Actual result: -- checking whether ptrace works... configure: error: can not run test program while cross compiling -- Edit this bug report at https://bugs.php.net/bug.php?id=61057&edit=1
Bug #54205 [Opn->Dup]: race condition in shtool's mkdir -p implementation. AND shtool 2.0.8
Edit report at https://bugs.php.net/bug.php?id=54205&edit=1 ID: 54205 Updated by: m...@php.net Reported by:fviard at lacie dot com Summary:race condition in shtool's mkdir -p implementation. AND shtool 2.0.8 -Status: Open +Status: Duplicate Type: Bug Package:Compile Failure Operating System: Linux PHP Version:trunk-SVN-2011-03-09 (SVN) Block user comment: N Private report: N New Comment: Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Thank you for your interest in PHP. See bug #51076 Previous Comments: [2011-03-09 16:23:49] fviard at lacie dot com Description: Previous bug #51076 http://bugs.php.net/bug.php?id=51076 was fixed by: svn commit r295225 ( http://svn.php.net/viewvc?view=revision&revision=295225 ) but later, commit r295230 ( http://svn.php.net/viewvc? view=revision&revision=295230) updated shtool to version 2.0.8 without backporting the previous patch. (In upstream, nothing changed regarding mkdir between 2.0.6 and 2.0.8) And so, the race condition with -j>1 is still there. (In my case, it appeared during the "make install" step processing the installation of the extensions) Error was: "mkdir: cannot create directory ... : File exists" So, the patch in r295225 should be reapplied to shtool 2.0.8. In a second time, why not replacing all the mkdir code block of shtool by something like: if opt_p = no: mkdir ... chmod ... chown ... chgrp ... ... else: mkdir -p ... chmod -R ... chown -R ... chgrp -R ... ... That would be safer I think ... -- Edit this bug report at https://bugs.php.net/bug.php?id=54205&edit=1
Bug #53772 [Opn->Fbk]: Can´t compile
Edit report at https://bugs.php.net/bug.php?id=53772&edit=1 ID: 53772 Updated by: m...@php.net Reported by:nestor_bolivar at digitel dot com dot ve Summary:Can´t compile -Status: Open +Status: Feedback Type: Bug Package:Compile Failure Operating System: Solaris 10 PHP Version:5.3.5 Block user comment: N Private report: N New Comment: Is this still an issue for you? I recently built fine a couple times on Solaris 11. By the way; the upload feature is for patches not logs. Previous Comments: [2011-01-17 23:50:32] nestor_bolivar at digitel dot com dot ve Description: ld: fatal: library -lnet: not found ld: fatal: File processing errors. No output written to sapi/cgi/php-cgi collect2: ld returned 1 exit status *** Error code 1 make: Fatal error: Command failed for target `sapi/cgi/php-cgi' Test script: --- ./configure '--prefix=/usr/local/php' '--with-config-file-path=/usr/local/php/lib' '--with-libxml-dir=/usr/local' '--with-zlib=/usr/local' '--with-xpm-dir=/usr/local' '--with-mysql=/usr/local/mysql' '--with-mysqli=/usr/local/mysql/bin/mysql_config' '--without-pgsql' '--with-jpeg-dir=/usr/local/lib' '--with-zlib-dir=/usr/local/lib' '--with-gd=/usr/local' '--enable-mbstring' '--enable-exif' '--enable-sockets' '--enable-soap' '--with-png-dir=/usr/local/lib' '--with-curl=/usr/local' '--with-ldap=/usr/local' '--with-openssl=/usr/local/ssl' '--with-gettext' '--with-pcre-dir=/usr/local' '--with-freetype-dir=/usr/local' '--with-mssql=/usr/local/freetds' '--with-oci8=/export/home/oraclien/instantclient_10_2' -- Edit this bug report at https://bugs.php.net/bug.php?id=53772&edit=1
Bug #53571 [Opn->Sus]: phpize: Can not build extensions with config[0-9].m4
Edit report at https://bugs.php.net/bug.php?id=53571&edit=1 ID: 53571 Updated by: m...@php.net Reported by:admin at webdesignforall dot net Summary:phpize: Can not build extensions with config[0-9].m4 -Status: Open +Status: Suspended Type: Bug Package:Compile Failure Operating System: linux PHP Version:5.3.4 Block user comment: N Private report: N New Comment: Patches welcome. In the meantime you can enable phpize builds with the a little trick in config.m4: sinclude(config9.m4) See pecl/http as example: http://svn.php.net/viewvc/pecl/http/branches/DEV_2/config.m4?revision=303137&view=markup Previous Comments: [2010-12-18 16:10:39] admin at webdesignforall dot net phpize is quicker than compiling php with the shared extension, so I'll stick to renaming the config0.m4 for now. [2010-12-18 13:07:13] johan...@php.net This actually is a bug in phpize, if at all. The name actually is part of a simple dependency mechanism for building extensions in the right order. You can build sqlite3 shared when doing ./configure--with-sqlite3=shared in the PHP source, no need for phpize. [2010-12-18 07:20:44] admin at webdesignforall dot net Description: ext/sqlite3 has a config0.m4 file instead of config.m4 so phpize complains. Nothing major since it can be renamed before running phpize, just a niggle. -- Edit this bug report at https://bugs.php.net/bug.php?id=53571&edit=1
Bug #53442 [Opn->Nab]: [fix provided] configure --with-iconv=DIR fails due to two faulty tests
Edit report at https://bugs.php.net/bug.php?id=53442&edit=1 ID: 53442 Updated by: m...@php.net Reported by:fransmeulenbroeks at gmail dot com Summary:[fix provided] configure --with-iconv=DIR fails due to two faulty tests -Status: Open +Status: Not a bug Type: Bug Package:Compile Failure Operating System: linux PHP Version:5.2SVN-2010-12-01 (snap) Block user comment: N Private report: N New Comment: Anything to add here? Previous Comments: [2013-06-25 16:35:47] fel...@php.net There is a check right after what you have quoted which handles the supplied path. ... dnl dnl Check external libs for iconv funcs dnl if test "$found_iconv" = "no"; then for i in $PHP_ICONV /usr/local /usr; do ... [2010-12-01 23:10:25] fransmeulenbroeks at gmail dot com oh and the subject line is wrong this reports and fixes only one faulty test, the other one is reported and fixed in 53443 [2010-12-01 23:09:00] fransmeulenbroeks at gmail dot com oops, made typo in patch This line: + if test "$PHP_ICONV" != no"; then is missing a " and must read + if test "$PHP_ICONV" != "no"; then Uploaded a new patch. Sorry for any inconvenience! [2010-12-01 22:50:49] fransmeulenbroeks at gmail dot com Description: when trying to cross-compile configure picked up the host iconv, not the target one, resulting in wrong paths later on and configure failing. configure was called with configure --with-iconv=DIR (where DIR is the dir to find the iconv stuff). This fails at two places. First one is due to a faulty test in acinclude.m4 It tests PHP_ICONV against "yes". However PHP_ICONV in my case contains the path so we should test against not "no" (PHP_ICONV can be a dir because otherwise this code later on would not make any sense: for i in $PHP_ICONV /usr/local /usr; do ) The following patch is for 5.2.13, but I have verified it is also in the 5.2 snap from today. Index: php-5.2.13/acinclude.m4 === --- php-5.2.13.orig/acinclude.m4 +++ php-5.2.13/acinclude.m4 @@ -2430,7 +2430,8 @@ AC_DEFUN([PHP_SETUP_ICONV], [ dnl dnl Check libc first if no path is provided in --with-iconv dnl - if test "$PHP_ICONV" = "yes"; then + dnl must check against no, not against yes as PHP_ICONV can also include a path, which implies yes + if test "$PHP_ICONV" != no"; then AC_CHECK_FUNC(iconv, [ found_iconv=yes ],[ -- Edit this bug report at https://bugs.php.net/bug.php?id=53442&edit=1
Bug #51247 [Asn->Csd]: SHA-2 family function test in crypt are wrong
Edit report at https://bugs.php.net/bug.php?id=51247&edit=1 ID: 51247 Updated by: m...@php.net Reported by:ondrej at debian dot org Summary:SHA-2 family function test in crypt are wrong -Status: Assigned +Status: Closed Type: Bug Package:Compile Failure Operating System: Linux PHP Version:5.3.2 Assigned To:pajoye Block user comment: N Private report: N New Comment: Has recently been fixed. Previous Comments: [2010-03-09 16:06:55] paj...@php.net Given the tests we have made lately on many platforms (with the author of the bundled SHA and blowfish implementation), we ponder to always use these version to provide a true portable crypt to PHP users. I will post the details of the tests in our wiki to explain why it is a must (no clear standard on error, differences in the way some character are processd, etc.). I also recommend to debian to use the PHP implementation instead of relying of the various system versions. About the m4 code, I will have to test it on our tests platforms. Cheers, [2010-03-09 15:04:55] ondrej at debian dot org Description: Tests for SHA-2 family functions in crypt() from -lcrypt are broken: strcpy(&answer[29],"$6$$QMXjqd7rHQZPQ1yHsXkQqC1FBzDiVfTHXL.LaeDAeVV.IzMaV9VU4MQ8 kPuZa2SOP1A0RPm772EaFYjpEJtdu."); in SHA-512 test will surely not fit into char answer[80]... and because of that salt (on the stack) is overwriten, same problem with SHA-256. But even if you increase the buffer, the code there is just plain wrong and could never function correctly. Looks like this code was not properly tested since there are probably too few platforms where you can satisfy all needed crypt functions (extended DES and Blowfish) and therefore internal crypt implementation is always used. Attached patch corrects that. If I have a more time I'll rework this whole code, to just use internal reimplementations for functions not provided by system library. Expected result: checking for SHA512 crypt... yes checking for SHA256 crypt... yes Actual result: -- checking for SHA512 crypt... no checking for SHA256 crypt... no -- Edit this bug report at https://bugs.php.net/bug.php?id=51247&edit=1
Bug #50291 [ReO->Fbk]: incorrect usage of autoconf diversions
Edit report at https://bugs.php.net/bug.php?id=50291&edit=1
ID: 50291
Updated by: m...@php.net
Reported by:vapier at gentoo dot org
Summary:incorrect usage of autoconf diversions
-Status: Re-Opened
+Status: Feedback
Type: Bug
Package:Compile Failure
Operating System: Linux
PHP Version:5.3.1
Block user comment: N
Private report: N
New Comment:
IIRC this is obsolete?
Previous Comments:
[2011-10-12 16:00:04] reeves_28 at yahoo dot com
One to make it compile is to run grep -Rn "divert(" and comment out all lines
in the *.m4 and *.in files that show up. There should be only three files that
actuall need changed. Ignore /ext/fileinfo/tests/magic this doesn't affect the
compile. You will get a lot of warnings from autoconf but it will compile.
[2011-04-25 11:12:57] mail at crick dot ru
PS. I mean the patch to compile only with autoconf> 2.6.4, not for both post
and pre.
[2011-04-25 11:09:15] mail at crick dot ru
Can I ask post here a patch that will allow PHP to compile with autoconf
version> 2.6? I think it will be useful to many users.
[2011-04-25 01:21:24] ras...@php.net
I spent quite a while on it. I couldn't come up with a viable way to support
both
pre and post autoconf-2.64 so it is either/or at this point. Every distro has
pre-
2.64, not everyone has post 2.64. We will eventually be able to make a clean
break, but it definitely won't be in 5.3.
[2011-04-24 23:41:25] mail at crick dot ru
This annoying bug is still there. How about solutions?
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
https://bugs.php.net/bug.php?id=50291
--
Edit this bug report at https://bugs.php.net/bug.php?id=50291&edit=1
Req #43593 [Opn->Fbk]: Impossible to disable Zend Memory Manager in anything other than CLI SAPI
Edit report at https://bugs.php.net/bug.php?id=43593&edit=1 ID: 43593 Updated by: m...@php.net Reported by:phajdan dot jr at gmail dot com Summary:Impossible to disable Zend Memory Manager in anything other than CLI SAPI -Status: Open +Status: Feedback Type: Feature/Change Request Package:Compile Failure Operating System: Linux Gentoo 2007.0 PHP Version:5.2CVS-2007-12-14 Block user comment: N Private report: N New Comment: Works fine here. What SAPI are you using? /usr/share/nginx/html$ USE_ZEND_ALLOC=0 PHP_FCGI_CHILDREN=0 php-cgi -b 0: $ curl --progress localhost/info.php | grep "Memory Manager" Zend Memory Manager disabled It's really just coming from the environment: http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_alloc.c#2723 Previous Comments: [2008-02-02 09:18:42] phajdan dot jr at gmail dot com After compiling with that option Zend MM is still enabled, according to phpinfo(). Anyway, it must be possible to somehow disable it, because debug build does it. But it would be not a good solution to use debug build in production. Please, please check it yourself, *seriously* - no guessing, not requiring me to check every opportunity. [2008-02-01 22:48:39] j...@php.net How about --disable-malloc-mm ?? [2008-01-29 07:06:10] phajdan dot jr at gmail dot com Well, reproduction script is *not*needed* as it's a PHP configuration setting issue. It is visible for example in and I gave exact *steps* to reproduce at the beginning. Here they are, for convenience: The goal is to disable the Zend Memory Manager. Try #1: 1. set USE_ZEND_ALLOC in the environment (/etc/profile) 1a. also tried other ways, like setting it in the Apache config (SetEnv etc) 2. Restart Apache to make sure change takes effect 3. View phpinfo page to see if Zend Memory Manager got disabled 3a. But this way works for the CLI version of PHP (setting env in /etc/profile). Try #2: (proven to be futile and ineffective, but anyway) I tried to recompile PHP with ./configure switches like --disable-zend-memory-manager or --enable-malloc-mm (some webpages told they will disable Zend MM), but as other developers said in this report, there are no such compile options. [2007-12-17 10:59:06] phajdan dot jr at gmail dot com So the bug I referred to was http://bugs.php.net/bug.php?id=43397. Curently it's marked as a duplicate of some other bug, which is now closed because of lack of feedback. I tried to request reopening my original bug, unfortunately without success. About setting env var - please note that I tried this method. No go. phpinfo shows that Zend Memory Manager is enabled. Note that I didn't set it from command line, but had in environment (something like export USE_ZEND_ALLOC=0; /usr/sbin/httpd ...). But it shouldn't make a difference. [2007-12-17 10:00:38] sni...@php.net How about you tell us what the crash is you get? (what bug id was the one you reported?) Also note that some crash bugs were fixed recently. And there are no -disable-zend-memory-manager or --enable-malloc-mm configure options. To disable the memory manager (for debugging) you start e.g. apache with same way you do with PHP CLI: # USE_ZEND_ALLOC=0 /usr/sbin/httpd 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 https://bugs.php.net/bug.php?id=43593 -- Edit this bug report at https://bugs.php.net/bug.php?id=43593&edit=1
Req #57206 [Opn->Fbk]: Add ability to change auto_commit
Edit report at https://bugs.php.net/bug.php?id=57206&edit=1
ID: 57206
Updated by: m...@php.net
Reported by:tiggscharley at charter dot net
Summary:Add ability to change auto_commit
-Status: Open
+Status: Feedback
Type: Feature/Change Request
-Package:PDO_PGSQL
+Package:*General Issues
Operating System: FreeBSD 6.1-Release
PHP Version:5.1.4
Block user comment: N
Private report: N
New Comment:
What's wrong with BEGIN & COMMIT?
Previous Comments:
[2006-08-30 12:27:13] tiggscharley at charter dot net
Description:
Would it be possible to have the ability to change the value of
PDO::ATTR_AUTOCOMMIT within the PDO_PGSQL driver at will? Specifically, if a
connection is opened where PDO::ATTR_AUTOCOMMIT is true but there are certain
processes that span classes within the currently executing page that use the
same connection, it would be helpful to be able to selectively turn off
autocommit and turn it back on once the transactions are complete. Attempting
to set autocommit to off using $dbh->setAttribute ( PDO::ATTR_AUTOCOMMIT, false
) after the connection has been made results in an exception.
Reproduce code:
---
setAttribute(PDO::ATTR_AUTOCOMMIT, false);
?>
Expected result:
PDO::ATTR_AUTOCOMMIT to be set to false.
Actual result:
--
Fatal error: Uncaught exception 'PDOException' with message 'The auto-commit
mode cannot be changed for this driver' in /usr/local/www/test_autocommit.php:4
Stack trace:
#0 /usr/local/www/test_autocommit.php(4): PDO->setAttribute(0, false)
#1 {main}
thrown in /usr/local/www/test_autocommit.php on line 4
--
Edit this bug report at https://bugs.php.net/bug.php?id=57206&edit=1
Req #57741 [Opn->Fbk]: Support for COPY FROM STDIN statements
Edit report at https://bugs.php.net/bug.php?id=57741&edit=1 ID: 57741 Updated by: m...@php.net Reported by:sebastianmarconi at gmail dot com Summary:Support for COPY FROM STDIN statements -Status: Open +Status: Feedback Type: Feature/Change Request -Package:PDO_PGSQL +Package:*General Issues Operating System: All PHP Version:5.2.1 Block user comment: N Private report: N New Comment: Looks like current PDO_PGSQL has a COPY interface. Previous Comments: [2007-07-12 11:02:32] sebastianmarconi at gmail dot com Description: Would it be possible to have something like pg_copy_from? We use it a lot in migrations and data imports. Currently, we need to create a different connection using the old extension. -- Edit this bug report at https://bugs.php.net/bug.php?id=57741&edit=1
Req #57734 [Opn->Wfx]: PECL version of PDO_PGSQL is very out of date
Edit report at https://bugs.php.net/bug.php?id=57734&edit=1 ID: 57734 Updated by: m...@php.net Reported by:bill dot w dot farrar at gmail dot com Summary:PECL version of PDO_PGSQL is very out of date -Status: Open +Status: Wont fix Type: Feature/Change Request -Package:PDO_PGSQL +Package:*General Issues Operating System: Linux PHP Version:5.2.1 Block user comment: N Private report: N New Comment: PECL PDO packages are obsolete. Previous Comments: [2007-07-06 13:56:02] bill dot w dot farrar at gmail dot com Description: Having just been bitten by this bug: http://bugs.php.net/bug.php?id=36681 I've done a little digging and found that while the bug is indeed fixed in the bundled version of the driver, it isn't in the latest PECL version. In fact, the latest pecl version (1.0.2) was released over a year ago, which probably means there have been many bugs fixed since then. This goes against the PDO documentation on the php.net site, which recommends using the PECL version of PDO so you get updates quicker. Expected result: Either a new release of PDO_PGSQL (and possibly other drivers) that at least match the version bundled in with php, or the deprecation of the PECL versions of these extensions with the documentation updated to this effect. Actual result: -- Reality doesn't appear to match the advice on the php documentation page for PDO. :( -- Edit this bug report at https://bugs.php.net/bug.php?id=57734&edit=1
Bug #57396 [Opn->Fbk]: The pdo_psql not support array[x:y]?
Edit report at https://bugs.php.net/bug.php?id=57396&edit=1 ID: 57396 Updated by: m...@php.net Reported by:jacch dot tw at gmail dot com Summary:The pdo_psql not support array[x:y]? -Status: Open +Status: Feedback Type: Bug -Package:PDO_PGSQL +Package:*General Issues Operating System: Mandriva 2006 PHP Version:5.2.0 RC4 Block user comment: N Private report: N New Comment: Should be gone since fixing bug #64953 Please try PHP-5.4.20 or newer. Previous Comments: [2006-11-26 11:58:25] jacch dot tw at gmail dot com Description: I'm tring pgsql array on php5.2 pdo_pgsql object, but I found this problem on my php machine. when i query this sql string ,it cann't run on my machine. "select array_to_string(array[1:10],";") from sometable limit 30" , this cann't work. but !! "select array_to_string(array,";") from sometable limit 30" it work !! So ,how can I do for this problem; -- Edit this bug report at https://bugs.php.net/bug.php?id=57396&edit=1
Bug #56082 [Opn->Wfx]: install fails - can't find krb5.h
Edit report at https://bugs.php.net/bug.php?id=56082&edit=1 ID: 56082 Updated by: m...@php.net Reported by:matt at kynx dot org Summary:install fails - can't find krb5.h -Status: Open +Status: Wont fix Type: Bug -Package:PDO_PGSQL +Package:*General Issues Operating System: RedHat 9 PHP Version:5CVS-2004-05-30 (dev) Block user comment: N Private report: N New Comment: PECL PDO packages are obsolete. Previous Comments: [2004-05-30 11:28:59] matt at kynx dot org Description: On RedHat 9, the file krb5.h required for installation of this package is located in /usr/kerebos/include where make cannot find it. To get this package to install, run $ CFLAGS="-I/usr/kerberos/include"; export CFLAGS before you run the pear install. -- Edit this bug report at https://bugs.php.net/bug.php?id=56082&edit=1
Bug #58580 [Opn->Wfx]: package can not be installed on debian
Edit report at https://bugs.php.net/bug.php?id=58580&edit=1 ID: 58580 Updated by: m...@php.net Reported by:jwspam1 at gmail dot com Summary:package can not be installed on debian -Status: Open +Status: Wont fix Type: Bug -Package:PDO_PGSQL +Package:*General Issues Operating System: Debian 5.0 PHP Version:5.2.5 Block user comment: N Private report: N New Comment: PECL PDO packages are obsolete. Previous Comments: [2009-03-09 16:41:58] jwspam1 at gmail dot com Description: pecl install pdo_pgsql gives the following error: checking for pg_config: not found configure:error: cannot find libpg-fe.h please specify correct postgresql installation path -- Edit this bug report at https://bugs.php.net/bug.php?id=58580&edit=1
Bug #58772 [Opn->Fbk]: PDO::fetchAll() issue with INSERT on view
Edit report at https://bugs.php.net/bug.php?id=58772&edit=1 ID: 58772 Updated by: m...@php.net Reported by:michael dot leuthold at googlemail dot com Summary:PDO::fetchAll() issue with INSERT on view -Status: Open +Status: Feedback Type: Bug -Package:PDO_PGSQL +Package:*General Issues Operating System: Linux / Debian PHP Version:5.2.6 Block user comment: N Private report: N New Comment: Your reproduce scripts are not available anymore and PQresultStatus for an INSERT that that resolves to a RULE with an SELECT as last statement returns PGRES_COMMAND_OK, so the result is freed regardless. Previous Comments: [2009-07-23 11:19:19] michael dot leuthold at googlemail dot com Description: "ON INSERT" rule on view returns rows which cannot be retrieved by PDO::fetchAll(): We have a view that has a ON INSERT DO INSTEAD rule. In this rule the insert on the view is basically split to do the actual inserts into the individual tables. In the end it SELECTs the new row (which has just been created) from that view. Doing this in psql for example behaves like expected: after the INSERT the new row is returned. We haven't managed to retrieve that row into an array via "PDO::fetchAll(PDO::FETCH_ASSOC)" - for some reason PDO seems to ignore that returned data - though PDO::rowCount returns 1 (actually it does always return 1 no matter how many rows are expected to be returned by that INSERT). This scenario works as expected when connected via PHP's pg_connect using pg_fetch_all. Information from phpinfo(): pdo_pgsql PDO Driver for PostgreSQL enabled PostgreSQL(libpq) Version 8.3.7 Module version 1.0.2 Revision$Id: pdo_pgsql.c,v 1.7.2.11.2.2 2007/12/31 07:20:10 sebastian Exp $ Reproduce code: --- For a small schema setup run this file through psql: http://www.byoc.de/pdo-pgsql.sql.txt This script inserts to the created example view and tries to retrieve the values: http://www.byoc.de/pdo-pgsql.php.txt Expected result: the associative array should contain all rows returned by the INSERT statement. Actual result: -- an empty array is returned by PDO::fetchAll though there are rows returned. -- Edit this bug report at https://bugs.php.net/bug.php?id=58772&edit=1
Bug #65796 [Opn->Nab]: mkdir creates folders with wrong permissions
Edit report at https://bugs.php.net/bug.php?id=65796&edit=1
ID: 65796
Updated by: m...@php.net
Reported by:cmfcmf dot flach at gmail dot com
Summary:mkdir creates folders with wrong permissions
-Status: Open
+Status: Not a bug
Type: Bug
Package:Directory function related
Operating System: Linux/Ubuntu 13.4
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Check your umask.
Previous Comments:
[2013-10-01 09:48:19] d...@php.net
I get the same on PHP 5.5.3. chmod('test', 0777) then transforms the directory
to
the right chmod.
[2013-10-01 09:44:10] cmfcmf dot flach at gmail dot com
Description:
Creating a directory using mkdir() does not respect the permissions given.
Test script:
---
https://bugs.php.net/bug.php?id=65796&edit=1
Bug #61548 [Opn->Csd]: content-type must appear at the end of headers for 201 Location to work in http
Edit report at https://bugs.php.net/bug.php?id=61548&edit=1
ID: 61548
Updated by: m...@php.net
Reported by:david at greenseedtechnologies dot com
Summary:content-type must appear at the end of headers for
201 Location to work in http
-Status: Open
+Status: Closed
Type: Bug
Package:HTTP related
Operating System: linux
PHP Version:5.3.10
Block user comment: N
Private report: N
New Comment:
Automatic comment on behalf of mike
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=18b04b480ebc41841b2004cc11797eda40fb3958
Log: Fixed bug #61548
Previous Comments:
[2012-03-28 22:14:35] david at greenseedtechnologies dot com
Description:
Line 445 of http_fopen_wrapper.c
only works of the content-type is at the end of a list of header fields in the
context. It fails if it is in the middle, or the beginning.
memmove(tmp, tmp + (s2 + 1 - tmp_c), tmp_c + l - 1 - s2);
To see the problem watch the HTTP stream in something like WireShark.
Test script:
---
null
."AnyHeader: 1\r\n"
// BUG on line 445 of http_fopen_wrapper.c of PHP: content_type cannot be
in the middle of headers.
."Content-type: anythingyouwanthere\r\n"
."SomeOtherHeader: 2\r\n"
);
/*
PHP incorrectly sends across when following the "Location":
GET /services/storm/lead HTTP/1.0
Host: storm
SomeOtherHeader: 2ent-type: anythingyouwanthere
SomeOtherHeader: 2
*/
$http['method'] = 'POST';
$options = array('http' => $http);
$context = stream_context_create($options);
$result =
file_get_contents('http://some/url/that/resturns/201/and/has/a/Location/in/the/header',
false, $context);
Expected result:
GET /services/storm/lead HTTP/1.0
Host: storm
AnyHeader: 1
SomeOtherHeader: 2
Actual result:
--
GET /services/storm/lead HTTP/1.0
Host: storm
SomeOtherHeader: 2ent-type: anythingyouwanthere
SomeOtherHeader: 2
--
Edit this bug report at https://bugs.php.net/bug.php?id=61548&edit=1
Bug #54114 [Nab]: Output Buffer Dumps Data On Error
Edit report at https://bugs.php.net/bug.php?id=54114&edit=1
ID: 54114
Updated by: m...@php.net
Reported by:danhstevens at gmail dot com
Summary:Output Buffer Dumps Data On Error
Status: Not a bug
Type: Bug
Package:Output Control
Operating System: all
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
Well, this is pretty much the wrong
way then, IMO. Is this about Symfony 1 or 2?
Previous Comments:
[2013-09-30 14:58:14] danhstevens at gmail dot com
Mike, this is a security issue because users of frameworks like Symfony are
highly
exposed to this bug. Symfony uses OB for parsing configuration files which
often
contain sensitive information. One syntax error in your config file and all
your
config params are on display to the www. It's unexpected behavior, and it can
(and
in my case, has) caused the release of sensitive information.
[2013-09-30 12:11:25] m...@php.net
I'm not sure why this should be security related?
Why even output security sensitive information at all?
[2011-08-17 13:44:19] nicolas dot grekas+php at gmail dot com
Here is an other example that can't be workaround using danhstevens' technique:
[2011-03-10 19:41:28] danhstevens at gmail dot com
I've found a viable work-around for this bug (although a patch of the core
would still be ideal so people don't discover this potential security issue the
hard-way).
By registering the following shutdown handler before any output buffering the
dump of data can be prevented:
1)
{
//Prevent data in buffer from dumping
ob_end_clean();
}
}
register_shutdown_function('shutdown_fn');
Now when using the examples above that normally cause the buffer to dump to the
client the buffer data is disposed of. Of course, this can be extended to use
ob_get_contents and redirect the data to file or other means if necessary. This
approach is working for me (on PHP 5.3.5).
~Dan
[2011-03-06 16:51:52] neweracracker at gmail dot com
I've managed to reproduce this in Windows 7 running php 5.2.17 (with
php.ini-dist) and php 5.3.5 (with php.ini-development).
Here is my test script:
I've reported this as bug #54174 which got closed due being a dupe of this one
so I am leaving this comment here for reference purposes.
Regards,
NewEraCracker.
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
https://bugs.php.net/bug.php?id=54114
--
Edit this bug report at https://bugs.php.net/bug.php?id=54114&edit=1
Bug->Req #54588 [Opn->Dup]: Included files should not output shebang
Edit report at https://bugs.php.net/bug.php?id=54588&edit=1 ID: 54588 Updated by: m...@php.net Reported by:djones109 at gmail dot com Summary:Included files should not output shebang -Status: Open +Status: Duplicate -Type: Bug +Type: Feature/Change Request Package:Output Control Operating System: All PHP Version:5.3SVN-2011-04-21 (snap) Block user comment: N Private report: N New Comment: See req #31563 Previous Comments: [2011-04-21 21:50:21] djones109 at gmail dot com Description: When writing CLI scripts, one typically adds a shebang to the beginning of the script. When the script is executed, the shebang is not outputted. On occasion, it's useful to include another CLI script. When the file is included, the shebang on the included file is outputted, contrary to expected behavior. Test script: --- file1.php: #!/usr/bin/php file2.php: #!/usr/bin/php Expected result: Including file2 Inside file2 Actual result: -- Including file2 #!/usr/bin/php Inside file2 -- Edit this bug report at https://bugs.php.net/bug.php?id=54588&edit=1
Req #64488 [Opn->Dup]: Allow open tag to "discard the previous shebang"
Edit report at https://bugs.php.net/bug.php?id=64488&edit=1
ID: 64488
Updated by: m...@php.net
Reported by:php at richardneill dot org
Summary:Allow open tag to "discard the previous shebang"
-Status: Open
+Status: Duplicate
Type: Feature/Change Request
Package:CGI/CLI related
PHP Version:5.4.13
Block user comment: N
Private report: N
New Comment:
See req #31563
Previous Comments:
[2013-03-22 23:46:17] bobwei9 at hotmail dot com
It's principally a good idea, but a function is very complicated to realize as
the shebang is already sent when the function will be called.
What I'd prefer is erasing the shebang line every time in a non-cli script when
the two first bytes are '#' and '!'. (I'd wonder if there exist some people who
really begin the content of their websites with a #!...)
[2013-03-22 10:32:27] php at richardneill dot org
Description:
It would be really useful to be able to write single files that would run
cleanly
as *either* CGI or CLI scripts.
At the moment, the closing '?>' tag will eat the trailing newline.
So, similarly, I'd like to request a way for the opening '";
}else{
echo "I am CLI\n";
}
?>
Expected result:
Exactly one line should be printed:
"I am CLI|CGI"
Actual result:
--
In CLI mode, this script cleanly prints:
"I am CLI"
but in Apache mode, the script prints the first line literally:
"#!/usr/bin/php
I am CGI"
It's relatively easy to work around this with a wrapper script, but I'd
appreciate the elegance of having a single file that can operate in both modes.
Thank you for your time.
--
Edit this bug report at https://bugs.php.net/bug.php?id=64488&edit=1
Bug #51749 [Opn->Nab]: header("Location:") changing HTTP status
Edit report at https://bugs.php.net/bug.php?id=51749&edit=1
ID: 51749
Updated by: m...@php.net
Reported by:theimp at iinet dot net dot au
Summary:header("Location:") changing HTTP status
-Status: Open
+Status: Not a bug
Type: Bug
Package:HTTP related
Operating System: Debian Lenny
PHP Version:5.3.2
Block user comment: N
Private report: N
New Comment:
So, nothing new here, closing.
Previous Comments:
[2010-05-30 00:41:43] theimp at iinet dot net dot au
The patch no-http-status-code-overwrite-on-location-header (last revision
2010-05-29 20:00 UTC) is a patch to main/SAPI.c from 5.3.2 (04 Mar 2010).
The relevant changes are lines 661 to 665 (661 to 668 in the original), and 675
to 678 (678 in the original).
I deliberately chose the simplest method I could; it simply checks to see if
the status is currently 200, and if so, then it updates the status code as
before. Otherwise, it does not.
As mentioned, the behavior that is the subject of this bug has been a
non-problem for a very long time. I am more and more inclined to agree with
mike at php dot net that "fixing" it just might not be worth it, when compared
against the possibility of failures related to backwards-compatibility
expectations. But aharvey at php dot net does have a valid point too.
A method I considered, but rejected as too inefficient (considering the
benefit), involved creating a new variable to store the status when set, and
only write it just before the headers are sent.
Another similar method that I considered, which was more efficient, but that I
rejected for being too dangerous and fault-prone, was making the default HTTP
response value 0 (or any other invalid value) and, again, updating it to 200 if
it was still set to 0 (meaning that it hadn't been updated) before the headers
were about to be sent.
These changes involve much more significant modification for very little
additional benefit. The only case where they would improve the patch code is if
you set the HTTP code to some number, and then set the HTTP code back to 200,
and then sent a Location or similar header; you might expect it not to change
(because you've explicitly set it), but it would change (because it's currently
200, and that's the only condition that is checked).
(Also, the code on lines 665-666 of the original is redundant in the current
code because it would always be performed again at 752).
Please note that I am not necessarily saying that I think this patch should be
applied. In fact, after reading the source code, I think that - if anything -
my complaint really should simply be a documentation bug (ie; that setting a
Status header, last, is the preferred method of setting the response code, and
clarifications related to the correct use of http_response_code).
(Should have read the source code first, I guess. For example, it's now
painfully clear that PHP follows RFC 3875 as closely as possible).
Thank you for your consideration.
[2010-05-20 09:17:43] m...@php.net
Heh, you're quite patient either ;)
I think the most SAPI-portable way to set the HTTP status is:
header("Status: NNN", true, NNN);
Still, special headers like Location and WWW-Authenticate might override it
again, so it's best to set the HTTP status at last.
If you want to know more about the "hack", visit sapi_header_op() in main/SAPI.c
Cheers
PS: patches are always welcome, even if the just cause a discussion without
following changes
[2010-05-20 08:51:06] theimp at iinet dot net dot au
> header("HTTP/1.1 XXX") is just a hack
I did not realize this. So does that mean that, per RFC 3875, we're only
supposed to set the Status header and hope that the server does what we expect?
The documentation specifically lists this "hack" as the correct way to supply
the Status-Line and, therefore, the Response Code. But I'm not going to argue
with you about this.
> I see no hard reason to introduce other hacks to support a hack in the first
> place.
Well, that's fair enough.
> You are writing *pages*
I apologize. I tend to use far more words than I have to, in anticipation of
explaining myself poorly otherwise. I will try to be more concise. Many of the
details I felt were essential for understanding how the fix SHOULD be handled,
distinct from my personal preferences.
> about code that's *years* old and worked that way for a long long time, and
> there's very little chance to become that changed.
I understand from this, that you do not want to fix this in the way I have
Req #53358 [Opn->Csd]: API queries in php.ini
Edit report at https://bugs.php.net/bug.php?id=53358&edit=1 ID: 53358 Updated by: m...@php.net Reported by:pophal at tubit dot tu-berlin dot de Summary:API queries in php.ini -Status: Open +Status: Closed Type: Feature/Change Request Package:PHP options/info functions PHP Version:* -Assigned To: +Assigned To:mike Block user comment: N Private report: N New Comment: We already have SAPI INIs. Previous Comments: [2010-11-19 17:47:53] pophal at tubit dot tu-berlin dot de Description: I would rather appreciate a php ini section analogous to [HOST=] querying the SAPI, e.g. [SAPI=CLI] extension = php-gtk2.so in order to prevent the extension from being loaded when PHP is running as apache module or cgi. This would be helpful for distributions with like php.ini regardless of SAPI, in contrast to debian with its API-depending php.ini location. A workaround is a modified shebang line: #!/usr/bin/php -d extension=php_gtk2.so but this cannot be considered a good solution. Maybe this is not only php-gtk related. -- Edit this bug report at https://bugs.php.net/bug.php?id=53358&edit=1
Bug #54114 [Opn->Nab]: Output Buffer Dumps Data On Error
Edit report at https://bugs.php.net/bug.php?id=54114&edit=1
ID: 54114
Updated by: m...@php.net
Reported by:danhstevens at gmail dot com
Summary:Output Buffer Dumps Data On Error
-Status: Open
+Status: Not a bug
Type: Bug
Package:Output Control
Operating System: all
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
I'm not sure why this should be security related?
Why even output security sensitive information at all?
Previous Comments:
[2011-08-17 13:44:19] nicolas dot grekas+php at gmail dot com
Here is an other example that can't be workaround using danhstevens' technique:
[2011-03-10 19:41:28] danhstevens at gmail dot com
I've found a viable work-around for this bug (although a patch of the core
would still be ideal so people don't discover this potential security issue the
hard-way).
By registering the following shutdown handler before any output buffering the
dump of data can be prevented:
1)
{
//Prevent data in buffer from dumping
ob_end_clean();
}
}
register_shutdown_function('shutdown_fn');
Now when using the examples above that normally cause the buffer to dump to the
client the buffer data is disposed of. Of course, this can be extended to use
ob_get_contents and redirect the data to file or other means if necessary. This
approach is working for me (on PHP 5.3.5).
~Dan
[2011-03-06 16:51:52] neweracracker at gmail dot com
I've managed to reproduce this in Windows 7 running php 5.2.17 (with
php.ini-dist) and php 5.3.5 (with php.ini-development).
Here is my test script:
I've reported this as bug #54174 which got closed due being a dupe of this one
so I am leaving this comment here for reference purposes.
Regards,
NewEraCracker.
[2011-02-28 21:40:36] danhstevens at gmail dot com
Hi Rasmus,
I was still able to create the problem by calling on a non-existing class to
create a fatal error. Here is a variation of your code:
function eh($errno, $errstr, $errfile, $errline) {
$contents = ob_get_contents();
ob_end_clean();
echo "Error: $errno, $errstr, $errfile, $errline\n";
}
set_error_handler('eh');
ob_start();
echo 123;
nonExistantClass::nonExistantMethod();
echo "After error\n";
Output is:
123
Fatal error: Class 'nonExistantClass' not found in ...
Hopefully the above should more accurately illustrate the issue.
[2011-02-28 19:37:32] ras...@php.net
I am unable to reproduce this. My test script:
https://bugs.php.net/bug.php?id=54114
--
Edit this bug report at https://bugs.php.net/bug.php?id=54114&edit=1
Bug #61450 [Opn]: oci8, open ldap not working
Edit report at https://bugs.php.net/bug.php?id=61450&edit=1
ID: 61450
Updated by: m...@php.net
Reported by:pratheeshrajan18 at gmail dot com
Summary:oci8, open ldap not working
Status: Open
Type: Bug
Package:LDAP related
Operating System: Linux
PHP Version:trunk-SVN-2012-03-20 (SVN)
-Assigned To:
+Assigned To:sixd
Block user comment: N
Private report: N
New Comment:
Hi Chris, could you have a quick look on this PR, please?
Previous Comments:
[2012-03-24 01:56:07] s...@php.net
The best solution is to build PHP without OCI8, and then build OCI8 as a shared
extension.
There are hack solutions that may or may not work like editing Makefile,
changing INCLUDES to remove the -I Oracle include directory, and adding that -I
option explicitly to every oci8*.c file.
Also see the patch https://github.com/cjbj/php-
src/commit/68b1abcd789711586c481feb12b985e5807ebeaa
[2012-03-20 10:14:17] pratheeshrajan18 at gmail dot com
changed to right package
[2012-03-20 10:10:18] pratheeshrajan18 at gmail dot com
Description:
ldap functionality is not working when i configure ldap and oci8 together.
I am getting "Out of memory" error while trying ldap. But, when i disabled
oci8, it worked well. Could some one help please..
My configuration looks like
'./configure' '--with-apxs2=/appl/apache3/bin/apxs' '--with-mysql=/appl/mysql/'
'--with-zlib' '--prefix=/appl/php5.2.9' '--enable-sockets' '--with-ldap'
'--with-oci8=instantclient,/usr/lib/oracle/11.1/client64/lib/'
'--enable-mbstring' '--with-mysqli' '--with-xmlrpc' '--with-libxml-dir'
'--with-openssl' '--with-pcre-dir' '--with-pspell' '--enable-soap'
'--with-xmlrpc' '--with-curl' '--enable-exif' '--with-gd'
I tried changing the order of ldap and oci8 in the config, that also didn't
work for me.
All thoughts welcome
Thanks,
Prats
Test script:
---
Sample code
---
ldap://ldap.example.com";;
$ldaprdn = "my user";
$ldappass = "my pass";
$ldap_conn = ldap_connect($ldapServer);
$ldapbind =ldap_bind($ldap_conn);
if($ldapbind) {
echo "success";
} else {
echo "LDAP-Errno: " . ldap_err2str(ldap_errno($ldap_conn)) . "\n";
echo "binding failed"; echo "";
Getting the ldap error no: 10.
Could any one have any idea ?
Thanks in advance :)
Prats.
--
Edit this bug report at https://bugs.php.net/bug.php?id=61450&edit=1
Bug #47786 [Asn->Fbk]: ldap_list get "Decoding error" on some specific searching attribute
Edit report at https://bugs.php.net/bug.php?id=47786&edit=1
ID: 47786
Updated by: m...@php.net
Reported by:tedc21thc at hotmail dot com
Summary:ldap_list get "Decoding error" on some specific
searching attribute
-Status: Assigned
+Status: Feedback
Type: Bug
Package:LDAP related
Operating System: FreeBSD 7.1
PHP Version:5.2.9
Block user comment: N
Private report: N
New Comment:
There's no difference in what PHP does for ldap_search and ldap_list, except
that ldap_lsit uses LDAP_SCOPE_ONELEVEL.
Previous Comments:
[2012-04-30 07:40:25] tedc21thc at hotmail dot com
please solve this problem for ldap_list(); ( see:#5433 for ldap_search(); )
[2010-12-24 10:41:38] tedc21thc at hotmail dot com
It seems be #5433 only fixed "ldap_search()" function,but not also fix
ldap_list() function.
please check again.
The problem is, it will get Decoding error (-4) when querying some OU and have
attributes.
When I get decoding error, and I use this function again with no argument
4(attributes), It will be fine.
samples:
When
$sr= @ldap_list($this->conn,$dn,$this->filter,$this->attrs);
ldap_errno($this->conn) sometimes will be -4
gets Decoding error, query fails.
Try use
$sr= @ldap_list($this->conn,$dn,$this->filter);
ldap_errno($this->conn) will be 0
and the data entries will be fine
[2010-12-24 10:31:38] tedc21thc at hotmail dot com
Hello there,
It seems be #5433 only fixed "ldap_search()" function,but not also fix
ldap_list() function.
please check again.
The problem is, it will get Decoding error (-4) when querying some OU and have
attributes.
When I get decoding error, and I use this function again with no argument
4(attributes), It will be fine.
samples:
When
$sr= @ldap_list($this->conn,$dn,$this->filter,$this->attrs);
ldap_errno($this->conn) sometimes will be -4
gets Decoding error, query fails.
Try use
$sr= @ldap_list($this->conn,$dn,$this->filter);
ldap_errno($this->conn) will be 0
and the data entries will be fine
[2009-04-08 01:00:00] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2009-04-01 01:53:45] tedc21thc at hotmail dot com
the problem is when I change the searching attribute from
("cn","mail","proxyaddresses","ou")
to any other
like... ("mail","cn","proxyaddresses","ou") <- only switching sorting
or... ("cn","mail","proxyaddresses","ou","something") <- add something or
remove something
or whatever
the result of ""LDAP_ERROR($ds)"" become success,
and I can get values from
$info = ldap_get_entries($ds, $sr);
and following steps.
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
https://bugs.php.net/bug.php?id=47786
--
Edit this bug report at https://bugs.php.net/bug.php?id=47786&edit=1
Bug #51638 [Opn->Fbk]: LDAP and Referrals
Edit report at https://bugs.php.net/bug.php?id=51638&edit=1
ID: 51638
Updated by: m...@php.net
Reported by:marco at forgetaboutit dot net
Summary:LDAP and Referrals
-Status: Open
+Status: Feedback
Type: Bug
Package:LDAP related
Operating System: ALL
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
What LDAP library do you use? Does it support referrals?
Previous Comments:
[2011-02-26 20:19:04] marco at forgetaboutit dot net
I have now spent quite a lot of time working on this issue, and looking at
tcpdumps it is very clear that there are major issues in the way php handles
add, modify and delete referrals. I believe this is due to the fact that the
tests used to validate the code are also wrong, so the code is believed to be
good, when it isn't. I will be submitting an alternative way of doing referrals
by switching off the php method and doing it with three new functions which I
will post on the ldap_set_rebind_proc documentation page once I know it is at
least working. I do not have enough skills to work on php source code but would
be more than happy to assist a programmer with little or no ldap knowledge if
that would help.
[2010-10-23 15:26:14] ka...@php.net
After reviewing this bug some more, it looks more to me like its an actual
issue in the ldap extension in PHP, so moving it to that category where
hopefully one of the maintainers can pick it up and decide if its indeed an
issue in the ldap extension or lacking documentation.
[2010-07-20 15:40:35] art dot vanscheppingen at spilgames dot com
We have the exact same problem.
Referrals do work correctly using the cli ldapmodify and with the exact same
setup it doesn't work under PHP.
I tried setting the LDAP_OPT_REFERRALS to either 1, LDAP_OPT_ON and true, but
neither of them resulted in anything else than the default -1. Setting the
value to 0 does have effect though, but doesn't do anything either.
I set the LDAP server to a read only server, but that resulted in a LDAP error.
[2010-05-21 17:54:05] marco at forgetaboutit dot net
Doing some monitoring with TCPDUMP, I can confirm that the local LDAP server is
returning the correct referral information, and then the web server is
performing a DNS lookup on the ldap referral URL. Then it would seem that PHP
just tries the localhost again without running the procedure specified in
ldap_set_rebind_proc.
[2010-04-22 19:07:20] marco at forgetaboutit dot net
Description:
I am trying to get a php application to follow ldap referrals, specifically
when the local server is a slave, and is used as a read-only server for
performance reasons, but has to write to a master server in order to add,
modify or delete records.
As far as I can tell all I need are three things.
A) Set LDAP_OPT_REFERRALS to 1 using ldap_set_options()
B) Set a callback function using ldap_set_rebind_proc()
C) Create a very simple rebind function.
The problem is that there is no documentation on the subject. For example, when
I check LDAP_OPTS_REFERRALS using ldap_get_options(), I get an answer of either
0 (when I set it to 0 or false), and an answer of -1 (minus or dash 1) for any
other setting, including 1 and TRUE, and it appears that the callback function
isn't called.
If someone can explain how it is supposed to work enough for me to get it
working, I am happy to provide documentation / examples
Test script:
---
ldap_set_option($LDAP_CON, LDAP_OPT_REFERRALS, 1);
ldap_set_rebind_proc($LDAP_CON, rebind_on_referral);
...
function rebind_on_referral ($link_id, $ldap_url) {
$binddn = $_SESSION['ldapab']['binddn'];
$bindpw = $_SESSION['ldapab']['password'];
if (!ldap_bind($link_id,$binddn,$bindpw)) return 1; // Error
else return 0; // Success
}
Expected result:
callback function should be called, application should rebind to new ldap
server and user should notice nothing
Actual result:
--
PHP appears to ignore the referral and ldap_error returns a "referral" message.
--
Edit this bug report at https://bugs.php.net/bug.php?id=51638&edit=1
Bug #60614 [Opn->Nab]: Rebinding always results in false return from bind()
Edit report at https://bugs.php.net/bug.php?id=60614&edit=1
ID: 60614
Updated by: m...@php.net
Reported by:david dot kit at cookmedical dot com
Summary:Rebinding always results in false return from bind()
-Status: Open
+Status: Not a bug
Type: Bug
Package:LDAP related
Operating System: Windows XP Pro SP3
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
ldap_unbind/ldap_close are jsut aliases.
Previous Comments:
[2011-12-28 04:42:59] david dot kit at cookmedical dot com
Description:
---
>From manual page: http://www.php.net/function.ldap-bind#refsect1-function.ldap-
bind-description
---
I reproduced a problem where connecting to an LDAP server, and then binding to
an
address I know to exist and work will perform perfectly.
Within the same script, following an unbind (as I don't need the connection to
be
binded any more), using ldap_bind(..) again [even the same user and password as
the original] would result in a fail.
Test script:
---
// Assume variables all set in working order below...
$ldapconn = ldap_connect($ldaphost, $ldapport) or die("Could Not Connect to
$ldaphost");
$ldapbind = ldap_bind($ldapconn, $ldaprdn, $ldappass);
// bind successful
ldap_unbind($ldapconn);
$ldapbind = ldap_bind($ldapconn, $ldaprdn, $ldappass);
// second bind unsuccessful!?
ldap_close($ldapconn);
// close ldap connection
Expected result:
after unbind, the bind function will work normally
Actual result:
--
after unbind, bind function always fails.
if initial bind has not been unbinded, then subsequent bind (even for
same/different user) will work correctly.
--
Edit this bug report at https://bugs.php.net/bug.php?id=60614&edit=1
Bug #64392 [Opn->Fbk]: ldap_search() fails on base64-encoded entries
Edit report at https://bugs.php.net/bug.php?id=64392&edit=1 ID: 64392 Updated by: m...@php.net Reported by:russ at bluecows dot com Summary:ldap_search() fails on base64-encoded entries -Status: Open +Status: Feedback Type: Bug Package:LDAP related Operating System: Linux PHP Version:Irrelevant Block user comment: N Private report: N New Comment: Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. Previous Comments: [2013-03-08 15:53:22] russ at bluecows dot com Description: When using the ldap_search() function to query data from an LDAP database, it would appear that base64-encoded attributes are not decoded before running the search pattern against them. Based on the code snippets below, if the first search is run, no results are returned, even if a DN in the search tree has a postalAddress attribute which matches the given search string. If the second search is run, results are returned, indicating the search can check to see if the attribute exists at all, but the text-based search string is being checked against a base64-encoded attribute. It would appear that ldap_get_entries() decodes base64-encoded attributes, because the output of $entries, when it is not NULL, will show postalAddress as text. In order for ldap_search() to work properly, it should decode base64-encoded attributes before attempting to run the search against them. Test script: --- Failed test: $search = ldap_search( $ldapHandle, $ldapBaseDn, "(postaladdress=*165 Main*)" ); $entries = ldap_get_entries( $ldapHandle, $search ); Successful test: $search = ldap_search( $ldapHandle, $ldapBaseDn, "(postaladdress=*)" ); $entries = ldap_get_entries( $ldapHandle, $search ); Expected result: In the failed test example, I would expect $entries to contain a list of LDAP DNs and associated attributes where the postalAddress attribute matches the search parameter. Currently, it does not. Searches against non-base64-encoded attributes such as mail or telephoneNumber work as expected. Actual result: -- When the failed test example is run, $entries is empty because no matches are returned from the ldap_search(). -- Edit this bug report at https://bugs.php.net/bug.php?id=64392&edit=1
Bug #63299 [Opn->Nab]: call to ldap_search returns null
Edit report at https://bugs.php.net/bug.php?id=63299&edit=1
ID: 63299
Updated by: m...@php.net
Reported by:php at monona dot us
Summary:call to ldap_search returns null
-Status: Open
+Status: Not a bug
Type: Bug
Package:LDAP related
Operating System: Windows
PHP Version:5.3.17
Block user comment: N
Private report: N
New Comment:
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.
Remove the error suppression operator (@) and you'll most probably see an error
message about wrong function arguments.
Previous Comments:
[2012-10-18 05:36:47] php at monona dot us
Description:
---
>From manual page:
>http://www.php.net/function.ldap-search#refsect1-function.ldap-search-returnvalues
---
The documentation for function ldap_search says that it will either return a
resource or it will return a boolean false.
I have successfully bound to a microsoft Active Directory using ldap_connect
and ldap_bind. When I call ldap_search with a null for the forth
parameter($attributes) it returns a null while setting ldap_error() to "Sucess"
and ldap_errno() to zero.
The reason for passing a null for $attributes is so that I can explicity set a
limit using the sixth parameter ($sizelimit) and because I want everything
passed back, as if I had called ldap_search with only three parameters.
Another factor that probably contributes to creating this bug is that if I make
the call to ldap_search with just 3 paramters, it returns false with error set
to "Operations error" and errno set to 1 so there is obviously something else
wrong with the search.
I would prefer that either this condition return false and a specific error
message if there is something about the null $attributes that is an error or
that it return false/1/Operations error because that error is in fact still
true or that the documentation be updated to reflect when/why this function can
return null/o/success when in fact there is nothing successful about the call.
Test script:
---
ldap://xx');
ldap_set_option($ad, LDAP_OPT_PROTOCOL_VERSION, 3);
ldap_set_option($ad, LDAP_OPT_REFERRALS, 0);
ldap_bind($ad);
// replace xx etc. with your base DN
$result=@ldap_search($ad,'dc=xx,dc=com','(objectClass=*)',null,1,10);
if(!$result){
die('Could not search AD because '.ldap_error($ad).'('.ldap_errno($ad).')');
}
ldap_unbind($ad);
?>
Expected result:
return false
ldap_error() returns 'Operation error'
ldap_error() errno=1
or
return false
ldap_error() returns 'Some message about invalid $attributes parameter'
ldap_errno() returnd unique error number for above
Actual result:
--
Return value of NULL
ldap_error() returns 'Success'
ldap_errno() returns 0
--
Edit this bug report at https://bugs.php.net/bug.php?id=63299&edit=1
Req #51579 [Opn->Fbk]: ob_gzhandler/header("304") incompatibility
Edit report at https://bugs.php.net/bug.php?id=51579&edit=1
ID: 51579
Updated by: m...@php.net
Reported by:boris at povolnam dot ru
Summary:ob_gzhandler/header("304") incompatibility
-Status: Open
+Status: Feedback
Type: Feature/Change Request
Package:Unknown/Other Function
Operating System: irrelevant
PHP Version:5.2.13
-Assigned To:
+Assigned To:mike
Block user comment: N
Private report: N
New Comment:
Please try a newer PHP version, though, usually, your web server should prevent
sending a body with 304 responses.
Previous Comments:
[2010-12-10 16:36:30] roan dot kattouw at gmail dot com
Clarification: the HTTP spec requires 304 responses be empty, and Firefox is
very particular about that. But ob_gzhandler gzips even empty responses, and
gzipping the empty string does not return the empty string (GZIP header, at
least).
Proposed solution: if there was no output (empty buffer), do not compress and
do not send Content-Encoding:gzip
[2010-04-17 01:22:02] boris at povolnam dot ru
Description:
test script below will produce a response with not empty body (it will contain
gzip stream header) which breaks the W3C standart that requires 304 response to
have empty body.
The idea was to speed up things with compression and leveraging client side
caching, but end up firefox (v.3.6.3) prepending with that body some of
conseqent responces (css file in my case, which broken styles rendering - that
was really really hard to find - i just coudn't understand why my server
returns corrupted file and only to firefox)
Test script:
---
Expected result:
ob_gzhandler() to look into response headers and wipe out buffer and disable
compression if 304 is set. Cause it's a subtle thing about 304 header, its body
and the way ob_gzhandler() works and others can run into same problem while
trying to speed up website as compression and client-side caching are 2 main
things to do.
--
Edit this bug report at https://bugs.php.net/bug.php?id=51579&edit=1
Bug #61728 [Ver->Csd]: PHP crash when calling ob_start in session_write
Edit report at https://bugs.php.net/bug.php?id=61728&edit=1 ID: 61728 Updated by: m...@php.net Reported by:frederik_php at vanrenterghem dot biz Summary:PHP crash when calling ob_start in session_write -Status: Verified +Status: Closed Type: Bug Package:Reproducible crash Operating System: Linux Debian Wheezy PHP Version:5.4.0 Assigned To:laruence Block user comment: N Private report: N New Comment: Thank you for your bug report. This issue has already been fixed in the latest released version of PHP, which you can download at http://www.php.net/downloads.php Previous Comments: [2012-04-16 11:19:10] larue...@php.net change the summary [2012-04-14 17:21:22] larue...@php.net assign to me, since I have made a try to fix it. will close this after confirm that fix is okey. [2012-04-14 17:18:02] larue...@php.net Automatic comment on behalf of laruence Revision: http://git.php.net/?p=php-src.git;a=commit;h=3b42f184cdcf512fdc1f944052bfa296f17a035f Log: Fixed bug #61728 (php-fpm SIGSEGV running friendica on nginx) [2012-04-14 17:16:58] larue...@php.net Automatic comment on behalf of laruence Revision: http://git.php.net/?p=php-src.git;a=commit;h=3b42f184cdcf512fdc1f944052bfa296f17a035f Log: Fixed bug #61728 (php-fpm SIGSEGV running friendica on nginx) [2012-04-14 16:59:05] larue...@php.net if you try to start a user output handler in session_write. then it will crash. I have attach a simple reproduce script. and also made a simple fix. 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 https://bugs.php.net/bug.php?id=61728 -- Edit this bug report at https://bugs.php.net/bug.php?id=61728&edit=1
Req #42132 [Opn->Wfx]: suggest a fix for global object got destructed in output buffer handler
Edit report at https://bugs.php.net/bug.php?id=42132&edit=1 ID: 42132 Updated by: m...@php.net Reported by:xuefer at gmail dot com Summary:suggest a fix for global object got destructed in output buffer handler -Status: Open +Status: Wont fix Type: Feature/Change Request -Package:Feature/Change Request +Package:*General Issues Operating System: gentoo linux PHP Version:5CVS-2007-07-28 (CVS) Block user comment: N Private report: N New Comment: http://3v4l.org/2ZsYF Previous Comments: [2007-07-29 23:41:10] j...@php.net See also bug #39546 and bug #39629 [2007-07-28 14:30:02] xuefer at gmail dot com Description: it seems that the implicit ob_end_flush() is called after object destructions. uncomment any ONE of the comments gives "okay". but this is not the official trick that supported by php. the php bug system suggest me this bug is by design in #39546 #39629 etc. there's many register_xxx arround my php files, which install data into a global object, and the output buffer handler will inject the data into the output in the correct place. if this bug is not fixed, the only way i can do is to rewrite the object into array/functions anyway, i have a suggested fix to change the work flow a bit: 1. flush and pop all OBs but leave 1 top OB on shutdown 2. destruct objects 3. flush the last OB if there's any no matter if this bug is gonna be fixed, there shall be a page that give explanation and work arround to this issue. Reproduce code: --- Expected result: okay Actual result: -- oops -- Edit this bug report at https://bugs.php.net/bug.php?id=42132&edit=1
Bug #65416 [Opn->Fbk]: output buffering autostart setting php.ini
Edit report at https://bugs.php.net/bug.php?id=65416&edit=1 ID: 65416 Updated by: m...@php.net Reported by:jwestbrook at gmail dot com Summary:output buffering autostart setting php.ini -Status: Open +Status: Feedback Type: Bug Package:Output Control Operating System: linux 64bit AWS ami PHP Version:5.4.17 Block user comment: N Private report: N New Comment: Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. Previous Comments: [2013-08-27 00:42:36] jwestbrook at gmail dot com Extensions string(4) "Core" [1]=> string(4) "date" [2]=> string(4) "ereg" [3]=> string(6) "libxml" [4]=> string(7) "openssl" [5]=> string(4) "pcre" [6]=> string(4) "zlib" [7]=> string(3) "bz2" [8]=> string(8) "calendar" [9]=> string(5) "ctype" [10]=> string(4) "hash" [11]=> string(6) "filter" [12]=> string(3) "ftp" [13]=> string(7) "gettext" [14]=> string(3) "gmp" [15]=> string(3) "SPL" [16]=> string(5) "iconv" [17]=> string(10) "Reflection" [18]=> string(7) "session" [19]=> string(8) "standard" [20]=> string(5) "shmop" [21]=> string(9) "SimpleXML" [22]=> string(7) "sockets" [23]=> string(8) "mbstring" [24]=> string(9) "tokenizer" [25]=> string(3) "xml" [26]=> string(14) "apache2handler" [27]=> string(7) "gearman" [28]=> string(4) "http" [29]=> string(4) "ssh2" [30]=> string(4) "curl" [31]=> string(3) "dom" [32]=> string(8) "fileinfo" [33]=> string(2) "gd" [34]=> string(8) "igbinary" [35]=> string(4) "json" [36]=> string(4) "exif" [37]=> string(6) "mcrypt" [38]=> string(9) "memcached" [39]=> string(7) "mysqlnd" [40]=> string(5) "mysql" [41]=> string(6) "mysqli" [42]=> string(8) "newrelic" [43]=> string(3) "PDO" [44]=> string(9) "pdo_mysql" [45]=> string(10) "pdo_sqlite" [46]=> string(4) "Phar" [47]=> string(5) "posix" [48]=> string(4) "snmp" [49]=> string(4) "soap" [50]=> string(7) "sqlite3" [51]=> string(7) "sysvmsg" [52]=> string(7) "sysvsem" [53]=> string(7) "sysvshm" [54]=> string(4) "wddx" [55]=> string(9) "xmlreader" [56]=> string(9) "xmlwriter" [57]=> string(3) "xsl" [58]=> string(3) "zip" [59]=> string(5) "mhash" [60]=> string(12) "Zend OPcache" } string(14) "apache2handler" 12 requests where I was able to note that the output buffer failed out of 142 requests to that specific script. As a whole I average 150,000 PHP requests per day [2013-08-26 22:45:23] yohg...@php.net I guess there is some kind of memory problem. What modules are loaded in your web server and SAPI? or paste phpinfo() output. > at least 12 times a day PHP fails to start the output buffer and I get the error shown. How many requests a day you have? [2013-08-26 21:35:48] jwestbrook at gmail dot com @mike at php.net Yes that is the bug I'm reporting - the php.ini setting does not start the output buffer on every request. [2013-08-19 22:19:57] m...@php.net Looks like when this is logged, there actually is no output buffer active, so ob_get_length() returns false. [2013-08-19 22:07:01] jwestbrook at gmail dot com I also tried the settings of On and 1. I also understand that #!/usr/bin/php means nothing to output buffering but is output that I want to capture if the php file is being run from a browser and discard. >From what I understand that is not how the output buffering works. The way I >understand it the output buffer fills then dumps everything when it is full. In this instance before the output buffer fills I want to discard the first 15 characters because it will corrupt any binary files that the browser is trying to download. Based on the test script attached ob_get_length() should ALWAYS return 15 characters - however at least 12 times a day PHP fails to start the output buffer and I get the error shown. 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 https://bugs.php.net/bug.php?id=65416 -- Edit this bug report at https://bugs.php.net/bug.php?id=65416&edit=1
Bug #65751 [Opn->Nab]: isset() and empty() hides illegal offset warning
Edit report at https://bugs.php.net/bug.php?id=65751&edit=1 ID: 65751 Updated by: m...@php.net Reported by:anton dot polonskiy at gmail dot com Summary:isset() and empty() hides illegal offset warning -Status: Open +Status: Not a bug Type: Bug Package:*General Issues Operating System: Ubuntu 13.04 PHP Version:Irrelevant Block user comment: N Private report: N New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Previous Comments: [2013-09-24 11:03:26] anton dot polonskiy at gmail dot com Description: Manual says: "As of PHP 5.4 string offsets have to either be integers or integer-like strings, otherwise a warning will be thrown. Previously an offset like "foo" was silently cast to 0." That warning will suppressed by wrapping variable in isset() or empty(); http://3v4l.org/MEldp Test script: --- https://bugs.php.net/bug.php?id=65751&edit=1
Req #44522 [Opn->Csd]: http upload max_limits and file above 2GB
Edit report at https://bugs.php.net/bug.php?id=44522&edit=1 ID: 44522 Updated by: m...@php.net Reported by:mail2lv at yahoo dot com Summary:http upload max_limits and file above 2GB -Status: Open +Status: Closed Type: Feature/Change Request Package:*Web Server problem Operating System: All PHP Version:5.2.5 -Assigned To: +Assigned To:mike Block user comment: N Private report: N New Comment: The fix for this bug has been committed. 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/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. Fixed in master on x86_64 Previous Comments: [2013-07-01 10:32:22] lang at b1-systems dot de Newest Mailing List feedback applied. Pull Request attached. Please pull or comment in github or here. [2013-04-19 20:21:34] azet at azet dot org Could you please add this patch? It MIGHT make seem PHP less an embarrassing language than it is already. Sincerely, The Internet [2013-04-19 09:37:22] scroogie at scroogie dot de In my opinion this is quite an issue. We faced it at an intranet side yesterday. Due to the cast to int at https://github.com/php/php-src/blob/master/main/rfc1867.c#L901 it also has weird side effects, like setting 4G will equal 0 and disable the size check (see https://github.com/php/php-src/blob/master/main/rfc1867.c#L1031), 5G equal 1G etc. [2012-03-26 04:02:16] jason at infininull dot com I have re-rolled the patch against HEAD (b4d078f18c950a4bf7e136443586e348bd54f40c) and attached it to this request. [2012-03-24 18:42:45] jason at infininull dot com I was recently bitten by this bug too. The patch needed a little updating for 11.04 and I also found a couple of other issues. 1) Uploads only work if upload_max_filesize = 0 and 2) The $_FILES[*]['size'] value is an overflowed integer. The attached patch fixes these issues. I am currently in the process of re-rolling the patch against HEAD on master to get this in to upstream. 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 https://bugs.php.net/bug.php?id=44522 -- Edit this bug report at https://bugs.php.net/bug.php?id=44522&edit=1
Bug #65499 [Opn->Fbk]: json_decode reports invalid literal as valid JSON
Edit report at https://bugs.php.net/bug.php?id=65499&edit=1 ID: 65499 Updated by: m...@php.net Reported by:m dot kurzyna at crystalpoint dot pl Summary:json_decode reports invalid literal as valid JSON -Status: Open +Status: Feedback Type: Bug Package:JSON related Operating System: Linux PHP Version:5.5.2 Block user comment: N Private report: N New Comment: Cannot reproduce. Do you use Debian/Ubuntu/Fedora? Report there. Previous Comments: [2013-08-22 08:15:54] m dot kurzyna at crystalpoint dot pl To be more precise - introduced regression casts the string to integer so technically it takes all first digits just like (int)"123abc" would do. [2013-08-22 08:00:25] m dot kurzyna at crystalpoint dot pl Description: There is a regression in json_decode starting with PHP5.5 (5.4.x works as expected). json_decode() now treats literals staring with an integer as valid JSON consisting only of the first character. Test script: --- https://bugs.php.net/bug.php?id=65499&edit=1
Bug #63642 [Asn->Nab]: No "out of memory" error during ->fetchAll() from PostgreSQL
Edit report at https://bugs.php.net/bug.php?id=63642&edit=1
ID: 63642
Updated by: m...@php.net
Reported by:amex at bucksvsbytes dot com
Summary:No "out of memory" error during ->fetchAll() from
PostgreSQL
-Status: Assigned
+Status: Not a bug
Type: Bug
Package:PDO related
Operating System: Ubuntu
PHP Version:5.3.19
Assigned To:willfitch
Block user comment: N
Private report: N
New Comment:
Cannot reproduce. This is probably your kernel OOM killer tricking you.
cli -d error_reporting=-1 -d memory_limit=5M -r '$pdo = new
PDO("pgsql:user=phptest dbname=phptest"); $stm = $pdo->query("select
repeat(\x27a\x27, 5*1024*1025) as data"); var_dump($stm->fetchAll());'
Fatal error: Allowed memory size of 5242880 bytes exhausted at
/home/mike/src/php-5.4/ext/pdo/pdo_stmt.c:641 (tried to allocate 5248001 bytes)
in Command line code on line 1
Previous Comments:
[2012-12-19 00:09:58] amex at bucksvsbytes dot com
Yes, my PHP development system displays every error, warning, and notice on
screen.
[2012-12-18 21:17:38] willfi...@php.net
Without looking into this too far, have you verified that
error_reporting/display_errors are set to levels that are sufficient to display
or
record this error?
[2012-11-29 00:25:41] amex at bucksvsbytes dot com
Description:
In PHP 5.3.10 and PostgreSQL 9.1, when executing PDOStatement::fetchAll(), if
the retrieved data busts the PHP memory limit, the script dies quietly, without
throwing an "out of memory" error.
Test script:
---
//ini_set('memory_limit','256M');
$dsn=;//appropriate Data Source Name string
$sql=;//any query that returns slightly more data than the PHP memory limit
allows (default limit is 128 MB on my server)
$db=new PDO($dsn);
$result=$db->query($sql);
$datarray=$result->fetchAll();//fetch all rows into an array
Expected result:
When fetchAll() retrieves too much data, the script dies quietly, instead of
throwing an "out of memory" error.
When I uncomment the first line, the script runs to completion, thus proving
that the quiet death was due to lack of memory.
The problem seems to relate to the postgresql driver, as the same thing happens
when I use pg_connect/pg_query/pg_fetch_all instead of PDO to get data from the
same query.
This is the only PHP "out of memory" condition I've ever seen where no error is
thrown.
--
Edit this bug report at https://bugs.php.net/bug.php?id=63642&edit=1
Bug #63631 [Fbk]: PDO_PGSQL: bindParam and bindValue not working
Edit report at https://bugs.php.net/bug.php?id=63631&edit=1 ID: 63631 Updated by: m...@php.net Reported by:mamatkazin at spb dot orw dot ru Summary:PDO_PGSQL: bindParam and bindValue not working Status: Feedback Type: Bug Package:PDO related Operating System: linux PHP Version:5.4.9 Block user comment: N Private report: N New Comment: 1.) Please provide a complete reproduce script. 2.) Now is that about PDO_PGSQL or PDO_ODBC? Your subject differs from the error message... Previous Comments: [2013-08-21 09:36:08] pretorian at km dot ru Test: version php 5.4.18 Code: $stmt=$dbh->prepare(âquery_with_param_?â); $stmt->bindParam(1, $param, PDO::PARAM_INT); // or bindValue $stmt->execute(); $result=$stmt->fetchAll(PDO::FETCH_NUM|PDO::FETCH_COLUMN); Error in log: (mod_fastcgi.c.2699) FastCGI-stderr: SQLSTATE[22P02]: Invalid text representation: 7 ERROR: invalid input syntax for integer: ""; Error while executing the query (SQLExecute[7] at /tmp/php-5.4.18/ext/pdo_odbc/odbc_stmt.c:254) [2013-08-20 12:52:00] m...@php.net Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. [2012-11-28 07:31:41] mamatkazin at spb dot orw dot ru Description: OS Linux, PHP 5.4.8 and 5.4.9, PostgreSQL 9.2.1, Probably, bindParam and bindValue not working. Code: $stmt=$dbh->prepare(âquery_with_param_?â); $stmt->bindParam(1, $param, PDO::PARAM_STR); // or bindValue $stmt->execute(); $result=$stmt->fetchAll(PDO::FETCH_NUM|PDO::FETCH_COLUMN); Expected result: $result - is not empty; Actual result: $result - empty Test script: --- $stmt=$dbh->prepare(âquery_with_param_?â); $stmt->bindParam(1, $param, PDO::PARAM_STR); // or bindValue $stmt->execute(); $result=$stmt->fetchAll(PDO::FETCH_NUM|PDO::FETCH_COLUMN); Expected result: $result - is not empty; Actual result: -- $result - empty -- Edit this bug report at https://bugs.php.net/bug.php?id=63631&edit=1
Bug #65439 [Opn->Nab]: Build fails when compiled
Edit report at https://bugs.php.net/bug.php?id=65439&edit=1 ID: 65439 Updated by: m...@php.net Reported by:me at umakantpatil dot com Summary:Build fails when compiled -Status: Open +Status: Not a bug Type: Bug Package:PHAR related Operating System: Ubuntu 12.10 PHP Version:5.5.1 Block user comment: N Private report: N New Comment: . Previous Comments: [2013-08-21 07:51:52] me at umakantpatil dot com This is not bug. Sorry for reporting. This was happening because of wrong file permissions. Please close/invalidate this ticket. [2013-08-12 14:10:51] me at umakantpatil dot com Description: When you compile PHP 5.5.1 version build fails with error. I have tried to create build from root user. I'm using maven 2.2.1 for building. I have done many previous versions but this version is somehow not working. Once I say mvn release:prepare it starts compiling PHP and midway it throws error. Details about libs, system are as follows:- OS:- Ubuntu 12.10. Lib:- open-ssl 1.0, bzip2 1.0.6, curl 7.26.0, libjpeg 6b, libpng 1.5.2, freetype 2.4.4, gmp 5.0.1, mhash 0.9.9.9, libmcrypt 2.5.8, tidy 2009-03-25, libiconv 1.14, libxslt 1.2.26, libxml2 2.7.8, get text 0.18, icu 4.8 Enabled:- --with-apxs2=/bin/apxs, --with-libxml-dir=, --disable-short-tags, --with-openssl=, --with-zlib, --with-bz2=, --with-curl=, --with-gd, --with-jpeg-dir=, --with-freetype-dir=, --with-png-dir=, --enable-gd-native-ttf, --with-gettext=, --with-gmp=, --with-mcrypt=, --with-mhash=, --with-tidy=, --with-xmlrpc, --with-iconv=, --with-xsl=, --with-zlib, --enable-bcmath, --enable-calendar, --enable-ftp, --enable-mbstring, --enable-posix=shared, --enable-soap, --enable-wddx, --enable-zip, --enable-exif, --enable-intl, --with-icu-dir=, --without-pear, --enable-zend-signals Expected result: Successful PHP build Actual result: -- [INFO] [INFO] Generating phar.php [INFO] [INFO] /bin/bash: /home/user/php/target/src/build/shtool: Permission denied [INFO] [INFO] /bin/bash: /home/user/php/target/src/build/shtool: Permission denied [INFO] [INFO] /bin/bash: -d: command not found [INFO] [INFO] make: *** [ext/phar/phar.php] Error 127 [INFO] [INFO] [INFO] [ERROR] BUILD ERROR [INFO] [INFO] [INFO] [INFO] make returned an exit value != 0. Aborting build; see command output above for more information. [INFO] [INFO] [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] [INFO] [INFO] Total time: 20 minutes 12 seconds [INFO] [INFO] Finished at: Mon Aug 12 06:32:09 PDT 2013 [INFO] [INFO] Final Memory: 40M/96M -- Edit this bug report at https://bugs.php.net/bug.php?id=65439&edit=1
Bug #44597 [Opn->Fbk]: [PATCH] Postgres driver does not prepare booleans correctly
Edit report at https://bugs.php.net/bug.php?id=44597&edit=1 ID: 44597 Updated by: m...@php.net Reported by:kenaniah at gmail dot com Summary:[PATCH] Postgres driver does not prepare booleans correctly -Status: Open +Status: Feedback Type: Bug Package:PDO related Operating System: Red Hat 4.1.1 PHP Version:5.2.6 Block user comment: N Private report: N New Comment: Please try using this snapshot: http://snaps.php.net/php5.4-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Seems to work correctly in recent versions. Previous Comments: [2010-10-12 12:20:14] ddebernardy at yahoo dot com I'm in agreement with the last commenter. The PGSQL driver handles booleans that are typecast as integers properly, but not the actual booleans. These really ought to work out of the box. [2009-10-05 06:08:33] kenaniah at gmail dot com *Sjoerd My apologies on the incorrect spelling. [2009-10-05 06:07:07] kenaniah at gmail dot com In response to sjored, I believe there is huge disagreement over that issue, and I can personally speak for many of my colleagues in saying that. While I understand the repercussions of the patch, I would also like to point out that the example cited depends on buggy functionality in the first place. For that reason alone, I humbly submit that such a case should not be considered when weighing the implementation of the patch. On the second point, I believe we have another difference of opinion. All DBMSs perform their own casting on query parameters to match internal data types. For example, certain DBs honor the *string* 'False' as a boolean value, whereas a simple boolean cast performed in PHP would result in the said parameter evaluating to TRUE. In addition, other transformations may be applied to a passed parameter based on localization, custom data types, complex data types, etc. which vary from vendor to vendor and schema to schema. The role of PDO should be to transparently forward parameters to queries via their respective PHP and PDO-recognized data types. Now concerning the third point: PHP is a loosely-typed language. There is beauty in being able to provide mixed parameters to functions. There is nothing wrong with allowing a "mixed" parameter to be passed to a query either. Most DBs operate perfectly fine when receiving mixed parameters, and rightfully throw an error when something is amiss. Passing 'True', TRUE, or 1 to a boolean database field is perfectly acceptable in many systems. And concerning your last statement: PHP should never under any circumstance attempt to think for the programmer. I expect a database abstraction layer to pass parameters along transparently *because* it is an abstraction layer. A programming language is not smarter than the one who implements it, and it is impossible to mitigate an error in logic. Rather, it is better for an error to be returned in order so that the erroneous logic be corrected, as their may be an even greater issue at hand. In closing, I believe that the implementation of a patch for this issue would be more inline with the general philosophy and design patterns that govern PHP than the current functionality today, to the point that I maintain my position that the current functionality is in fact buggy. I merely ask that PDO -- true to the form and function of an abstraction layer -- would pass parameters along in their respective data types without casting them to "string" of all things. I thank everyone who has participated in this issue thus far (especially sjored for the patch submitted), and am looking forward to this issue being resolved in an upcoming release. [2009-10-04 18:46:07] sjo...@php.net It is a bad idea to determine the PDO type from the PHP type. First, it would break existing scripts which assume false is cast to an empty string, like this: $a[] = strstr($foo, $bar); // may return false $pdo->execute($a); Secondly, the correct type to use is the type of the column, not the type of the PHP parameter. Consider the following query: SELECT * FROM foo WHERE a=? If a is a boolean, the parameter to execute() or bindBaram() should be converted to a boolean, no matter what the type of the passed parameter is. Finally, one of PHP features is that it dynamically changes types. The type of a variable should be transparent to the user. Therefore, the behavior of a function should not change when it is passed another type. To solve this, you should always specify the PDO type. Only the programmer knows which types the column i
Bug #64953 [Ana->Csd]: Postgres prepared statement positional parameter casting
Edit report at https://bugs.php.net/bug.php?id=64953&edit=1
ID: 64953
Updated by: m...@php.net
Reported by:goetas at lignano dot it
Summary:Postgres prepared statement positional parameter
casting
-Status: Analyzed
+Status: Closed
Type: Bug
Package:PDO related
Operating System: ubuntu 10.04
PHP Version:5.3.25
Block user comment: N
Private report: N
New Comment:
Automatic comment on behalf of mike
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=27c803aaed259f76a66db1278eea05f30a8ec956
Log: Fix bug #64953 (Postgres prepared statement positional parameter casting)
Previous Comments:
[2013-08-20 13:07:08] m...@php.net
The problem rather is, that PDO contains an SQL parser (or, erm, such) which
implements named parameters like ":argname". The result is then discovered by
people not only using MySQL: havoc.
[2013-05-31 09:46:44] goetas at lignano dot it
Description:
Using a prepared statement with positional parameters will produce unexpected
behaviour when casting these parameters.
Test script:
---
// pdo
$pdo = new \PDO("pgsql:host=localhost;dbname=db", "user", "pwd");
$pdo->setAttribute (\PDO::ATTR_ERRMODE, \PDO::ERRMODE_EXCEPTION);
$st = $pdo->prepare('SELECT ?::char as i');
$st->bindValue(1, '1');
$st->execute();
var_dump($st->fetch()); // return false
$st = $pdo->prepare('SELECT (?)::char as i');
$st->bindValue(1, '1');
$st->execute();
var_dump($st->fetch()); // return array(1) { ["i"]=> string(1) "1" }
// old pg extension
$dbconn = pg_connect("host=localhost dbname=superdpi user=postgres
password=df54tb70");
$result = pg_prepare($dbconn, "my_query", 'SELECT $1::char as i');
$result = pg_execute($dbconn, "my_query", array("1"));
var_dump(pg_fetch_assoc ( $result)); // return array(1) { ["i"]=> string(1) "1"
}
Expected result:
array(2) {
["i"]=>
string(1) "1"
[0]=>
string(1) "1"
}
array(2) {
["i"]=>
string(1) "1"
[0]=>
string(1) "1"
}
array(1) {
["i"]=>
string(1) "1"
}
Actual result:
--
bool(false)
array(2) {
["i"]=>
string(1) "1"
[0]=>
string(1) "1"
}
array(1) {
["i"]=>
string(1) "1"
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=64953&edit=1
