Bug #65581 [Opn-Csd]: stream_get_contents does not seek with a stream wrapper
Edit report at https://bugs.php.net/bug.php?id=65581edit=1
ID: 65581
Updated by: jpa...@php.net
Reported by:ivan dot enderlin at hoa-project dot net
Summary:stream_get_contents does not seek with a stream
wrapper
-Status: Open
+Status: Closed
Type: Bug
Package:*General Issues
PHP Version:master-Git-2013-08-29 (Git)
-Assigned To:
+Assigned To:jpauli
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
This is because your stream_seek() function does not return the right value.
stream_seek() should return TRUE if the seek has successed, you return the
value
of fseek(), which is 0 on success.
Additionally, you have to implement stream_tell() so that the underlying layer
can ask for it and know where the stream position is.
stream_tell() is called just after stream_seek() has successed, thus it is
needed, even if you never call ftell() on your own stream, the underlying layer
does.
Correct code is :
?php
class StreamWrapper {
protected $_stream = null;
public function stream_open ( $path, $mode, $options, $openedPath ) {
$this-_stream = fopen(__FILE__, $mode);
return true;
}
public function stream_seek ( $offset, $whence = SEEK_SET ) {
var_dump('seek to ' . $offset);
if (fseek($this-_stream, $offset, $whence) == 0) {
return true;
}
return false;
}
public function stream_tell()
{
return ftell($this-_stream);
}
public function stream_read ( $count ) {
return fread($this-_stream, $count);
}
public function stream_stat ( ) {
return fstat($this-_stream);
}
public function stream_eof ( ) {
return feof($this-_stream);
}
}
stream_wrapper_register('foo', 'StreamWrapper');
$a = fopen('foo://bar', 'rb');
var_dump(stream_get_contents($a, 30, 4));
Previous Comments:
[2013-08-29 08:40:49] ivan dot enderlin at hoa-project dot net
Oh also the bug disappears with:
fseek($a, 4);
stream_get_contents($a, 30);
[2013-08-29 08:28:08] ivan dot enderlin at hoa-project dot net
Description:
When calling stream_get_contents() with $offset = ftell() *through a stream
wrapper*, the internal pointer of the stream is moved but stream_get_contents()
throws an error: Failed to seek to position $offset in the stream.
While monitoring the source code (ext/standard/streamsfuncs.c, at line 404, no
kidding ;-)), it appears that it is a normal behaviour since seek_res is set to
-1 at line 426 (with the code bellow). I did not understand why (I looked at
php_stream_seek implementation but I was not able to understand).
Change fopen('foo://bar', 'rb') for fopen(__FILE__, 'rb') and the issue
disappears. That's why I think it is related to stream wrapper, but I cannot
ensure that.
Test script:
---
?php
class StreamWrapper {
protected $_stream = null;
public function stream_open ( $path, $mode, $options, $openedPath ) {
$this-_stream = fopen(__FILE__, $mode);
return true;
}
public function stream_seek ( $offset, $whence = SEEK_SET ) {
var_dump('seek to ' . $offset);
return fseek($this-_stream, $offset, $whence);
}
public function stream_read ( $count ) {
return fread($this-_stream, $count);
}
public function stream_stat ( ) {
return fstat($this-_stream);
}
public function stream_eof ( ) {
return feof($this-_stream);
}
}
stream_wrapper_register('foo', 'StreamWrapper');
$a = fopen('foo://bar', 'rb');
var_dump(stream_get_contents($a, 30, 4));
Expected result:
no error
Actual result:
--
error
--
Edit this bug report at https://bugs.php.net/bug.php?id=65581edit=1
Bug #53405 [Asn-Nab]: accessing the iterator inside a foreach loop leads to strange results
Edit report at https://bugs.php.net/bug.php?id=53405edit=1
ID: 53405
Updated by: jpa...@php.net
Reported by:jpa...@php.net
Summary:accessing the iterator inside a foreach loop leads
to strange results
-Status: Assigned
+Status: Not a bug
Type: Bug
Package:Scripting Engine problem
Operating System: *nix
PHP Version:5.3.3
Assigned To:dmitry
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.
Ok, I'm gonna add a doc hint.
Previous Comments:
[2013-04-09 10:10:25] dmi...@php.net
First off all mixing foreach() and reset/next/current is not a good idea.
In general the value of internal iterator pointer is undefined when using
foreach().
At second false is more expected value, than a.
The value b may be explained as well. The current() call in the foreach loop
separates the value of variable $a from the array used by foreach loop. So we
got two copies of arrays with different iterator positions.
I don't think we should try to fix it. It's better to add the note into
documentation about undefined behaviour in case of mixing foreach and
reset/next/current.
[2013-04-08 23:39:38] chris at clowerweb dot com
I actually experienced something last night during Wordpress development that I
believe to be related to this.
ul
?php
$posts = get_posts();
foreach($posts as $post) {
setup_postdata($post); ?
lia href=?php the_permalink(); ??php the_title(); ?/a/li
?php } ?
/ul
Somehow the foreach loop was manipulating a $post (not $posts) variable in
another
part of the script, causing post pages to display incorrect content.
[2010-11-25 18:38:12] jpa...@php.net
Description:
foreach() is supposed to work on a copy of the iternal iterator.
However, manipulating the iterator inside the foreach loop leads to very
strange results.
- Also try to print the result of current() inside the foreach loop in the 3
use cases provided. You'll see that the iterator is some kind of manipulated by
foreach
Test script:
---
$a = range('a','d');
foreach ($a as $v) { }
var_dump(current($a));
$a = range('a','d');
foreach ($a as $v) { current($a); }
var_dump(current($a));
$a = range('a','d');
foreach ($a as $v) { current($a); }
var_dump(current($a));
Expected result:
'a'
'a'
'a'
Actual result:
--
false
'b'
false
--
Edit this bug report at https://bugs.php.net/bug.php?id=53405edit=1
Bug #18556 [Csd]: Setting locale to 'tr_TR' lowercases class names
Edit report at https://bugs.php.net/bug.php?id=18556edit=1
ID: 18556
Updated by: jpa...@php.net
Reported by:spud at nothingness dot org
Summary:Setting locale to 'tr_TR' lowercases class names
Status: Closed
Type: Bug
Package:Scripting Engine problem
Operating System: Linux (RedHat 7.2)
PHP Version:5CVS, 4CVS (2005-10-04)
Assigned To:stas
Block user comment: N
Private report: N
New Comment:
So, to sum things up :
The bugs has only been fixed in 5.5 branch. It mainly uses a char map to lower
characters instead of relying on locale-aware (possibly buggy versions)
system's
libc.
You can find details with internal zend functions affected directly by reading
the source, here : http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_operators.c#45
Previous Comments:
[2012-09-13 19:19:14] s...@php.net
It looks like snaps is serving 5.4 under the name of php-trunk. Not sure why.
Could you submid a website bug for that and send me the bug ID?
In the meantime you could use github: https://github.com/php/php-src just use
the
zip file option and you could build it from there.
[2012-09-13 15:31:04] richlv at nakts dot net
thanks for the response.
$ wget http://snaps.php.net/php-trunk-201209131330.tar.gz
$ wget http://snaps.php.net/php-trunk-201209131330.tar.bz2
$ wget http://snaps.php.net/php-trunk-201209131330.tar.xz
$ for type in gz bz2 xz; do mkdir $type; (cd $type; tar -xf
../php-trunk-201209131330.tar.$type); done
$ grep PHP_VERSION {bz2,gz,xz}/php-trunk-201209131330/main/php_version.h
bz2/php-trunk-201209131330/main/php_version.h:#define PHP_VERSION 5.4.8-dev
gz/php-trunk-201209131330/main/php_version.h:#define PHP_VERSION 5.4.8-dev
xz/php-trunk-201209131330/main/php_version.h:#define PHP_VERSION 5.4.8-dev
is that ok for trunk snapshots then ?
[2012-09-10 06:22:46] s...@php.net
You should be using 5.5 (or master) branch of PHP. It is not fixed in 5.4 due
to necessities of binary APIs change which is not possible in stable version.
Trunk does not announce itself as 5.4 but as 5.5, so there must be some
mistake.
However if you feel very adventurous, you can take 5.5 commit (it's marked with
the bug #) and cherry-pick it into your 5.4 branch.
[2012-09-08 14:54:04] richlv at nakts dot net
hmm, i just tested trunk snapshot php-trunk-201209081330 which announces itself
as 5.4.8-dev
trying to use turkish locale still fails with :
Fatal error: Class 'CInput' not found
(there's uppercase I in the name)
what am i doing wrong ?
[2012-09-08 14:25:15] richlv at nakts dot net
which version is expected to have the fix ? looking at snapshots, is it trunk
only (thus php 5.5 or whichever will be the next version) ?
interesting bit - this bug was fixed just 9 days short of it's 10th birthday ;)
(submitted 2002-07-25, fixed 2012-07-16)
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=18556
--
Edit this bug report at https://bugs.php.net/bug.php?id=18556edit=1
Req #23955 [Opn]: setcookie(): max-age needed [to comply with rfc]
Edit report at https://bugs.php.net/bug.php?id=23955edit=1 ID: 23955 Updated by: jpa...@php.net Reported by:kruemelmonster at cookiecan dot de Summary:setcookie(): max-age needed [to comply with rfc] Status: Open Type: Feature/Change Request -Package:Feature/Change Request +Package:*General Issues PHP Version:4.3.2 Block user comment: N Private report: N New Comment: The timezone is not an issue as dates are GMT based anyway. However, the issue shows up when the client UA has a wrong local time set. Previous Comments: [2003-06-02 07:51:37] kruemelmonster at cookiecan dot de based on the discussion in #23835, I file here that the function setcookie() should include the missing paramenter 'max-age'. max-age is defined in: http://www.ietf.org/rfc/rfc2109.txt http://www.ietf.org/rfc/rfc2965.txt which both are referenced in the documentation of the setcookie() - func itself. max-age has become more and more important, because it removes the timezone-issue from the former way of timestamping cookie expiration dates. thanks for considering. - here's some detail taken from the rfc-specs: Max-Age=value OPTIONAL. The value of the Max-Age attribute is delta-seconds, the lifetime of the cookie in seconds, a decimal non-negative integer. To handle cached cookies correctly, a client SHOULD calculate the age of the cookie according to the age calculation rules in the HTTP/1.1 specification [RFC2616]. When the age is greater than delta-seconds seconds, the client SHOULD discard the cookie. A value of zero means the cookie SHOULD be discarded immediately. -- Edit this bug report at https://bugs.php.net/bug.php?id=23955edit=1
Bug #62653 [Opn]: unset($array[$float]) causes a crash
Edit report at https://bugs.php.net/bug.php?id=62653edit=1 ID: 62653 Updated by: jpa...@php.net Reported by:davidso1 at rose-hulman dot edu Summary:unset($array[$float]) causes a crash Status: Open Type: Bug -Package:Apache2 related +Package:Scripting Engine problem Operating System: Windows Server PHP Version:5.4.5 Block user comment: N Private report: N New Comment: Switch to Scripting Engine Problem as bug type Previous Comments: [2012-07-25 13:40:44] larue...@php.net I can no reproduce this on Linux redhat [2012-07-24 19:27:22] s...@php.net The testcase produces invalid reads writes in valgrind. [2012-07-24 16:16:05] davidso1 at rose-hulman dot edu Description: The test code crashes apache in the 5.4+ environment. $foo starts as a string, gets interpreted as a double but it isn't I guess. unset($array[(double) $foo]) works as expected Test script: --- $array = array(5=bar); $foo = 10.; // gettype($foo) = string $foo /= 2; //Makes $foo = 5 but still gettype($foo) = double unset($array[$foo]); print_r($array); Expected result: Array() Actual result: -- Error 101 (net::ERR_CONNECTION_RESET): The connection was reset. -- Edit this bug report at https://bugs.php.net/bug.php?id=62653edit=1
Bug #62616 [Ver]: ArrayIterator::count() from IteratorIterator instance gives Segmentation fault
Edit report at https://bugs.php.net/bug.php?id=62616edit=1 ID: 62616 Updated by: jpa...@php.net Reported by:zoeslam at gmail dot com Summary:ArrayIterator::count() from IteratorIterator instance gives Segmentation fault Status: Verified Type: Bug Package:SPL related Operating System: Ubuntu 12.04 PHP Version:5.4.5 Block user comment: N Private report: N New Comment: I can reproduce on 5.3.14 I can only reproduce calling the method directly. Calling count($ii) instead of $ii-count() wont segfault Previous Comments: [2012-07-20 12:54:55] f...@php.net BT #0 0x7fdfaf4221d8 in ?? () #1 0x00594a41 in spl_dual_it_free (intern=0x7fdfaf53fa20) at /opt/src/php-5.4.5/ext/spl/spl_iterators.c:1585 #2 spl_dual_it_dtor (_object=0x7fdfaf53fa20, handle=optimized out) at /opt/src/php-5.4.5/ext/spl/spl_iterators.c:2237 #3 0x006a7b20 in zend_objects_store_del_ref_by_handle_ex (handle=2, handlers=optimized out) at /opt/src/php-5.4.5/Zend/zend_objects_API.c:206 #4 0x006a7b63 in zend_objects_store_del_ref (zobject=0x7fdfaf53f990) at /opt/src/php-5.4.5/Zend/zend_objects_API.c:172 #5 0x00674082 in _zval_dtor (zvalue=optimized out) at /opt/src/php- 5.4.5/Zend/zend_variables.h:35 #6 _zval_ptr_dtor (zval_ptr=0x7fdfaf53fb30) at /opt/src/php- 5.4.5/Zend/zend_execute_API.c:438 #7 _zval_ptr_dtor (zval_ptr=0x7fdfaf53fb30) at /opt/src/php- 5.4.5/Zend/zend_execute_API.c:427 #8 0x0068e28b in zend_hash_apply_deleter (ht=ht@entry=0xd34508, p=p@entry=0x7fdfaf53fb18) at /opt/src/php-5.4.5/Zend/zend_hash.c:650 #9 0x0068fdd1 in zend_hash_reverse_apply (ht=0xd34508, apply_func=apply_func@entry=0x673f10 zval_call_destructor) at /opt/src/php- 5.4.5/Zend/zend_hash.c:804 #10 0x0067438b in shutdown_destructors () at /opt/src/php- 5.4.5/Zend/zend_execute_API.c:217 #11 0x006826c0 in zend_call_destructors () at /opt/src/php- 5.4.5/Zend/zend.c:925 #12 0x00624805 in php_request_shutdown (dummy=dummy@entry=0x0) at /opt/src/php-5.4.5/main/main.c:1723 #13 0x00726004 in do_cli (argc=2, argv=0x7fff5ea442f8) at /opt/src/php- 5.4.5/sapi/cli/php_cli.c:1174 #14 0x00428455 in main (argc=2, argv=0x7fff5ea442f8) at /opt/src/php- 5.4.5/sapi/cli/php_cli.c:1364 [2012-07-20 11:54:38] f...@php.net Reproducible on Debian wheezy with 5.4.0 and 5.4.5. [2012-07-20 08:13:34] vanidlesky dot jr at gmail dot com VanZCool [2012-07-20 08:07:05] zoeslam at gmail dot com Description: The code explains all, no idea why it happens. Verified on Ubuntu and Slackware, both on PHP 5.4.3, PHP 5.4.4, PHP 5.4.5. Test script: --- $ai = new ArrayIterator(array(0,1)); var_dump($ai-count()); $ii = new IteratorIterator($ai); var_dump($ii-count()); Expected result: int(2) int(2) Actual result: -- int(2) int(2) Segmentation fault -- Edit this bug report at https://bugs.php.net/bug.php?id=62616edit=1
Bug #62577 [Opn]: simplexml_load_file does not file if libxml_disable_entity_loader(true)
Edit report at https://bugs.php.net/bug.php?id=62577edit=1
ID: 62577
Updated by: jpa...@php.net
Reported by:ivan dot enderlin at hoa-project dot net
Summary:simplexml_load_file does not file if
libxml_disable_entity_loader(true)
Status: Open
Type: Bug
Package:SimpleXML related
Operating System: All
PHP Version:master-Git-2012-07-16 (Git)
Block user comment: N
Private report: N
New Comment:
http://lxr.php.net/xref/PHP_5_4/ext/libxml/libxml.c#1058
libxml_disable_entity_loader(true) registers a NULL function
(http://lxr.php.net/xref/PHP_5_4/ext/libxml/libxml.c#372) as callback for URI
input file handling in libxml.
So you cant open any file with libxml after having called this function.
Is that the correct behavior ? I have no clue to answer that
Previous Comments:
[2012-07-16 08:56:06] ivan dot enderlin at hoa-project dot net
Description:
The function simplexml_load_file() failed to open any file (existing or not) if
libxml_disable_entity_loader(true) has been called.
I have tried with simplexml_load_string(), it works; same with new
SimpleXMLElement() etc. The bug is restricted to the simplexml_load_file()
function.
Test script:
---
?php
libxml_use_internal_errors(true);
libxml_disable_entity_loader(true);
$xml = simplexml_load_file('foo');
print_r(libxml_get_errors());
var_dump($xml);
Expected result:
Array
(
)
â¦
Actual result:
--
Array
(
[0] = LibXMLError Object
(
[level] = 1
[code] = 1549
[column] = 0
[message] = failed to load external entity foo
[file] =
[line] = 0
)
)
bool(false)
--
Edit this bug report at https://bugs.php.net/bug.php?id=62577edit=1
Req #54638 [Opn]: PDO_MYSQL Always Uses Emulated Prepared Statements
Edit report at https://bugs.php.net/bug.php?id=54638edit=1 ID: 54638 Updated by: jpa...@php.net Reported by:me at ircmaxell dot com Summary:PDO_MYSQL Always Uses Emulated Prepared Statements Status: Open Type: Feature/Change Request Package:PDO related Operating System: All PHP Version:5.4 Block user comment: N Private report: N New Comment: I agree we should at least document that behavior. #61969 is related. Previous Comments: [2011-04-30 20:38:59] ras...@php.net This is a 5.4 feature request. There were very good reasons for not using the native prepared statement support in MySQL 5.1.17. [2011-04-30 17:38:08] damien at tournoud dot net Before MySQL 5.1.17, prepared statements completely skip the query cache (see http://dev.mysql.com/doc/refman/5.1/en/query-cache-operation.html). I think it's too early to make the switch. [2011-04-30 02:25:24] me at ircmaxell dot com Description: The PDO_MySQL driver defaults emulate_prepare to 1, which forces all prepared queries to be emulated by the driver. This means that even though the client library (mysqlnd or libmysql) may support prepared statements, PDO will never really use them. You can set the attribute PDO::ATTR_EMULATE_PREPARES to 0, and it prepares and executes the prepared statements just fine using the native mode (rather than emulation). However this is not documented at all on PHP.NET. Since PDO_MYSQL will fallback to emulation automatically if the client library or server are too old for prepared statements, I would suggest that the default value for emulate_prepare should be set to 0 to allow for true prepared statements. -- Edit this bug report at https://bugs.php.net/bug.php?id=54638edit=1
Bug #61838 [Nab]: mysqli_get_cache_stats() does nothing
Edit report at https://bugs.php.net/bug.php?id=61838edit=1 ID: 61838 Updated by: jpa...@php.net Reported by:jpa...@php.net Summary:mysqli_get_cache_stats() does nothing Status: Not a bug Type: Bug Package:MySQL related Operating System: Linux PHP Version:5.3.10 Block user comment: N Private report: N New Comment: So, there is no plan to implement this function at all ? Previous Comments: [2012-05-02 14:16:07] u...@php.net Good find, but... - it is marked as undocumented. Means, it can return pretty much anything, including nothing. - it is marked as deprecated. Whether this is sufficient or not, well, Docs team can decide on adding a note.I would say its OK as it is. Thus, setting to not a bug. [2012-04-24 14:19:38] jpa...@php.net Description: mysqli_get_cache_stats() just return an empty array, always. It has not been implemented, but it's documented :) Test script: --- See source code of mysqli_get_cache_stats(), it always returns an empty array, whatever happens Expected result: mysqli_get_cache_stats() returns useful data Actual result: -- mysqli_get_cache_stats() is useless actually -- Edit this bug report at https://bugs.php.net/bug.php?id=61838edit=1
Bug #54547 [Ver]: wrong equality of string numbers
Edit report at https://bugs.php.net/bug.php?id=54547edit=1
ID: 54547
Updated by: jpa...@php.net
Reported by:peter dot ritt at gmx dot net
Summary:wrong equality of string numbers
Status: Verified
Type: Bug
Package:Unknown/Other Function
Operating System: linux
PHP Version:5.3.6
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
I'd like to add that strcmp() and familly are functions designed to compare
strings, as they are in C ; except that in PHP they are binary compatible, like
PHP strings are
Previous Comments:
[2012-04-12 14:17:32] ni...@php.net
@Jeff Please see jabakobob's comment why doing just a string comparison can be
counterproductive. Remember: PHP is mainly used around the HTTP protocol (where
everything is a string) and MySQL (where also everything is returned as a
string). So in PHP you will often deal with numbers in strings, thus they
should be handled as such.
[2012-04-12 14:02:02] Jeff at bobmail dot info
That didn't address my comment. Why wouldn't the internal implementation check
to see if the strings are the same? When doing a comparison and the internal
data type is a string, wouldn't that be faster and most correct?
In all honesty I would prefer PHP's loosely typed system mimic JavaScript's
in that any type can be put anywhere but the object still keeps its type
information for situations just like this.
[2012-04-12 13:59:32] ni...@php.net
@Jeff: You have to understand in PHP 1, 1.0 and 1.0 all are equivalent (in
most situations). That's by design.
E.g. GET and POST variables are always strings, even if you put numbers into
them (as per the HTTP standard). PHP obviously wants those GET/POST variables
to still be useable just like they were numbers, that's why 1 and 1 can be
used interchangeably throughout PHP.
In that context - in my eyes - this comparison also makes sense. Consider a
very similar comparison:
var_dump('0.1' == '0.1000');
What would you expect to be the output - if you remember that in PHP numeric
strings and actual numbers are interchangeable? Clearly it has to behave
exactly as if you had written:
var_dump(0.1 == 0.1000); // = bool(true)
In most cases this type of comparison is what you want and it usually works
exactly as expected.
What you see here in this issue is one of the edge cases (how often do you use
large numbers in PHP?) where it does not work well.
I hope you understand that it is not viable to remove a handy feature from PHP,
just because it fails under certain edge case conditions.
If you want to use a strict string comparison, just use ===.
[2012-04-12 13:58:53] paj...@php.net
@Jeff at bobmail dot info
that's what === is for (real comparisons without casting).
[2012-04-12 13:51:22] jabakobob at gmail dot com
The conversion to a number is necessary because programmers don't differentiate
between strings and numbers in PHP. Consider the following code:
if ($_GET[a] == $_GET[b]) echo a is same as b!;
The result will be the same if the query string is ?a=1b=1 or ?a=1b=1.0 or ?
a=01b=1 because PHP is loosely typed.
Internally $_GET[a] and $_GET[b] are both strings, but we can't do a string
comparison. If you want a string comparison, use strcmp.
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=54547
--
Edit this bug report at https://bugs.php.net/bug.php?id=54547edit=1
Bug #61172 [Opn]: With Apache 2.4.1, ./configure fails on APXS but stops only on the MySQL check.
Edit report at https://bugs.php.net/bug.php?id=61172edit=1 ID: 61172 Updated by: jpa...@php.net Reported by:antoine dot bajolet at tdf dot fr Summary:With Apache 2.4.1, ./configure fails on APXS but stops only on the MySQL check. Status: Open Type: Bug Package:Compile Failure Operating System: Linux 3.2.6 glibc 2.11.3 PHP Version:5.3.10 Block user comment: N Private report: N New Comment: Same problem here, apxs -q doesn't handle MPM anymore because of DSOs MPM in Apache 2.4, I get a ZTS PHP at final whatever happens (no errors) The patch works fine, I suggest we merge it to 5.3 and 5.4 branches Previous Comments: [2012-02-24 06:11:08] antoine dot bajolet at tdf dot fr The patch works fine, thanks. PHP compiles to the end. (Note I didn't change anything about mysql and i have no configure failure anymore). Regards, AB [2012-02-24 00:49:37] s...@php.net Try the attached patch: patch bug61172.patch.txt rm configure config.cache autom4ate.* ./buildconf --force ./configure [2012-02-24 00:44:52] s...@php.net The following patch has been added/updated: Patch Name: bug61172.patch.txt Revision: 1330044292 URL: https://bugs.php.net/patch-display.php?bug=61172patch=bug61172.patch.txtrevision=1330044292 [2012-02-23 22:31:33] johan...@php.net This issue: checking for MySQL support... yes checking for specified location of the MySQL UNIX socket... no configure: error: Cannot find libmysqlclient_r under /usr/local/mysql. Note that the MySQL client library is not bundled anymore! Can be fixed by making sure that oyur MySQL installation contains the thread-safe version of libmysql or by using --with-mysql=mysqlnd --with-mysqli=mysqlnd --with-pdo-mysql=myslqnd to use the PHP-specific mysqlnd library. This won't solve the actual bug, though as you'll get a thread-safe PHP which one probably won't like as apxs -q MPM_NAME is not returning prefork (but an error) [2012-02-23 20:15:05] antoine dot bajolet at tdf dot fr Description: ./configure PHP 5.3.10 fails when attempting to configure apache2handler DSO with apache 2.4.1. - ./configure --prefix=/usr/local/ --with-apxs2=/usr/local/apache2.4/bin/apxs --with-config-file-path=/usr/local/ --with-mysql=/usr/local/mysql [.../...] 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... apxs:Error: Invalid query string `MPM_NAME'. yes 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... no checking for Zeus ISAPI support... no checking for LiteSpeed support... no checking for Milter support... no [.../...] checking for MySQL support... yes checking for specified location of the MySQL UNIX socket... no configure: error: Cannot find libmysqlclient_r under /usr/local/mysql. Note that the MySQL client library is not bundled anymore! - The behavior is very confusing, because if i choose the Apache 2.2.x APXS, the MySQL checks work fine ! : - ./configure --prefix=/usr/local/ --with-apxs2=/usr/local/apache2.2/bin/apxs --with-config-file-path=/usr/local/ --with-mysql=/usr/local/mysql [.../...] 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... yes checking for Apache 1.x (hooks) module support via DSO through APXS... no [.../...] checking for specified location of the MySQL UNIX socket... no checking for mysql_close in -lmysqlclient... yes checking for MySQL UNIX socket location... no [.../...] - In fact, the error is in the apache worker check, because of with apache 2.4, the worker can be dynamically loaded, and not fixed at compile time : The MPM_NAME parameter doesn't exist anymore : # /usr/local/apache2.2/bin/apxs -q MPM_NAME prefork # /usr/local/apache2.4/bin/apxs -q MPM_NAME apxs:Error: Invalid query
Bug #31749 [ReO]: deadlock due to libc mutexes not released when timeout signal is delivered
Edit report at https://bugs.php.net/bug.php?id=31749edit=1
ID: 31749
Updated by: jpa...@php.net
Reported by:phpbug2 at mailinator dot com
Summary:deadlock due to libc mutexes not released when
timeout signal is delivered
Status: Re-Opened
Type: Bug
Package:Scripting Engine problem
Operating System: Linux 2.4.28, 2.4.21-SMP
PHP Version:5CVS, 4CVS (2005-06-19)
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
Interesting as well as weird bug.
I have nothing to say about it that would move things forward but that signal
handling have been rewritten in PHP5.4. It might handle such cases, see with
contributors.
You should have a look at http://lxr.php.net/xref/PHP_5_4/Zend/zend_signal.c
and
try to reproduce the bug on a 5.4 basis.
Previous Comments:
[2011-11-17 01:34:38] tstarl...@php.net
I added a workaround to our custom error handler:
https://www.mediawiki.org/wiki/Special:Code/MediaWiki/103433
[2011-11-16 10:22:13] tstarl...@php.net
The suggested patch is an improvement, but it still calls zend_timeout() when
the hard timeout is reached, which will usually deadlock if a libc mutex such
as the one for malloc() is held. The only safe way to handle this situation is
to kill the process without calling any non-signal-safe functions, e.g. by
calling abort(). If you return control to Apache using longjmp() (like what
zend_bailout() does), Apache will deadlock instead. I haven't found any robust
way to display an error message, it would look the same as a segfault to the
user.
[2010-06-08 13:27:41] michael at makeweb dot no
I have the same problem, reproduced on php 4.4.9 and 5.3.0.
Basically pseudocode to reproduce is set_time_limit(1); do { ... } until time
passed = 1 second.
This will create a race condition where sometimes a libc lock will prevent
zend_timeout to process properly.
Script to reproduce on 5.3.0: ($limit is not 1, because php seems to not break
accurately on time - this value must be adjusted so the error PHP Fatal error:
Maximum execution time of 1 second exceeded in Unknown on line 0 frequently
appears. The script should fail within 100 runs (lock up).
?php
echo Trying to break php...\n;
set_time_limit(1);
$limit = 1.235;
$start = array_sum(explode(' ',$x = microtime()));
$a = array();
for ($cnt = 0; $cnt 10; $cnt++) {
for ($cntb = 0; $cntb 100; $cntb++) {
for ($cntc = 0; $cntc 100; $cntc++) {
$end = array_sum(explode(' ',$y = microtime()));
$a[$cnt][$cntb][$cntc] = md5($cnt.$cntb.$cntc);
if ($end = $start+$limit) break;
}
if ($end = $start+$limit) break;
}
if ($end = $start+$limit) break;
}
echo $x - $y (.($end-$start).)\n;
?
run with: while [ true ]; do php break.php; done
Though this scenario is unlikely, there are other cases where it can happen
very often, however I fail to come up with a short example of it. The reason
for generating a multidimensional array is that in php4, the hang is very
likely to happen within zend_shutdown, as the resources are freed (hangs within
1-10 cycles)
Keep in mind error logging has to be enabled (this is when there's calls for
libc get time which causes the locking issue within zend_timeout)
pstack for php 5.3.0:
# pstack 1565
#0 0x00319402 in __kernel_vsyscall ()
#1 0x001dede3 in __lll_lock_wait_private () from /lib/libc.so.6
#2 0x0016e6f6 in _L_lock_15330 () from /lib/libc.so.6
#3 0x0016dbb4 in free () from /lib/libc.so.6
#4 0x0012067c in setlocale () from /lib/libc.so.6
#5 0x08084586 in seek_to_tz_position ()
#6 0x08084664 in timelib_timezone_id_is_valid ()
#7 0x0806575c in guess_timezone ()
#8 0x080657a5 in get_timezone_info ()
#9 0x08067f35 in php_format_date ()
#10 0x082ab96e in php_log_err ()
#11 0x082abe17 in php_error_cb ()
#12 0x082f9fe8 in zend_error_noreturn ()
#13 0x082ec745 in zend_timeout ()
#14 signal handler called
#15 0x00169c49 in _int_free () from /lib/libc.so.6
#16 0x0016dbc0 in free () from /lib/libc.so.6
#17 0x082ac6df in php_conv_fp ()
#18 0x082ad409 in strx_printv ()
#19 0x082ad804 in ap_php_snprintf ()
#20 0x082565f2 in _php_gettimeofday ()
#21 0x08342509 in zend_do_fcall_common_helper_SPEC ()
#22 0x08319f3d in execute ()
#23 0x082f8e47 in zend_execute_scripts ()
#24 0x082a92be in php_execute_script ()
#25 0x08378457 in main ()
Any suggestions how to patch php4 be greatly appreciated!
Michael
[2008-07-21 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
Bug #61067 [Opn]: free() from signal handler leads to deadlock
Edit report at https://bugs.php.net/bug.php?id=61067edit=1 ID: 61067 Updated by: jpa...@php.net Reported by:phpbugs at oops dot mooo dot com Summary:free() from signal handler leads to deadlock Status: Open Type: Bug Package:FPM related Operating System: Debian Squeeze PHP Version:5.3.10 Block user comment: N Private report: N New Comment: Seems related to #31749 Previous Comments: [2012-02-12 22:59:18] phpbugs at oops dot mooo dot com Description: Using PHP-FPM-5.3.10+APC-3.1.9. I just discovered 30 PHP processes that's been running for 22 hours. Further inspection revealed all of them (except one) are waiting to flock() a session file. The process holding the flock() is doing: futex(0x7f21238f9e40, FUTEX_WAIT_PRIVATE, 2, NULL unfinished ... (gdb) info threads Id Target Id Frame * 1Thread 0x7f2126114720 (LWP 4271) __lll_lock_wait_private () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:97 (gdb) bt #0 __lll_lock_wait_private () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:97 #1 0x7f2123614558 in _L_lock_9590 () from /lib/libc.so.6 #2 0x7f2123612941 in *__GI___libc_free (mem=0x7f21238f9e40) at malloc.c:3737 #3 0x7f21263f5820 in php_error_cb (type=1, error_filename=0x7f2121088fd8 , error_lineno=154, format=optimized out, args=optimized out) at /build/php-5.3.10/main/main.c:931 #4 0x7f2126446d7c in zend_error (type=1, format=0x7f2126902028 Maximum execution time of %d second%s exceeded) at /build/php-5.3.10/Zend/zend.c:1127 #5 signal handler called #6 0x7f2123612a1d in *__GI___libc_malloc (bytes=50) at malloc.c:3658 #7 0x7f2123617a22 in *__GI___strdup (s=0x7f2121088fd8 ) at strdup.c:43 #8 0x7f21263f587a in php_error_cb (type=8, error_filename=0x7f2121088fd8 , error_lineno=154, format=optimized out, args=optimized out) at /build/php-5.3.10/main/main.c:943 #9 0x7f2126446d7c in zend_error (type=8, format=0x7f2126907356 Undefined index: %s) at /build/php-5.3.10/Zend/zend.c:1127 #10 0x7f21264b2f89 in zend_fetch_dimension_address_inner (type=optimized out, dim=optimized out, ht=optimized out) at /build/php-5.3.10/Zend/zend_execute.c:820 #11 zend_fetch_dimension_address_read (result=0x7f2127f17930, container_ptr=optimized out, dim=0x7f2126bf25c8, dim_is_tmp_var=optimized out, type=0) at /build/php-5.3.10/Zend/zend_execute.c:1043 #12 0x7f21264b4059 in ZEND_FETCH_DIM_R_SPEC_CV_VAR_HANDLER (execute_data=0x7f2127f17678) at /build/php-5.3.10/Zend/zend_vm_execute.h:26962 #13 0x7f212646ee30 in execute (op_array=0x7f2127efe020) at /build/php-5.3.10/Zend/zend_vm_execute.h:107 #14 0x7f212644654f in zend_execute_scripts (type=8, retval=optimized out, file_count=3) at /build/php-5.3.10/Zend/zend.c:1308 #15 0x7f21263f2bc7 in php_execute_script (primary_file=optimized out) at /build/php-5.3.10/main/main.c:2323 #16 0x7f21264db7c8 in main (argc=669766600, argv=optimized out) at /build/php-5.3.10/sapi/fpm/fpm/fpm_main.c:1875 It looks like PHP caught a signal inside malloc(), causing glibc to take some lock, and that free() wants the same lock, leading to deadlock. I'm not sure if malloc/free is safe to use in signal handlers. http://linux.derkeiler.com/Newsgroups/comp.os.linux.development.apps/2005-07/0323.html seems to suggest it's not. -- Edit this bug report at https://bugs.php.net/bug.php?id=61067edit=1
Bug #31749 [ReO]: deadlock due to libc mutexes not released when timeout signal is delivered
Edit report at https://bugs.php.net/bug.php?id=31749edit=1
ID: 31749
Updated by: jpa...@php.net
Reported by:phpbug2 at mailinator dot com
Summary:deadlock due to libc mutexes not released when
timeout signal is delivered
Status: Re-Opened
Type: Bug
Package:Scripting Engine problem
Operating System: Linux 2.4.28, 2.4.21-SMP
PHP Version:5CVS, 4CVS (2005-06-19)
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
Seems like there are problems with 5.4 zend signals.
http://marc.info/?l=php-internalsm=132921501729587
Also, see related #61067
Previous Comments:
[2012-02-14 10:10:31] jpa...@php.net
Interesting as well as weird bug.
I have nothing to say about it that would move things forward but that signal
handling have been rewritten in PHP5.4. It might handle such cases, see with
contributors.
You should have a look at http://lxr.php.net/xref/PHP_5_4/Zend/zend_signal.c
and
try to reproduce the bug on a 5.4 basis.
[2011-11-17 01:34:38] tstarl...@php.net
I added a workaround to our custom error handler:
https://www.mediawiki.org/wiki/Special:Code/MediaWiki/103433
[2011-11-16 10:22:13] tstarl...@php.net
The suggested patch is an improvement, but it still calls zend_timeout() when
the hard timeout is reached, which will usually deadlock if a libc mutex such
as the one for malloc() is held. The only safe way to handle this situation is
to kill the process without calling any non-signal-safe functions, e.g. by
calling abort(). If you return control to Apache using longjmp() (like what
zend_bailout() does), Apache will deadlock instead. I haven't found any robust
way to display an error message, it would look the same as a segfault to the
user.
[2010-06-08 13:27:41] michael at makeweb dot no
I have the same problem, reproduced on php 4.4.9 and 5.3.0.
Basically pseudocode to reproduce is set_time_limit(1); do { ... } until time
passed = 1 second.
This will create a race condition where sometimes a libc lock will prevent
zend_timeout to process properly.
Script to reproduce on 5.3.0: ($limit is not 1, because php seems to not break
accurately on time - this value must be adjusted so the error PHP Fatal error:
Maximum execution time of 1 second exceeded in Unknown on line 0 frequently
appears. The script should fail within 100 runs (lock up).
?php
echo Trying to break php...\n;
set_time_limit(1);
$limit = 1.235;
$start = array_sum(explode(' ',$x = microtime()));
$a = array();
for ($cnt = 0; $cnt 10; $cnt++) {
for ($cntb = 0; $cntb 100; $cntb++) {
for ($cntc = 0; $cntc 100; $cntc++) {
$end = array_sum(explode(' ',$y = microtime()));
$a[$cnt][$cntb][$cntc] = md5($cnt.$cntb.$cntc);
if ($end = $start+$limit) break;
}
if ($end = $start+$limit) break;
}
if ($end = $start+$limit) break;
}
echo $x - $y (.($end-$start).)\n;
?
run with: while [ true ]; do php break.php; done
Though this scenario is unlikely, there are other cases where it can happen
very often, however I fail to come up with a short example of it. The reason
for generating a multidimensional array is that in php4, the hang is very
likely to happen within zend_shutdown, as the resources are freed (hangs within
1-10 cycles)
Keep in mind error logging has to be enabled (this is when there's calls for
libc get time which causes the locking issue within zend_timeout)
pstack for php 5.3.0:
# pstack 1565
#0 0x00319402 in __kernel_vsyscall ()
#1 0x001dede3 in __lll_lock_wait_private () from /lib/libc.so.6
#2 0x0016e6f6 in _L_lock_15330 () from /lib/libc.so.6
#3 0x0016dbb4 in free () from /lib/libc.so.6
#4 0x0012067c in setlocale () from /lib/libc.so.6
#5 0x08084586 in seek_to_tz_position ()
#6 0x08084664 in timelib_timezone_id_is_valid ()
#7 0x0806575c in guess_timezone ()
#8 0x080657a5 in get_timezone_info ()
#9 0x08067f35 in php_format_date ()
#10 0x082ab96e in php_log_err ()
#11 0x082abe17 in php_error_cb ()
#12 0x082f9fe8 in zend_error_noreturn ()
#13 0x082ec745 in zend_timeout ()
#14 signal handler called
#15 0x00169c49 in _int_free () from /lib/libc.so.6
#16 0x0016dbc0 in free () from /lib/libc.so.6
#17 0x082ac6df in php_conv_fp ()
#18 0x082ad409 in strx_printv ()
#19 0x082ad804 in ap_php_snprintf ()
#20 0x082565f2 in _php_gettimeofday ()
#21 0x08342509 in zend_do_fcall_common_helper_SPEC ()
#22 0x08319f3d in execute ()
#23 0x082f8e47 in zend_execute_scripts ()
#24 0x082a92be in php_execute_script ()
#25 0x08378457 in main ()
Any suggestions how to patch php4 be greatly appreciated!
Bug #61046 [Opn]: Segfault when memory limit is hit while copying hash table
Edit report at https://bugs.php.net/bug.php?id=61046edit=1
ID: 61046
Updated by: jpa...@php.net
Reported by:ni...@php.net
Summary:Segfault when memory limit is hit while copying hash
table
Status: Open
Type: Bug
Package:Reproducible crash
PHP Version:5.4.0RC7
Block user comment: N
Private report: N
New Comment:
What I can say :
- I dont reproduce on 5.3.10
- For 5.4, disabling ZendMM with USE_ZEND_ALLOC=0 makes the segfault disappear
- For 5.4, changing the ZendMM segment size with ZEND_MM_SEG_SIZE={val} makes
the
segfault disappear, I havent tested all the possible values for SEG_SIZE.
As a reminder, ZendMM default SEG_SIZE is set to 256k
Previous Comments:
[2012-02-10 17:31:28] ni...@php.net
GDB Stacktrace:
#0 zend_mm_remove_from_free_list (heap=0x88da8d8, mm_block=0xb7fc5308)
at /home/nikic/dev/php-src-git/Zend/zend_alloc.c:805
#1 0x083ad608 in _zend_mm_free_int (heap=0x88da8d8, p=0xb7fc52f0)
at /home/nikic/dev/php-src-git/Zend/zend_alloc.c:2101
#2 0x083cd657 in destroy_op_array (op_array=0x8a5d4c8, tsrm_ls=0x88d9050)
at /home/nikic/dev/php-src-git/Zend/zend_opcode.c:380
#3 0x083cd777 in zend_function_dtor (function=0x8a5d4c8)
at /home/nikic/dev/php-src-git/Zend/zend_opcode.c:124
#4 0x083e49ae in zend_hash_apply_deleter (ht=0x88dae70, p=0x8a5d498)
at /home/nikic/dev/php-src-git/Zend/zend_hash.c:650
#5 0x083e63b1 in zend_hash_reverse_apply (ht=0x88dae70,
apply_func=0x83c7310 clean_non_persistent_function, tsrm_ls=0x88d9050)
at /home/nikic/dev/php-src-git/Zend/zend_hash.c:804
#6 0x083c7ecb in shutdown_executor (tsrm_ls=0x88d9050)
at /home/nikic/dev/php-src-git/Zend/zend_execute_API.c:304
#7 0x083d7c11 in zend_deactivate (tsrm_ls=0x88d9050)
at /home/nikic/dev/php-src-git/Zend/zend.c:934
#8 0x0836be33 in php_request_shutdown (dummy=0x0)
at /home/nikic/dev/php-src-git/main/main.c:1782
#9 0x0848d723 in do_cli (argc=4, argv=0xb3b4, tsrm_ls=0x88d9050)
at /home/nikic/dev/php-src-git/sapi/cli/php_cli.c:1169
#10 0x0806eaa3 in main (argc=4, argv=0xb3b4)
at /home/nikic/dev/php-src-git/sapi/cli/php_cli.c:1356
[2012-02-10 17:28:02] ni...@php.net
Description:
The attached test script triggers a segfault. It happens during the shutdown
after the memory limit is reached in the byRef($array) line.
Test script:
---
?php
function byRef($ref) {}
ini_set('memory_limit', '500k');
$array = array_fill(0, 2000, '*');
$ref = $array;
byRef($array);
--
Edit this bug report at https://bugs.php.net/bug.php?id=61046edit=1
Bug #61046 [Opn]: Segfault when memory limit is hit while copying hash table
Edit report at https://bugs.php.net/bug.php?id=61046edit=1
ID: 61046
Updated by: jpa...@php.net
Reported by:ni...@php.net
Summary:Segfault when memory limit is hit while copying hash
table
Status: Open
Type: Bug
Package:Reproducible crash
PHP Version:5.4.0RC7
Block user comment: N
Private report: N
New Comment:
Notice that I only reproduce with memory_limit set to accurate 512k , not 500k
as
in bug text, nor even 511k
Previous Comments:
[2012-02-10 17:34:21] jpa...@php.net
What I can say :
- I dont reproduce on 5.3.10
- For 5.4, disabling ZendMM with USE_ZEND_ALLOC=0 makes the segfault disappear
- For 5.4, changing the ZendMM segment size with ZEND_MM_SEG_SIZE={val} makes
the
segfault disappear, I havent tested all the possible values for SEG_SIZE.
As a reminder, ZendMM default SEG_SIZE is set to 256k
[2012-02-10 17:31:28] ni...@php.net
GDB Stacktrace:
#0 zend_mm_remove_from_free_list (heap=0x88da8d8, mm_block=0xb7fc5308)
at /home/nikic/dev/php-src-git/Zend/zend_alloc.c:805
#1 0x083ad608 in _zend_mm_free_int (heap=0x88da8d8, p=0xb7fc52f0)
at /home/nikic/dev/php-src-git/Zend/zend_alloc.c:2101
#2 0x083cd657 in destroy_op_array (op_array=0x8a5d4c8, tsrm_ls=0x88d9050)
at /home/nikic/dev/php-src-git/Zend/zend_opcode.c:380
#3 0x083cd777 in zend_function_dtor (function=0x8a5d4c8)
at /home/nikic/dev/php-src-git/Zend/zend_opcode.c:124
#4 0x083e49ae in zend_hash_apply_deleter (ht=0x88dae70, p=0x8a5d498)
at /home/nikic/dev/php-src-git/Zend/zend_hash.c:650
#5 0x083e63b1 in zend_hash_reverse_apply (ht=0x88dae70,
apply_func=0x83c7310 clean_non_persistent_function, tsrm_ls=0x88d9050)
at /home/nikic/dev/php-src-git/Zend/zend_hash.c:804
#6 0x083c7ecb in shutdown_executor (tsrm_ls=0x88d9050)
at /home/nikic/dev/php-src-git/Zend/zend_execute_API.c:304
#7 0x083d7c11 in zend_deactivate (tsrm_ls=0x88d9050)
at /home/nikic/dev/php-src-git/Zend/zend.c:934
#8 0x0836be33 in php_request_shutdown (dummy=0x0)
at /home/nikic/dev/php-src-git/main/main.c:1782
#9 0x0848d723 in do_cli (argc=4, argv=0xb3b4, tsrm_ls=0x88d9050)
at /home/nikic/dev/php-src-git/sapi/cli/php_cli.c:1169
#10 0x0806eaa3 in main (argc=4, argv=0xb3b4)
at /home/nikic/dev/php-src-git/sapi/cli/php_cli.c:1356
[2012-02-10 17:28:02] ni...@php.net
Description:
The attached test script triggers a segfault. It happens during the shutdown
after the memory limit is reached in the byRef($array) line.
Test script:
---
?php
function byRef($ref) {}
ini_set('memory_limit', '500k');
$array = array_fill(0, 2000, '*');
$ref = $array;
byRef($array);
--
Edit this bug report at https://bugs.php.net/bug.php?id=61046edit=1
Bug #60909 [Opn]: custom error handler throwing Exception + fatal error = no shutdown function
Edit report at https://bugs.php.net/bug.php?id=60909edit=1
ID: 60909
Updated by: jpa...@php.net
Reported by:tyr...@php.net
Summary:custom error handler throwing Exception + fatal
error = no shutdown function
Status: Open
Type: Bug
Package:Scripting Engine problem
Operating System: linux
PHP Version:5.4.0RC6
Block user comment: N
Private report: N
New Comment:
Ok I can reproduce.
Try replacing your require (which generates E_COMPILE_ERROR) by an unknown
function call (which generates E_ERROR), and all's just fine
So there is a trick in the error engine, any kind of fatal shouldn't be handled
by user defined error handlers, here we got proof it's not the case
Tip: Reproduced on 5.3.10 as well
Previous Comments:
[2012-01-27 18:07:20] tyr...@php.net
Description:
first of all sorry for the weird Summary, I couldn't come up with a better one.
it is weird.
so it seems that if you have a shutdown function callback set and a custom
error
handler which would throw and exception and you happen to have a fatal error,
the shutdown function won't be called.
See the attached script, the error handler shouldn't really do anything here,
because it won't be called for the fatals, but somehow it still screw things up.
If I remove the error handler, I will see the !!!shutdown!!! printed.
If I put a return false; before the throw I will see the !!!shutdown!!!
printed.
If I add E_NOTICE as the $error_type to the set_error_handler call I will see
the !!!shutdown!!! printed.
If I add E_WARNING as the $error_type to the set_error_handler call I will NOT
see the !!!shutdown!!! printed.
wtf?
Test script:
---
?php
register_shutdown_function(function(){echo(\n\n!!!shutdown!!!\n\n);});
set_error_handler(function($errno, $errstr, $errfile, $errline){throw new
Exception(Foo);});
require 'notfound.php';
--
Edit this bug report at https://bugs.php.net/bug.php?id=60909edit=1
Bug #60981 [Asn]: Shell environment inaccessible in tests
Edit report at https://bugs.php.net/bug.php?id=60981edit=1 ID: 60981 Updated by: jpa...@php.net Reported by:david at davidfavor dot com Summary:Shell environment inaccessible in tests Status: Assigned Type: Bug Package:Testing related Operating System: Ubuntu 11.10 PHP Version:5.3.10 Assigned To:danielc Block user comment: N Private report: N New Comment: I confirm that getenv() works regardless any .ini config. It proxies to SAPI/system getenv() Previous Comments: [2012-02-07 14:30:43] tyr...@php.net the problem is that the run-tests.php fetches the environment variables from $_ENV http://svn.php.net/viewvc/php/php-src/trunk/run-tests.php?view=markup#l134 then passes the environment variables to the system_with_timeout call (which will proc_open using those environment variables). so there is no documentation issue, only run-tests.php needs a change to either force the variable_orders to contain E(we could pass the --d variable_orders=EGPCS in the run-tests.php call in http://svn.php.net/viewvc/php/php- src/trunk/Makefile.global) or changing run-tests.php to not use the $_ENV array for fetching all the environment vars. [2012-02-07 14:18:14] tyr...@php.net AFAIK getenv does work independently from variable_orders: foo=bar php -d variables_order=GPC -r 'echo $_ENV[foo];echo getenv(foo);' outputs bar for me, so it works. Tyrael [2012-02-07 14:11:31] david at davidfavor dot com That works... So there are two doc errors... #1) http://php.net/manual/en/reserved.variables.environment.php contains comments that getenv() returns environment variables, independent of variable_orders setting. I've submitted a note to clarify this. #2 http://php.net/manual/en/ini.core.php states variables_order default setting is EGPCS, which is incorrect. Both php.ini-production and php.ini-development contain GPCS. Best to fix both php.ini files so they match the docs. Let me know if I should open another bug request for the doc change. Thanks for helping me get this to work! [2012-02-06 21:30:59] s...@php.net Try adding E to php.ini's variables_order. [2012-02-06 20:12:20] david at davidfavor dot com export var=foo is the same as sourcing a file that includes... export var=foo Problem is no shell environment is reaching the test scripts. Please suggest a way to turn off clearing of the environment. 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=60981 -- Edit this bug report at https://bugs.php.net/bug.php?id=60981edit=1
Req #38489 [Opn-Csd]: DOMNodeList should implement Traversable
Edit report at https://bugs.php.net/bug.php?id=38489edit=1
ID: 38489
Updated by: jpa...@php.net
Reported by:mmcintyre at squiz dot net
Summary:DOMNodeList should implement Traversable
-Status: Open
+Status: Closed
Type: Feature/Change Request
Package:DOM XML related
Operating System: *
PHP Version:5.1.5
-Assigned To:
+Assigned To:jpauli
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
DomNodeListe implements Traversable. You can convert a Traversable object to an
Iterator using the IteratorIterator
class.
?php
$xml = 'queriesquery attr1=value/query/queries';
$doc = new DOMDocument;
$doc-loadXML($xml);
$queries = $doc-getElementsByTagName('queries');
$nodes = iterator_to_array(new IteratorIterator($queries));
?
Previous Comments:
[2007-01-17 15:11:55] jules_papillon_fh at yahoo dot de
This bug exists further reproducibly on PHP5.2
[2007-01-17 15:09:11] jules_papillon_fh at yahoo dot de
Another Code to reproduce the Bug:
--
$dom = new DOMDocument('1.0', 'ISO-8859-1');
$dom-load('file.xml');
$iterator = new RecursiveIteratorIterator($dom-childNodes,
RecursiveIteratorIterator::SELF_FIRST);
foreach($iterator as $name = $element) {
print $name . \n;
}
Expected result:
A recursive List of all Elements
Actual result:
--
Catchable fatal error: Argument 1 passed to
RecursiveIteratorIterator::__construct() must implement interface Traversable,
instance of DOMNodeList given, called in [
] and defined in [
]
[2006-08-18 06:37:22] mmcintyre at squiz dot net
Description:
Currently, a DOMNodeList object can be traversed using a foreach loop, but it
cannot be converted to an array using iterator_to_array(), as it produces an
error Warning: iterator_to_array() expects parameter 1 to be Traversable,
object given
Reproduce code:
---
$xml = 'queriesquery attr1=value/query/queries';
$doc = new DOMDocument;
$doc-loadXML($xml);
$queries = $doc-getElementsByTagName('queries');
$nodes = iterator_to_array($queries);
Expected result:
The nodes in the NodeList are returned as an array.
Actual result:
--
Warning: iterator_to_array() expects parameter 1 to be Traversable, object
given
--
Edit this bug report at https://bugs.php.net/bug.php?id=38489edit=1
