Bug #53035 [Com]: finfo_file() returns incorrect mimetype
Edit report at https://bugs.php.net/bug.php?id=53035&edit=1 ID: 53035 Comment by: n dot delargy at ctidigital dot com Reported by:stuart at horuskol dot net Summary:finfo_file() returns incorrect mimetype Status: Bogus Type: Bug Package:Filesystem function related Operating System: Linux/Ubuntu 10.04 PHP Version:Irrelevant Block user comment: N Private report: N New Comment: I've also had this issue, using ZF Zend_Validate_File_MimeType a text/plain file (according to file -i /path/to/file.txt) is incorrectly identified as text/x-c in ubuntu 11.10 Previous Comments: [2011-07-06 19:27:16] shawn at thesignchef dot com I am having the same issue still. Has this been fixed or is there a workaround. Thanks so much. [2010-11-09 16:57:47] stephane at emark dot nl Hi, I just want to say that I experience the same problem. As fel...@php.net mentionned, if you have any type of comments at the top of your file, the problem occurs. For example, if i try to get the mime type of a js file with comments at the top, it returns "text/x-c", if i remove the comments, then it returns "text/plain", which in and of itself is not correct as it should return 'text/javascript'. Any idea how to circumvent this problem other than removing all my comments ?!?! [2010-10-13 00:38:01] stuart at horuskol dot net "however, the command line tool 'mimetype' correctly identifies the file using the same library at '/usr/share/misc/magic'" I tested using the -M switch (as in my example/test script): mimetype -DM --database /usr/share/misc/magic /path/to/file/reset.css and this tells me the file is text/css on my platform - are you sure you're using the same magic database? [2010-10-12 07:52:11] ahar...@php.net I get the same result from the command line "file" program on Ubuntu 10.10: $ curl -s http://horuskol.net/reset.css | file --mime-type - /dev/stdin: text/x-c mimetype also believes it's C source: $ mimetype -DM reset.css > Data dirs are: /home/aharvey/.local/share, /usr/share/gnome, > /usr/local/share, /usr/share > Checking all magic rules > Value "/*" at offset 2 matches at /usr/share/mime/magic line 1136 reset.css: text/x-csrc The only way I can get mimetype to return text/css is if it also looks at the extension (ie is called without -M). I can't really see any way this is a PHP bug, given other programs using the same magic database are resulting in the same file being detected as C source. Closing. [2010-10-11 15:39:35] fel...@php.net Strange... It's caused by the comment in the begin of the CSS file. 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=53035 -- Edit this bug report at https://bugs.php.net/bug.php?id=53035&edit=1
Bug #53035 [Com]: finfo_file() returns incorrect mimetype
Edit report at https://bugs.php.net/bug.php?id=53035&edit=1 ID: 53035 Comment by: n dot delargy at ctidigital dot com Reported by:stuart at horuskol dot net Summary:finfo_file() returns incorrect mimetype Status: Bogus Type: Bug Package:Filesystem function related Operating System: Linux/Ubuntu 10.04 PHP Version:Irrelevant Block user comment: N Private report: N New Comment: It may also be worth noting that the file was converted from an excel sheet to a text tab delimited and charset was us-ascii Previous Comments: [2011-12-12 12:06:42] n dot delargy at ctidigital dot com I've also had this issue, using ZF Zend_Validate_File_MimeType a text/plain file (according to file -i /path/to/file.txt) is incorrectly identified as text/x-c in ubuntu 11.10 [2011-07-06 19:27:16] shawn at thesignchef dot com I am having the same issue still. Has this been fixed or is there a workaround. Thanks so much. [2010-11-09 16:57:47] stephane at emark dot nl Hi, I just want to say that I experience the same problem. As fel...@php.net mentionned, if you have any type of comments at the top of your file, the problem occurs. For example, if i try to get the mime type of a js file with comments at the top, it returns "text/x-c", if i remove the comments, then it returns "text/plain", which in and of itself is not correct as it should return 'text/javascript'. Any idea how to circumvent this problem other than removing all my comments ?!?! [2010-10-13 00:38:01] stuart at horuskol dot net "however, the command line tool 'mimetype' correctly identifies the file using the same library at '/usr/share/misc/magic'" I tested using the -M switch (as in my example/test script): mimetype -DM --database /usr/share/misc/magic /path/to/file/reset.css and this tells me the file is text/css on my platform - are you sure you're using the same magic database? [2010-10-12 07:52:11] ahar...@php.net I get the same result from the command line "file" program on Ubuntu 10.10: $ curl -s http://horuskol.net/reset.css | file --mime-type - /dev/stdin: text/x-c mimetype also believes it's C source: $ mimetype -DM reset.css > Data dirs are: /home/aharvey/.local/share, /usr/share/gnome, > /usr/local/share, /usr/share > Checking all magic rules > Value "/*" at offset 2 matches at /usr/share/mime/magic line 1136 reset.css: text/x-csrc The only way I can get mimetype to return text/css is if it also looks at the extension (ie is called without -M). I can't really see any way this is a PHP bug, given other programs using the same magic database are resulting in the same file being detected as C source. Closing. 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=53035 -- Edit this bug report at https://bugs.php.net/bug.php?id=53035&edit=1
[PHP-BUG] Bug #60498 [NEW]: Unset obj.prop. thru ArrayAccess while iterating thru ArrayIterator cause error
From:
Operating system: Unix
PHP version: 5.3.8
Package: SPL related
Bug Type: Bug
Bug description:Unset obj.prop. thru ArrayAccess while iterating thru
ArrayIterator cause error
Description:
Using foreach to iterate object which implements IteratorAggregate and
ArrayAccess while iterating with iterator created by ArrayIterator($this)
causes
error in internal spl_array_update_pos when trying to unset object property
thru
arrayaccess interface:
debug:
#0 0x000802f9cd2f in spl_array_update_pos (intern=0x80847d778) at
/usr/ports/lang/php5/work/php-5.3.8/ext/spl/spl_array.c:101
101 intern->pos_h = pos->h;
[New Thread 8016041c0 (LWP 100187/httpd)]
(gdb) bt
#0 0x000802f9cd2f in spl_array_update_pos (intern=0x80847d778) at
/usr/ports/lang/php5/work/php-5.3.8/ext/spl/spl_array.c:101
#1 0x000802fa00aa in spl_array_next_no_verify (intern=0x80847d778,
aht=0x8082764a8) at
/usr/ports/lang/php5/work/php-5.3.8/ext/spl/spl_array.c:858
#2 0x000802fa0566 in spl_array_it_move_forward (iter=0x808428330) at
/usr/ports/lang/php5/work/php-5.3.8/ext/spl/spl_array.c:983
#3 0x000803189a25 in ZEND_FE_FETCH_SPEC_VAR_HANDLER
(execute_data=0x807a0a268) at zend_vm_execute.h:9014
#4 0x0008031616aa in execute (op_array=0x803af3d00) at
zend_vm_execute.h:107
#5 0x00080311c307 in zend_call_function (fci=0x7fffcc50,
fci_cache=0x7fffcc20) at /usr/ports/lang/php5/work/php-
5.3.8/Zend/zend_execute_API.c:968
#6 0x000802fcd3ee in zif_call_user_func (ht=2,
return_value=0x8082bd5d0,
return_value_ptr=0x0, this_ptr=0x0, return_value_used=1) at
/usr/ports/lang/php5/work/php-5.3.8/ext/standard/basic_functions.c:4772
#7 0x00080316271c in zend_do_fcall_common_helper_SPEC
(execute_data=0x807a09c48) at zend_vm_execute.h:320
#8 0x0008031636c5 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0x807a09c48) at zend_vm_execute.h:425
#9 0x0008031616aa in execute (op_array=0x807af1c50) at
zend_vm_execute.h:107
#10 0x00080312de5d in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/ports/lang/php5/work/php-5.3.8/Zend/zend.c:1236
#11 0x0008030ad482 in php_execute_script (primary_file=0x7fffe5a0)
at
/usr/ports/lang/php5/work/php-5.3.8/main/main.c:2284
#12 0x000803221e45 in php_handler (r=0x803ba40a0) at
/usr/ports/lang/php5/work/php-5.3.8/sapi/apache2handler/sapi_apache2.c:669
#13 0x0043dd1a in ap_run_handler (r=0x803ba40a0) at config.c:157
#14 0x0043e643 in ap_invoke_handler (r=0x803ba40a0) at
config.c:376
#15 0x0044f9d4 in ap_process_request (r=0x803ba40a0) at
http_request.c:282
#16 0x0044c7b4 in ap_process_http_connection (c=0x803afa290) at
http_core.c:190
#17 0x004475aa in ap_run_process_connection (c=0x803afa290) at
connection.c:43
#18 0x00447a2b in ap_process_connection (c=0x803afa290,
csd=0x803afa0a0)
at connection.c:190
#19 0x00456d85 in child_main (child_num_arg=37) at prefork.c:667
#20 0x00456f3c in make_child (s=0x80161c708, slot=37) at
prefork.c:768
#21 0x00457629 in ap_mpm_run (_pconf=0x801615028, plog=0x801647028,
s=0x80161c708) at prefork.c:1068
#22 0x0042410b in main (argc=2, argv=0x7fffeb20) at main.c:739
(gdb) bt full
Test script:
---
class obj implements \ArrayAccess , \IteratorAggregate {
public function __construct() {
foreach(array("one" => 1, "two" => 2, "three" => 3) as $offset =>
$value) $this->{$offset} = $value;
}
public function offsetSet($offset, $value) {
$this->{$offset} = $value;
}
public function offsetExists($offset) {
return isset($this->{$offset});
}
public function offsetUnset($offset) {
unset($this->{$offset});
}
public function offsetGet($offset) {
return isset($this->{$offset}) ? $this->{$offset} : null;
}
function getIterator() {
return new \ArrayIterator($this);
}
}
$obj = new obj;
foreach($obj as $offset => $value) unset($obj[$offset]);
print_r($obj);
foreach(get_object_vars($obj) as $offset => $value) unset($obj[$offset]);
print_r($obj);
Expected result:
obj Object
(
)
obj Object
(
)
Actual result:
--
The first foreach cause an internal error second one is ok
--
Edit bug report at https://bugs.php.net/bug.php?id=60498&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60498&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60498&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60498&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60498&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60498&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60498&r=alreadyfixed
Need backtrace:
Bug #32983 [Com]: Bogus error message when using ArrayAccess / References
Edit report at https://bugs.php.net/bug.php?id=32983&edit=1
ID: 32983
Comment by: charles dot louw at gmail dot com
Reported by:jason at amp-design dot net
Summary:Bogus error message when using ArrayAccess /
References
Status: Closed
Type: Bug
Package:SPL related
Operating System: *
PHP Version:5.0.3
Assigned To:helly
Block user comment: N
Private report: N
New Comment:
Excuse me if I'm being obtuse here but this doesn't really solve the problem
and renders the ArrayAccess interface useless for anything other than
1-dimensional arrays. So you can't do:
$data = new ArrayAccessImpl(); // using class in example above
$data['level_1'] = array();
$data['level_1']['level_2'] = 'some data';
Suggestion:
1. Change the ArrayAccess interface to support references - so as to fix the
problem.
2. Reduce the severity of the error triggered for class declarations that don't
implement the ArrayAccess methods with references from "fatal" to "warning" (so
that the application does not terminate).
3. If I'm not amiss very little will need to be changed in the SPL to then
handle data passed to & from the (ArrayAccess) methods whether passed by
reference or not. This will "maintain" BC.
4. Once the old implementation of the ArrayAccess methods have been deprecated
you can remove the interface check specific to ArrayAccess which will then
revert to a fatal.
* The fatal error I'm talking about would be: "Declaration of
ArrayAccessImpl::offsetSet() must be compatible with that of
ArrayAccess::offsetSet()"... and for the other methods.
* You could do this as a major revision. I would rather know that I need to
update the classes that implement ArrayAccess before upgrading to say PHP.v6
rather than have to live with this limitation. Basically I will now not use
ArrayAccess again because of this bug.
Previous Comments:
[2005-08-16 23:30:14] he...@php.net
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
We found out that this is not solvable without blowing up the interface and
creating a BC or providing an additional interface to support references and
thereby creating an internal nightmare - actually i don't see a way we can make
that work ever. Thus we decided to enforce the original design and disallow
references completley. Also the error message should have changed with 5.0.4 or
is being changed with 5.0.5/5.1 at least
[2005-08-16 07:44:50] sslotnick at gmail dot com
I have a similar but different reproduction using two dimensional arrays
instead of explicitly setting a reference.
class ArrayAccessImpl implements ArrayAccess {
private $data = array();
public function offsetUnset($index) {}
public function offsetSet($index, $value) {
$this->data[$index] = $value;
}
public function offsetGet($index) {
return $this->data[$index];
}
public function offsetExists($index) {
return isset($this->data[$index]);
}
}
$data = new ArrayAccessImpl();
$data['element'] = array();
$data['element']['element2'] = "hi";
[2005-05-09 19:05:42] he...@php.net
Actually at the moment this is a known issue which we cannot fix appropriate
right away. But we are working on the matter.
[2005-05-09 12:38:42] jason at amp-design dot net
Description:
I'm not 100% sure this is considered a "bug" as such, anyway, I thought I'd
point it out, and let you decide. It's more a case of the error message being a
little fuzzy.
When trying to assign an item by reference by using the reference operator, &,
to an element inside a class that implements ArrayAccess produces a werid error
message.
Admittedly, the code I've provided is probably not valid PHP code, because the
nature of the ArrayAccess interface means that data is assigned and returned
from offsetSet and offsetGet by value, so using refernces should probably not
work.
However, the when you do try this, you get an error about about post/pre
increment/decrement. I'm not sure what this refers to, but it doesn't seem to
be very descriptive.
Reproduce code:
---
data[$index] = $value;
}
public function offsetGet($index) {
return $this->data[$index];
}
public function offsetExists($index) {
return isset($this->data[$index]);
}
}
$data = new ArrayAccessImpl();
$test = 'some data';
$data['element'] = &$test;
?>
Expected result:
Unsure, probably an error message relating to the fact ArrayAc
Bug #60483 [Fbk->Opn]: stream_select only selects STDIN if present in read array
Edit report at https://bugs.php.net/bug.php?id=60483&edit=1 ID: 60483 User updated by:vmiszczak at ankama dot com Reported by:vmiszczak at ankama dot com Summary:stream_select only selects STDIN if present in read array -Status: Feedback +Status: Open Type: Bug Package:Streams related Operating System: Linux/Debian x64 PHP Version:5.3.8 Block user comment: N Private report: N New Comment: Here is a simple dummy.php that can be used as a program opened with proc_open() : http://pastebin.com/78KEpbBB Here is a way to show the problem : http://pastebin.com/aNZK6DBv If you launch this script simply using "php bug.php" and sending data by hand, no problem, it will do the job. If you launch this script using "php bug.php < lines.txt" where lines.txt is a text file containing lines, the response from the proc_opened process happens only when there is no more data on STDIN. That's not nice because I want to create a real time forwarder. I may have missed something with the buffering system but it looks like a problem. Previous Comments: [2011-12-11 15:52:23] cataphr...@php.net Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , 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. [2011-12-09 15:25:29] vmiszczak at ankama dot com Description: I'm writing a data multiplexer PHP CLI script that takes data from STDIN and dispatchs those data on programs opened with proc_open(). I'm using stream_select() to see which descriptor has data. The read array I'm using contains STDIN and the output streams from programs opened with proc_open() (the classic $pipes[1] from proc_open() descriptorspec). Those programs write on their stdout as soon as there is data on their stdin (actually those programs are PHP scripts echoing input). If STDIN remains in the read set, stream_select returns only STDIN as readable and never returns any of the programs output streams. As soon as STDIN is removed from the read set, stream_select behave normaly and selects the output streams that are ready. Expected result: I'm expecting all my ready streams to be returned, even if STDIN is present in the set. -- Edit this bug report at https://bugs.php.net/bug.php?id=60483&edit=1
Bug #60498 [Opn]: Unset obj.prop. thru ArrayAccess while iterating thru ArrayIterator cause error
Edit report at https://bugs.php.net/bug.php?id=60498&edit=1
ID: 60498
User updated by:michal dot brzuchalski at gmail dot com
Reported by:michal dot brzuchalski at gmail dot com
Summary:Unset obj.prop. thru ArrayAccess while iterating
thru ArrayIterator cause error
Status: Open
Type: Bug
Package:SPL related
-Operating System: Unix
+Operating System: FreeBSD
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
Sorry no Unix but FreeBSD
Previous Comments:
[2011-12-12 12:28:18] michal dot brzuchalski at gmail dot com
Description:
Using foreach to iterate object which implements IteratorAggregate and
ArrayAccess while iterating with iterator created by ArrayIterator($this)
causes
error in internal spl_array_update_pos when trying to unset object property
thru
arrayaccess interface:
debug:
#0 0x000802f9cd2f in spl_array_update_pos (intern=0x80847d778) at
/usr/ports/lang/php5/work/php-5.3.8/ext/spl/spl_array.c:101
101 intern->pos_h = pos->h;
[New Thread 8016041c0 (LWP 100187/httpd)]
(gdb) bt
#0 0x000802f9cd2f in spl_array_update_pos (intern=0x80847d778) at
/usr/ports/lang/php5/work/php-5.3.8/ext/spl/spl_array.c:101
#1 0x000802fa00aa in spl_array_next_no_verify (intern=0x80847d778,
aht=0x8082764a8) at /usr/ports/lang/php5/work/php-5.3.8/ext/spl/spl_array.c:858
#2 0x000802fa0566 in spl_array_it_move_forward (iter=0x808428330) at
/usr/ports/lang/php5/work/php-5.3.8/ext/spl/spl_array.c:983
#3 0x000803189a25 in ZEND_FE_FETCH_SPEC_VAR_HANDLER
(execute_data=0x807a0a268) at zend_vm_execute.h:9014
#4 0x0008031616aa in execute (op_array=0x803af3d00) at
zend_vm_execute.h:107
#5 0x00080311c307 in zend_call_function (fci=0x7fffcc50,
fci_cache=0x7fffcc20) at /usr/ports/lang/php5/work/php-
5.3.8/Zend/zend_execute_API.c:968
#6 0x000802fcd3ee in zif_call_user_func (ht=2, return_value=0x8082bd5d0,
return_value_ptr=0x0, this_ptr=0x0, return_value_used=1) at
/usr/ports/lang/php5/work/php-5.3.8/ext/standard/basic_functions.c:4772
#7 0x00080316271c in zend_do_fcall_common_helper_SPEC
(execute_data=0x807a09c48) at zend_vm_execute.h:320
#8 0x0008031636c5 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0x807a09c48) at zend_vm_execute.h:425
#9 0x0008031616aa in execute (op_array=0x807af1c50) at
zend_vm_execute.h:107
#10 0x00080312de5d in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/ports/lang/php5/work/php-5.3.8/Zend/zend.c:1236
#11 0x0008030ad482 in php_execute_script (primary_file=0x7fffe5a0) at
/usr/ports/lang/php5/work/php-5.3.8/main/main.c:2284
#12 0x000803221e45 in php_handler (r=0x803ba40a0) at
/usr/ports/lang/php5/work/php-5.3.8/sapi/apache2handler/sapi_apache2.c:669
#13 0x0043dd1a in ap_run_handler (r=0x803ba40a0) at config.c:157
#14 0x0043e643 in ap_invoke_handler (r=0x803ba40a0) at config.c:376
#15 0x0044f9d4 in ap_process_request (r=0x803ba40a0) at
http_request.c:282
#16 0x0044c7b4 in ap_process_http_connection (c=0x803afa290) at
http_core.c:190
#17 0x004475aa in ap_run_process_connection (c=0x803afa290) at
connection.c:43
#18 0x00447a2b in ap_process_connection (c=0x803afa290,
csd=0x803afa0a0)
at connection.c:190
#19 0x00456d85 in child_main (child_num_arg=37) at prefork.c:667
#20 0x00456f3c in make_child (s=0x80161c708, slot=37) at prefork.c:768
#21 0x00457629 in ap_mpm_run (_pconf=0x801615028, plog=0x801647028,
s=0x80161c708) at prefork.c:1068
#22 0x0042410b in main (argc=2, argv=0x7fffeb20) at main.c:739
(gdb) bt full
Test script:
---
class obj implements \ArrayAccess , \IteratorAggregate {
public function __construct() {
foreach(array("one" => 1, "two" => 2, "three" => 3) as $offset =>
$value) $this->{$offset} = $value;
}
public function offsetSet($offset, $value) {
$this->{$offset} = $value;
}
public function offsetExists($offset) {
return isset($this->{$offset});
}
public function offsetUnset($offset) {
unset($this->{$offset});
}
public function offsetGet($offset) {
return isset($this->{$offset}) ? $this->{$offset} : null;
}
function getIterator() {
return new \ArrayIterator($this);
}
}
$obj = new obj;
foreach($obj as $offset => $value) unset($obj[$offset]);
print_r($obj);
foreach(get_object_vars($obj) as $offset => $value) unset($obj[$offset]);
print_r($obj);
Expected result:
obj Object
(
)
obj Object
(
)
Actual result:
--
The first foreach cause an internal error second one is ok
--
Edit this bug report at https://bu
Bug #52404 [Com]: All TTF Files are invalid [ALL PHP.NET]
Edit report at https://bugs.php.net/bug.php?id=52404&edit=1 ID: 52404 Comment by: clockw...@php.net Reported by:h...@php.net Summary:All TTF Files are invalid [ALL PHP.NET] Status: Open Type: Bug Package:*General Issues PHP Version:Irrelevant Block user comment: N Private report: N New Comment: This... doesn't seem to be just those .ttf files. I grabbed http://ftp.gnome.org/pub/GNOME/sources/ttf-bitstream-vera/1.10/ and there's no differences against http://github.com/pear/Image_Text/tests/ Trying to open these; I get: imagettfbbox(): Could not read font Previous Comments: [2011-06-12 03:32:01] gozmeu at gmail dot com same here Warning: imagettftext() [function.imagettftext]: Could not find/open font in /home/gozmeu/domains/pwiguilds.com/public_html/travelcounter.php on line 40 â°PNG IHDRP Ã-q" PLTEÿÿÿÿÿÿsxÂ¥c IDAT(âcpñ,»ÃQ3GÃÃk&]7> 7¡ËFIEND®B`â with a valid or invalid ttf file :s [2010-12-07 12:51:33] h...@php.net This is not a difficult bug to fix. Anybody with commit access should be able to fix it. Can somebody fix it? Thanks. [2010-10-18 18:30:24] h...@php.net I would if I could. I don't think I have commit access to all of the ttf files on the php.net svn. [2010-07-27 01:54:48] ras...@php.net You may just have to re-import them into Subversion or something. All I did was flip the svn property so Subversion wouldn't mangle them. [2010-07-27 01:02:53] ka...@php.net Confirmed on Windows XP aswell (unreadable font files in the font viewer) Rasmus: You did this change, should it be reverted or do you have any easy fix on your mind? 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=52404 -- Edit this bug report at https://bugs.php.net/bug.php?id=52404&edit=1
Bug #55640 [Com]: Functionality of 'from' and 'len' as arrays is not implemented
Edit report at https://bugs.php.net/bug.php?id=55640&edit=1 ID: 55640 Comment by: send_no_hormel at hotmail dot com Reported by:dmitry dot sychov at gmail dot com Summary:Functionality of 'from' and 'len' as arrays is not implemented Status: Feedback Type: Bug Package:*General Issues PHP Version:5.3.8 Block user comment: N Private report: N New Comment: I agree that it'd be very nice if one could pass a buffer as the input string, with arrays of offsets, lengths, and replacement strings (which is something I need to accomplish), but per the documentation, use of arrays for the replacement, offset, and lengths are only valid if the input string itself is passed as an array, and in that case, this function will return an array, not a string. This is best categorized as a desired functionality, but it's not a bug. Previous Comments: [2011-10-10 14:45:49] rintaun at projectxero dot net Example: Expected output: ffcde Actual output: Warning: substr_replace(): Functionality of 'from' and 'len' as arrays is not implemented in - on line 2 abcde [2011-09-13 22:17:07] ka...@php.net Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , 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. [2011-09-08 10:54:13] dmitry dot sychov at gmail dot com Description: --- >From manual page: http://www.php.net/function.substr-replace%23Changelog --- I'am getting: "Functionality of 'from' and 'len' as arrays is not implemented" when trying to pass arrays as per documentation. -- Edit this bug report at https://bugs.php.net/bug.php?id=55640&edit=1
Bug #60457 [Opn]: gc_zval_possible_root SIGSEGV
Edit report at https://bugs.php.net/bug.php?id=60457&edit=1
ID: 60457
User updated by:Sjon at hortensius dot net
Reported by:Sjon at hortensius dot net
Summary:gc_zval_possible_root SIGSEGV
Status: Open
Type: Bug
Package:Scripting Engine problem
Operating System: Linux
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
I am afraid not, gc_disable() doesn't solve this segfault unfortunately
Previous Comments:
[2011-12-11 19:41:22] arekm at maven dot pl
Isn't this something similar to last comments of #40479 (there is
reproduction script there).
[2011-12-07 14:05:33] Sjon at hortensius dot net
Description:
Our application segfaults after completely finishing the request.
Unfortunately I cannot provide a script to reproduce this as it occurs in an
application consisting of many classes. I have been poking at this with gdb for
a
while, but can't find the cause for this problem.
How can I supply you with the information you need to resolve this? We can
'fix'
the problem by die()-ing in the __destruct of the class that seems to cause this
Actual result:
--
#0 0x005bf0e9 in gc_zval_possible_root (zv=0x1985580) at
/usr/src/debug/php-5.3.8/Zend/zend_gc.c:143
#1 0x005aeb28 in zend_hash_destroy (ht=0x1363998) at
/usr/src/debug/php-5.3.8/Zend/zend_hash.c:529
#2 0x005c0609 in zend_object_std_dtor (object=0x1363970) at
/usr/src/debug/php-5.3.8/Zend/zend_objects.c:45
#3 0x005c0629 in zend_objects_free_object_storage (object=0x1985580)
at
/usr/src/debug/php-5.3.8/Zend/zend_objects.c:126
#4 0x005c46d6 in zend_objects_store_free_object_storage
(objects=0x91bef8) at /usr/src/debug/php-5.3.8/Zend/zend_objects_API.c:92
#5 0x00595757 in shutdown_executor () at /usr/src/debug/php-
5.3.8/Zend/zend_execute_API.c:304
#6 0x005a1fc2 in zend_deactivate () at /usr/src/debug/php-
5.3.8/Zend/zend.c:891
#7 0x0054f2ce in php_request_shutdown (dummy=) at
/usr/src/debug/php-5.3.8/main/main.c:1640
#8 0x0062b10f in main (argc=3, argv=0x7fffea88) at
/usr/src/debug/php-5.3.8/sapi/cli/php_cli.c:1363
(gdb) frame 2
#2 0x005c0609 in zend_object_std_dtor (object=0x1363970) at
/usr/src/debug/php-5.3.8/Zend/zend_objects.c:45
45 zend_hash_destroy(object->properties);
(gdb) print *object->ce
$1 = {type = 2 '\002', name = 0xcdce30 "React_Introspection_Controller",
name_length = 30, parent = 0xcb3e78, refcount = 1, constants_updated = 1
'\001',
ce_flags = 0, function_table = {nTableSize = 32,
nTableMask = 31, nNumOfElements = 27, nNextFreeElement = 0,
pInternalPointer
= 0xcde7b0, pListHead = 0xcde7b0, pListTail = 0xce9d10, arBuckets = 0xce8fa8,
pDestructor = 0x599450 ,
persistent = 0 '\000', nApplyCount = 0 '\000', bApplyProtection = 0
'\000'},
default_properties = {nTableSize = 8, nTableMask = 7, nNumOfElements = 5,
nNextFreeElement = 0, pInternalPointer = 0xce74c8,
pListHead = 0xce74c8, pListTail = 0xce7660, arBuckets = 0xcdcf50,
pDestructor = 0x595420 <_zval_ptr_dtor>, persistent = 0 '\000', nApplyCount = 0
'\000', bApplyProtection = 0 '\000'}, properties_info = {
nTableSize = 8, nTableMask = 7, nNumOfElements = 5, nNextFreeElement = 0,
pInternalPointer = 0xce76c8, pListHead = 0xce76c8, pListTail = 0xce7850,
arBuckets = 0xcde670,
pDestructor = 0x586190 , persistent = 0 '\000',
nApplyCount = 0 '\000', bApplyProtection = 0 '\000'}, default_static_members =
{nTableSize = 8, nTableMask = 7,
nNumOfElements = 0, nNextFreeElement = 0, pInternalPointer = 0x0, pListHead
= 0x0, pListTail = 0x0, arBuckets = 0xcde6c0, pDestructor = 0x595420
<_zval_ptr_dtor>, persistent = 0 '\000',
nApplyCount = 0 '\000', bApplyProtection = 0 '\000'}, static_members = 0x0,
constants_table = {nTableSize = 8, nTableMask = 7, nNumOfElements = 0,
nNextFreeElement = 0, pInternalPointer = 0x0,
pListHead = 0x0, pListTail = 0x0, arBuckets = 0xcde710, pDestructor =
0x595420 <_zval_ptr_dtor>, persistent = 0 '\000', nApplyCount = 0 '\000',
bApplyProtection = 0 '\000'}, builtin_functions = 0x0,
constructor = 0xca2160, destructor = 0x0, clone = 0x0, __get = 0x0, __set =
0x0, __unset = 0x0, __isset = 0x0, __call = 0x0, __callstatic = 0x0, __tostring
= 0x0, serialize_func = 0x0,
unserialize_func = 0x0, iterator_funcs = {funcs = 0x0, zf_new_iterator = 0x0,
zf_valid = 0x0, zf_current = 0x0, zf_key = 0x0, zf_next = 0x0, zf_rewind =
0x0},
create_object = 0, get_iterator = 0,
interface_gets_implemented = 0, get_static_method = 0, serialize = 0,
unserialize = 0, interfaces = 0xcde368, num_interfaces = 1,
filename = 0xcde018 "[...]/Introspection/Controller.php", line_start = 2,
line_end = 82, doc
Bug #60475 [Opn]: Assignments of $this in some implicit __toString contexts get broken
Edit report at https://bugs.php.net/bug.php?id=60475&edit=1 ID: 60475 User updated by:ctrahey at rubicon dot com Reported by:ctrahey at rubicon dot com Summary:Assignments of $this in some implicit __toString contexts get broken Status: Open Type: Bug Package:Class/Object related Operating System: Windows 7, Ubuntu 10 -PHP Version:5.3.8 +PHP Version:5.3.8, 5.4.0RC2, 5.5.0-dev Block user comment: N Private report: N New Comment: Tested against trunk (5.5.0-dev, revision 320923) compiled on Ubuntu 10.04.3 with same (incorrect) result. Previous Comments: [2011-12-08 16:58:08] ctrahey at rubicon dot com Description: Tested with php 5.3.8 on Windows 7, 5.4.0RC2 Win32, and 5.4.0RC2 (cli) on Ubuntu 10.04.3 When an object is implicitly used as a string when passed to some php functions, __toString is called as expected, but any assignments of $this from within __toString are eventually broken and point instead to the string that gets returned. This behavior occurs only in some php functions, and never if you cast as string while passing into the functions. This behavior has been observed when passing objects into at least these php functions: str_replace, preg_replace, preg_match_all, sprintf. There are many php string functions that do not behave this way (they allow __toString-created references to $this persist as references to the object). For extra fun, play around with htmlspecialchars, echo-ing the output... I suspect that's a whole different issue, but related (possible memory leak there). Test script: --- https://bugs.php.net/bug.php?id=60475&edit=1
Bug #52404 [Com]: All TTF Files are invalid [ALL PHP.NET]
Edit report at https://bugs.php.net/bug.php?id=52404&edit=1
ID: 52404
Comment by: h...@php.net
Reported by:h...@php.net
Summary:All TTF Files are invalid [ALL PHP.NET]
Status: Open
Type: Bug
Package:*General Issues
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
Comment:
I was unable to replicate clockwerx's findings.
According to my results there is only a problem with the fonts changed by
rasmus
in r284292.
New test script:
https://github.com/pear/Image_Text/raw/master/tests/Vera.ttf
$fonts[]='fonts/Vera.ttf';
//from http://ftp.gnome.org/pub/GNOME/sources/ttf-bitstream-vera/1.10/ttf-
bitstream-vera-1.10.zip
$fonts[] = 'fonts/ttf-bitstream-vera-1.10/Vera.ttf';
foreach ($fonts as $font) {
$read = file_exists($font)?'Yes':'No';
echo "Does font '$font' exist? $read\n";
$read = is_readable($font)?'Yes':'No';
echo "Is font '$font' readable? $read\n";
$test = @imagettfbbox(1, 1, $font, 1)?'Yes':'No';
echo "Is font '$font' valid? $test\n";
echo "What PHP version? ".phpversion()."\n";
echo "\n";
}
?>
Results:
Here's the results of that:
Does font 'fonts/Vera.ttf' exist? Yes
Is font 'fonts/Vera.ttf' readable? Yes
Is font 'fonts/Vera.ttf' valid? No
What PHP version? 5.3.4
Does font 'fonts/ttf-bitstream-vera-1.10/Vera.ttf' exist? Yes
Is font 'fonts/ttf-bitstream-vera-1.10/Vera.ttf' readable? Yes
Is font 'fonts/ttf-bitstream-vera-1.10/Vera.ttf' valid? Yes
What PHP version? 5.3.4
Conclusion:
In r284292 rasmus made a change which changed the EOL of these font files.
These
files use a "Mixed" EOL while the original files use just Unix type EOL.
Solution:
Roll back r284292.
Previous Comments:
[2011-12-12 13:58:40] clockw...@php.net
This... doesn't seem to be just those .ttf files. I grabbed
http://ftp.gnome.org/pub/GNOME/sources/ttf-bitstream-vera/1.10/ and there's no
differences against http://github.com/pear/Image_Text/tests/
Trying to open these; I get:
imagettfbbox(): Could not read font
[2011-06-12 03:32:01] gozmeu at gmail dot com
same here
Warning: imagettftext() [function.imagettftext]: Could not find/open font in
/home/gozmeu/domains/pwiguilds.com/public_html/travelcounter.php on line 40
â°PNG IHDRP Ã-q"
PLTEÿÿÿÿÿÿsxÂ¥c IDAT(âcpñ,»ÃQ3GÃÃk&]7> 7¡ËFIEND®B`â
with a valid or invalid ttf file :s
[2010-12-07 12:51:33] h...@php.net
This is not a difficult bug to fix. Anybody with commit access should be able
to fix it.
Can somebody fix it?
Thanks.
[2010-10-18 18:30:24] h...@php.net
I would if I could.
I don't think I have commit access to all of the ttf files on the php.net svn.
[2010-07-27 01:54:48] ras...@php.net
You may just have to re-import them into Subversion or something. All I did
was
flip the svn property so Subversion wouldn't mangle them.
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=52404
--
Edit this bug report at https://bugs.php.net/bug.php?id=52404&edit=1
[PHP-BUG] Req #60502 [NEW]: uses bundled web server for standard/http tests
From: mattficken Operating system: Windows PHP version: 5.4.0RC3 Package: Testing related Bug Type: Feature/Change Request Bug description:uses bundled web server for standard/http tests Description: HTTP tests originally use its own internally implemented web server. This patch has them use the CLI web server instead. Note: 3 or 4 of the 5 tests still have mismatched output (fail). -- Edit bug report at https://bugs.php.net/bug.php?id=60502&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60502&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60502&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60502&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60502&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60502&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60502&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60502&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60502&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60502&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60502&r=support Expected behavior: https://bugs.php.net/fix.php?id=60502&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60502&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60502&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60502&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60502&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60502&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60502&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60502&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60502&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60502&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60502&r=mysqlcfg
[PHP-BUG] Bug #60503 [NEW]: SAPI Continuity is outdated.
From: Operating system: PHP version: trunk-SVN-2011-12-12 (SVN) Package: *General Issues Bug Type: Bug Bug description:SAPI Continuity is outdated. Description: SAPI Continuity is outdated. SVN: /php/php-src/trunk/sapi/continuity/ VIEWVC: http://svn.php.net/viewvc/php/php-src/trunk/sapi/continuity/ Author (Alex Leigh ) not reachable. domain down. in /php/php-src/trunk/sapi/continuity/capi.c line 19: /* For more information on Continuity: http://www.ashpool.com/ */ ashpool.com domain down. i'm suggesting removing the directory from trunk. act appropriately, regards jens -- Edit bug report at https://bugs.php.net/bug.php?id=60503&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60503&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60503&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60503&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60503&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60503&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60503&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60503&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60503&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60503&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60503&r=support Expected behavior: https://bugs.php.net/fix.php?id=60503&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60503&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60503&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60503&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60503&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60503&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60503&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60503&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60503&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60503&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60503&r=mysqlcfg
[PHP-BUG] Bug #60504 [NEW]: PHP Warning: Module 'ssh2' already loaded in Unknown on line 0
From: Operating system: Linux - Ubuntu 11.10 PHP version: 5.3SVN-2011-12-12 (SVN) Package: Dynamic loading Bug Type: Bug Bug description:PHP Warning: Module 'ssh2' already loaded in Unknown on line 0 Description: Installed every version of PHP from SVN/Snapshots: # php -m | grep ssh2 PHP Warning: Module 'ssh2' already loaded in Unknown on line 0 ssh2 When you remove extension=ssh2.so from the php.ini file: # php -m | grep ssh2 No modules are returned. The module is loaded only once in the config when the already loaded error message is returned. A find / -name "*" -print | xargs grep "ssh2.so" Returns the binary files in ~/ssh2-0.11.3 and /usr/local/php-5.3/lib/php/20090626/ as well as the /etc/php.ini file. Configuration File (php.ini) Path => /etc Loaded Configuration File => /etc/php.ini Scan this dir for additional .ini files => /etc Additional .ini files parsed => /etc/php.ini Only one file exists, and confirmed PHP is loading only one file. Backtrace did not result in any useful information. Test script: --- Any code, simply, php -v Expected result: No message. Actual result: -- PHP Warning: Module 'ssh2' already loaded in Unknown on line 0 -- Edit bug report at https://bugs.php.net/bug.php?id=60504&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60504&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60504&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60504&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60504&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60504&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60504&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60504&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60504&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60504&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60504&r=support Expected behavior: https://bugs.php.net/fix.php?id=60504&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60504&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60504&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60504&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60504&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60504&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60504&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60504&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60504&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60504&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60504&r=mysqlcfg
Req #60341 [Com]: SplFixedArray should throw specific exceptions.
Edit report at https://bugs.php.net/bug.php?id=60341&edit=1 ID: 60341 Comment by: morrison dot levi at gmail dot com Reported by:morrison dot levi at gmail dot com Summary:SplFixedArray should throw specific exceptions. Status: Assigned Type: Feature/Change Request Package:SPL related Operating System: irrelevant PHP Version:5.3 Assigned To:colder Block user comment: N Private report: N New Comment: The proposed patch addresses all the issues I have submitted. However, it is important to note that it breaks backwards compatibility in these areas: - Passing an Object as a key will throw InvalidArgumentException which does not inherit from RuntimeException. - Passing a key that does not represent an int will throw InvalidArgumentException instead of RuntimeException. All other changes are backwards compatible (I believe. Still new to patching PHP). Previous Comments: [2011-11-22 21:56:39] morrison dot levi at gmail dot com Note that the proposed patch isn't perfect. Using a string index that is not numeric will throw OutOfBoundsException instead of InvalidArgumentException. I haven't figured out how to do that in C yet, hopefully I'll figure it out soon or someone else knows how and can submit the patch. [2011-11-22 19:46:59] morrison dot levi at gmail dot com I have a patch nearly ready for this. It's at home, not on this machine, but I noticed that it got assigned, so I thought it was worth mentioning. Also, I think that: $fixedArray[] = ''; Should throw OverflowException instead of RuntimeException. See http://stackoverflow.com/questions/8219158/correct-exception-type-for-adding-to- an-array-when-it-isnt-allowed and http://php.net/manual/en/class.overflowexception.php [2011-11-21 17:36:11] morrison dot levi at gmail dot com This should really be titled 'SplFixedArray should throw specific exceptions' [2011-11-19 21:31:32] morrison dot levi at gmail dot com Description: SplFixedArray thankfully throws exceptions when you try to do incorrect things with indices. However, the types of exceptions are just too generic. If I give the wrong type of index, that's a logic error (I'd expect InvalidArgument or at least something that inherits from LogicError to be thrown). If I give an index that's that's a valid type but doesn't exist, I'd expect an OutOfBoundsException to be thrown. Instead I get a generic RuntimeException. I should expect because they are very different problems that I would at least get a distinguishing message between the two. However, I get the same descriptions: 'Index invalid or out of range'. The very message suggests they should be different exceptions. The first fix would sort-of break backwards compatibility: throw an InvalidArgumentException for things of the wrong type. The second fix, throw OutOfBoundsException on incorrect index, could be implemented and keep backwards compatibility. Test script: --- $fa = new SplFixedArray(1); $fa[new StdClass()]; //expect InvalidArgumentException or perhaps OutOfRangeException $fa[2] = 'james'; // expect OutOfBoundsException Expected result: I expect $fa[new StdClass] to throw an InvalidArgumentException, not a RuntimeException I expect $fa['2'] to throw OutOfBoundsException not a RuntimeException. Actual result: -- Both throw RuntimeExceptions. -- Edit this bug report at https://bugs.php.net/bug.php?id=60341&edit=1
[PHP-BUG] Bug #60505 [NEW]: When a script exits due to write/flush failure, php cli still returns 0
From: Operating system: Platform agnostic PHP version: 5.3.8 Package: *General Issues Bug Type: Bug Bug description:When a script exits due to write/flush failure, php cli still returns 0 Description: Here is the scenario that causes the issue: In php.ini, ignore_user_abort=0 Have a PHP script that writes to standard out using 'echo'. The php script is launched by a shell script that redirects standard out to a file. If the partition/disk that receives the standard out file fills up while the script is running, eventually the 'echo' will cause the script to bail out because PHP was unable to write to the output stream due to the disk being full. However, the php process will exit with error code 0 even though the script never completed. The root cause is in main.c php_execute_script. If an error occurs and zend_execute_scripts returns via longjmp, both retval and EG(exit_status) will still both be 0. This makes it difficult to ascertain whether or not your script ran successfully. The obvious fix seems to be to add a zend_catch block that would set retval and EG(exit_status) to FAILURE, but I am unsure if that would have any unwanted impact. This fix doesn't make the situation any easier to debug, but it at least allows php to exit with a proper error code. Test script: --- Expected result: Expect the script to either run to completion or that PHP would exit with an error Actual result: -- In the case of the above script, the script bails out without running to completion, but an error code of 0 is returned to the parent process. -- Edit bug report at https://bugs.php.net/bug.php?id=60505&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60505&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60505&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60505&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60505&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60505&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60505&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60505&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60505&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60505&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60505&r=support Expected behavior: https://bugs.php.net/fix.php?id=60505&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60505&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60505&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60505&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60505&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60505&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60505&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60505&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60505&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60505&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60505&r=mysqlcfg
Req #46549 [Com]: translating the function list manual into Arabic
Edit report at https://bugs.php.net/bug.php?id=46549&edit=1 ID: 46549 Comment by: jakoch at web dot de Reported by:flashpack at gmail dot com Summary:translating the function list manual into Arabic Status: Open Type: Feature/Change Request Package:Feature/Change Request Operating System: Windows XP PHP Version:5.3.0alpha2 Block user comment: N Private report: N New Comment: if you want to help the arabic php community, then you might consider using the Online Documentation Editor (https://edit.php.net/) for translating the function list pages into arabic language. Previous Comments: [2008-11-11 21:07:26] flashpack at gmail dot com Description: i'm intending to translate the function list manual into Arabic in a seperated site which will be especially for this translation so i'm asking your permission first -- Edit this bug report at https://bugs.php.net/bug.php?id=46549&edit=1
[PHP-BUG] Bug #60506 [NEW]: extra warnings messages for dir tests
From: mattficken Operating system: Windows PHP version: 5.4.0RC3 Package: Testing related Bug Type: Bug Bug description:extra warnings messages for dir tests Description: on windows (win2008r2 sp1), extra warning messages are added to the output of scandir-variation6-win32 -- Edit bug report at https://bugs.php.net/bug.php?id=60506&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60506&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60506&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60506&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60506&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60506&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60506&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60506&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60506&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60506&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60506&r=support Expected behavior: https://bugs.php.net/fix.php?id=60506&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60506&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60506&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60506&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60506&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60506&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60506&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60506&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60506&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60506&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60506&r=mysqlcfg
Req #51565 [Com]: PHP Spl(Binary)Tree Structure
Edit report at https://bugs.php.net/bug.php?id=51565&edit=1 ID: 51565 Comment by: morrison dot levi at gmail dot com Reported by:clintonxa at gmail dot com Summary:PHP Spl(Binary)Tree Structure Status: Open Type: Feature/Change Request Package:SPL related Operating System: All PHP Version:5.3.2 Block user comment: N Private report: N New Comment: Honestly, heaps are just a representation of trees. I know that particular benefits are associated with trees and others with heaps, but generally speaking you could probably just use a heap. Previous Comments: [2010-04-15 23:35:49] clintonxa at gmail dot com Description: SPL has so far included several very useful structures, and another basic one that we would benefit from is a tree structure. It is possible to use an array for this now, but an SPL class would be beneficial. Test script: --- add(4); $btree->add(10); $btree->add(2); // Well, I'm not sure on how PHP devs would implement the tree's methods. // But a quick browse through any intro to OOP guide will give some ideas. ?> -- Edit this bug report at https://bugs.php.net/bug.php?id=51565&edit=1
Bug #60465 [Opn->Ana]: file_get_contents doesn't stop retrieving data
Edit report at https://bugs.php.net/bug.php?id=60465&edit=1 ID: 60465 Updated by: larue...@php.net Reported by:dbc334 at gmail dot com Summary:file_get_contents doesn't stop retrieving data -Status: Open +Status: Analyzed Type: Bug Package:HTTP related Operating System: Windows PHP Version:5.3.8 Block user comment: N Private report: N New Comment: it seems improper to use php_steam_eof while parsing header in php_stream_url_wrap_http_ex. Previous Comments: [2011-12-08 00:22:33] dbc334 at gmail dot com Description: When I send request to script connection_close.php from web browser (Internet Explorer, Firefox or Opera), it returns only "1". connection_close.php is run on Apache 2.2 web server. But when I execute this script from other php file via file_get_contents (eg. do_request.php), it returns "12". Test script: --- file connection_close.php: file do_request.php: http://web_server_path/connection_close.php";); ?> Expected result: Executing do_request.php should return "1". Actual result: -- do_request.php returns "12". -- Edit this bug report at https://bugs.php.net/bug.php?id=60465&edit=1
Bug #60506 [Opn]: extra warnings messages for dir tests
Edit report at https://bugs.php.net/bug.php?id=60506&edit=1 ID: 60506 Updated by: paj...@php.net Reported by:mattfic...@php.net Summary:extra warnings messages for dir tests Status: Open Type: Bug Package:Testing related Operating System: Windows PHP Version:5.4.0RC3 Block user comment: N Private report: N New Comment: Please add a skipif section and duplicate the test instead, as these tests passes on other versions. Previous Comments: [2011-12-13 00:57:00] mattfic...@php.net Description: on windows (win2008r2 sp1), extra warning messages are added to the output of scandir-variation6-win32 -- Edit this bug report at https://bugs.php.net/bug.php?id=60506&edit=1
