[PHP-BUG] Bug #60497 [NEW]: PHP Destructor not called after object save
From:
Operating system: Ubuntu
PHP version: 5.3.8
Package: *General Issues
Bug Type: Bug
Bug description:PHP Destructor not called after object save
Description:
After saving an object in __destruct, __destruct is not called again.
Test script:
---
class ClassSave {
function __destruct(){
global $test;
$test = $this;
echo "Destruct\r\n";
}
}
echo "1: ";
new ClassSave();
echo "2: ";
$test = null;
unset($test);
echo "End\r\n";
Expected result:
1: Destruct
2: Destruct
End
Actual result:
--
1: Destruct
2: End
--
Edit bug report at https://bugs.php.net/bug.php?id=60497&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60497&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60497&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60497&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60497&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60497&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60497&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60497&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60497&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60497&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60497&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60497&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60497&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60497&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60497&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60497&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60497&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60497&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60497&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60497&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60497&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60497&r=mysqlcfg
[PHP-BUG] Bug #60496 [NEW]: PHP cli-server does not report syntax errors in the router
From: Operating system: Mac OS X 10.7.2 (Lion) PHP version: 5.4.0RC3 Package: Built-in web server Bug Type: Bug Bug description:PHP cli-server does not report syntax errors in the router Description: Even when enabled in a router php's built-in webserver does not report any errors coming from the router or included scripts. Note that it's currently necessary to do php execution from a router using a require instead of by using `return false;` because of virtual paths where a "/fake-nonexistent-path" may be desired to be routed to "/somescript.php" instead of attempting to serve the file "fake-nonexistent-path" in the docroot. The api does not seem to have a way to `return false;` telling the server to serve a completely different file so the only way to have this behavior is to use a require call. Obviously it would also be nice for errors to be reported simply so that you can fix bugs in the router itself as well. Test script: --- # ./router.php https://bugs.php.net/bug.php?id=60496&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60496&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60496&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60496&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60496&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60496&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60496&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60496&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60496&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60496&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60496&r=support Expected behavior: https://bugs.php.net/fix.php?id=60496&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60496&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60496&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60496&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60496&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60496&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60496&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60496&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60496&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60496&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60496&r=mysqlcfg
Bug #60494 [Opn]: iconv_mime_decode does ignore special characters
Edit report at https://bugs.php.net/bug.php?id=60494&edit=1 ID: 60494 User updated by:bin at webcandy dot at Reported by:bin at webcandy dot at Summary:iconv_mime_decode does ignore special characters Status: Open Type: Bug Package:ICONV related Operating System: Windows 7 PHP Version:Irrelevant Block user comment: N Private report: N New Comment: Expected result should probably have 2 bytes as I expect it to be UTF-8 when using iconv.output_encoding = UTF-8 Exptected result: string(2) "ä" string(2) "ö" string(2) "Ã" Previous Comments: [2011-12-11 21:12:35] bin at webcandy dot at Description: If the string $text passed to iconv_mime_decode($text) does contain special characters (tested with ä, ü and Ã), it will just return an empty character for these characters. In my opinion it iconv_mime_decode should leave special characters as they are as long as they're not encoded via Q-encoding. Tested on Windows 7 and Debian. iconv.output_encoding is set to "UTF-8" Test script: --- Expected result: string(1) "ä" string(1) "ö" string(1) "Ã" Actual result: -- string(0) "" string(0) "" string(0) "" -- Edit this bug report at https://bugs.php.net/bug.php?id=60494&edit=1
[PHP-BUG] Bug #60494 [NEW]: iconv_mime_decode does ignore special characters
From: Operating system: Windows 7 PHP version: Irrelevant Package: ICONV related Bug Type: Bug Bug description:iconv_mime_decode does ignore special characters Description: If the string $text passed to iconv_mime_decode($text) does contain special characters (tested with ä, ü and Ã), it will just return an empty character for these characters. In my opinion it iconv_mime_decode should leave special characters as they are as long as they're not encoded via Q-encoding. Tested on Windows 7 and Debian. iconv.output_encoding is set to "UTF-8" Test script: --- Expected result: string(1) "ä" string(1) "ö" string(1) "Ã" Actual result: -- string(0) "" string(0) "" string(0) "" -- Edit bug report at https://bugs.php.net/bug.php?id=60494&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60494&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60494&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60494&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60494&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60494&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60494&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60494&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60494&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60494&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60494&r=support Expected behavior: https://bugs.php.net/fix.php?id=60494&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60494&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60494&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60494&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60494&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60494&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60494&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60494&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60494&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60494&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60494&r=mysqlcfg
Bug #60455 [Csd]: stream_get_line reports two lines instead of one
Edit report at https://bugs.php.net/bug.php?id=60455&edit=1 ID: 60455 Updated by: cataphr...@php.net Reported by:jakub dot lopuszanski at nasza-klasa dot pl Summary:stream_get_line reports two lines instead of one Status: Closed Type: Bug Package:Streams related Operating System: linux PHP Version:Irrelevant Assigned To:cataphract Block user comment: N Private report: N New Comment: Fixed in SVN. Thanks. Previous Comments: [2011-12-11 21:07:57] cataphr...@php.net Automatic comment from SVN on behalf of cataphract Revision: http://svn.php.net/viewvc/?view=revision&revision=320876 Log: - Fixed bug #60455: stream_get_line misbehaves if EOF is not detected together with the last read. [2011-12-07 10:01:42] jakub dot lopuszanski at nasza-klasa dot pl Description: If a file consists of single line, and you use a straightforward loop over all lines using stream_get_line, you may be suprised that there are actually two lines, where the second one is empty string. This is inconsistent with the case where you actually have two lines in a file, and stream_get_line reports two lines as expected without the additional empty third line. This inconsistency makes it quite difficult to write a correct code. Test script: --- I have three files: lopuszanski@vanisoft:~$ hexdump -C one_line.txt 61 0a |a.| 0002 lopuszanski@vanisoft:~$ hexdump -C two_lines.txt 61 0a 62 0a |a.b.| 0004 lopuszanski@vanisoft:~$ hexdump -C two_lines_one_of_which_is_empty.txt 61 0a 0a |a..| 0003 And the following script: lopuszanski@vanisoft:~$ cat test.php Expected result: lopuszanski@vanisoft:~$ php test.php < one_line.txt string(1) "a" lopuszanski@vanisoft:~$ php test.php < two_lines.txt string(1) "a" string(1) "b" lopuszanski@vanisoft:~$ php test.php < two_lines_one_of_which_is_empty.txt string(1) "a" string(0) "" Actual result: -- lopuszanski@vanisoft:~$ php test.php < one_line.txt string(1) "a" string(0) "" lopuszanski@vanisoft:~$ php test.php < two_lines.txt string(1) "a" string(1) "b" lopuszanski@vanisoft:~$ php test.php < two_lines_one_of_which_is_empty.txt string(1) "a" string(0) "" -- Edit this bug report at https://bugs.php.net/bug.php?id=60455&edit=1
Bug #60455 [Opn->Csd]: stream_get_line reports two lines instead of one
Edit report at https://bugs.php.net/bug.php?id=60455&edit=1 ID: 60455 Updated by: cataphr...@php.net Reported by:jakub dot lopuszanski at nasza-klasa dot pl Summary:stream_get_line reports two lines instead of one -Status: Open +Status: Closed Type: Bug Package:Streams related Operating System: linux PHP Version:Irrelevant -Assigned To: +Assigned To:cataphract Block user comment: N Private report: N Previous Comments: [2011-12-11 21:07:57] cataphr...@php.net Automatic comment from SVN on behalf of cataphract Revision: http://svn.php.net/viewvc/?view=revision&revision=320876 Log: - Fixed bug #60455: stream_get_line misbehaves if EOF is not detected together with the last read. [2011-12-07 10:01:42] jakub dot lopuszanski at nasza-klasa dot pl Description: If a file consists of single line, and you use a straightforward loop over all lines using stream_get_line, you may be suprised that there are actually two lines, where the second one is empty string. This is inconsistent with the case where you actually have two lines in a file, and stream_get_line reports two lines as expected without the additional empty third line. This inconsistency makes it quite difficult to write a correct code. Test script: --- I have three files: lopuszanski@vanisoft:~$ hexdump -C one_line.txt 61 0a |a.| 0002 lopuszanski@vanisoft:~$ hexdump -C two_lines.txt 61 0a 62 0a |a.b.| 0004 lopuszanski@vanisoft:~$ hexdump -C two_lines_one_of_which_is_empty.txt 61 0a 0a |a..| 0003 And the following script: lopuszanski@vanisoft:~$ cat test.php Expected result: lopuszanski@vanisoft:~$ php test.php < one_line.txt string(1) "a" lopuszanski@vanisoft:~$ php test.php < two_lines.txt string(1) "a" string(1) "b" lopuszanski@vanisoft:~$ php test.php < two_lines_one_of_which_is_empty.txt string(1) "a" string(0) "" Actual result: -- lopuszanski@vanisoft:~$ php test.php < one_line.txt string(1) "a" string(0) "" lopuszanski@vanisoft:~$ php test.php < two_lines.txt string(1) "a" string(1) "b" lopuszanski@vanisoft:~$ php test.php < two_lines_one_of_which_is_empty.txt string(1) "a" string(0) "" -- Edit this bug report at https://bugs.php.net/bug.php?id=60455&edit=1
Bug #60457 [Com]: gc_zval_possible_root SIGSEGV
Edit report at https://bugs.php.net/bug.php?id=60457&edit=1
ID: 60457
Comment by: arekm at maven dot pl
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:
Isn't this something similar to last comments of #40479 (there is
reproduction script there).
Previous Comments:
[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_comment = 0x0,
doc_comment_len = 0, module = 0x0}
--
Edit this bug report at https://bugs.php.net/bug.php?id=6045
Bug #40479 [Com]: zend_mm_heap corrupted
Edit report at https://bugs.php.net/bug.php?id=40479&edit=1
ID: 40479
Comment by: arekm at maven dot pl
Reported by:rrossi at maggioli dot it
Summary:zend_mm_heap corrupted
Status: Feedback
Type: Bug
Package:Reproducible crash
Operating System: Suse Linux 9.0
PHP Version:5.2.1
Block user comment: N
Private report: N
New Comment:
"f dot ardelian at gmail dot com" test case works on php 5.4rc2, too (php
cli segfaults)
Previous Comments:
[2011-11-23 11:30:36] utnalove at yahoo dot it
Hello, I use Wordpress. I am hosted in home.pl which uses IdeaWebServer instead
of Apache. Very often when I enable whatever cache plugin I get the
"zend_mm_heap corrupted" error.
I have also a hosting in the USA with Apache and the same PHP and MySql
versions. If I backup both data and database and restore it in the Apache
server
I can use my caching plugins without issues because the "zend_mm_heap
corrupted"
error never appears.
Home.pl says that this is a PHP issue and it is not connected with their non-
Apache server.
What's your opinion in that? Is it a PHP issue or a hosting issue?
Thank you
[2011-11-02 10:34:30] from dot php dot net at brainbox dot cz
I can reproduce the bug on Microsoft Windows XP SP3, with latest official PHP
5.3.8 NTS build.
When we run script from "f dot ardelian at gmail dot com", PHP does not output
"zend_mm_heap corrupted", but right after displaying the "If you see thisâ¦"
line CRASHES.
However, I found that when I call "gc_disable();" before script end, it
finishes successfully. This helped me run the test script without problems, but
didn't solve the issue in my other scripts.
_guid = self::$maxGuid++] = $this;
}
public function __destruct() {
unset(self::$world[$this->_guid]);
}
}
for ($i = 0; $i < OBJECT_COUNT; ++$i) {
new Object();
}
// You probably won't see this because of the "zend_mm_heap corrupted"
echo 'If you see this, try to increase OBJECT_COUNT to 100,000';
gc_disable(); // ADDED - works for me - PHP does not crash
?>
[2011-10-17 20:24:44] rob dot spekschoor at gmail dot com
problem solved by compiling apache with prefork. Somehow Apache worker MPM +
PHP 5.2 works fine but Apache worker MPM + PHP 5.3 fails terribly. Prefork
seems stable
[2011-10-05 20:08:42] rob dot spekschoor at gmail dot com
I can also reproduce with script from 'f dot ardelian at gmail dot com' this
error on:
php --version
PHP 5.3.8-pl0-gentoo (cli) (built: Oct 4 2011 10:42:38)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies
[2011-09-26 08:00:03] laacz at laacz dot lv
Second this by running code, provided by "f dot ardelian at gmail dot com" at
2011-08-31 07:49 UTC:
# php -q zend_mm_heap_corrupted.php
If you see this, try to increase OBJECT_COUNT to 100,000zend_mm_heap corrupted
# php --version
PHP 5.3.8 (cli) (built: Aug 29 2011 14:48:33)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies
with eAccelerator v0.9.6.1, Copyright (c) 2004-2010 eAccelerator, by
eAccelerator
with Xdebug v2.1.2, Copyright (c) 2002-2011, by Derick Rethans
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=40479
--
Edit this bug report at https://bugs.php.net/bug.php?id=40479&edit=1
Req #8897 [Opn->Csd]: Significant portions of the InterBase API have no PHP representation.
Edit report at https://bugs.php.net/bug.php?id=8897&edit=1 ID: 8897 Updated by: mar...@php.net Reported by:awjunkmail at anduin dot com Summary:Significant portions of the InterBase API have no PHP representation. -Status: Open +Status: Closed Type: Feature/Change Request Package:InterBase related Operating System: All PHP Version:4.0.3pl1 -Assigned To: +Assigned To:mariuz Block user comment: N Private report: N New Comment: We are sorry, but we can not support PHP 4 related problems anymore. Momentum is gathering for PHP 6, and we think supporting PHP 4 will lead to a waste of resources which we want to put into getting PHP 6 ready. Previous Comments: [2011-12-11 19:12:03] mar...@php.net Ok then i will close it the bug is for php4 only [2011-09-11 15:59:52] lester at lsces dot co dot uk This is a very old situation. PHP5 interbase driver supports everything listed, but was never backported to PHP4, so suggest this is just closed? [2001-01-25 04:30:40] awjunkmail at anduin dot com InterBase has four functions for executing SQL commands. The current PHP wrappers use one: isc_dsql_execute. If you had to choose which of the prepared execute functions to wrap isc_dsql_execute2() would have been a better choice. This would have allowed things like EXECUTE PROCEDURE in addition to all the functionality of isc_dsql_execute(). It would also remove the need to use SELECT to run a procedure. More importantly is that isc_dsql_execute_immediate() and isc_dsql_exec_immed2() are not exposed in any form. Along the same lines functions for managing users would be nice as well (isc_add/delete/modify_user). -- Edit this bug report at https://bugs.php.net/bug.php?id=8897&edit=1
Req #8897 [Com]: Significant portions of the InterBase API have no PHP representation.
Edit report at https://bugs.php.net/bug.php?id=8897&edit=1 ID: 8897 Comment by: mar...@php.net Reported by:awjunkmail at anduin dot com Summary:Significant portions of the InterBase API have no PHP representation. Status: Open Type: Feature/Change Request Package:InterBase related Operating System: All PHP Version:4.0.3pl1 Block user comment: N Private report: N New Comment: Ok then i will close it the bug is for php4 only Previous Comments: [2011-09-11 15:59:52] lester at lsces dot co dot uk This is a very old situation. PHP5 interbase driver supports everything listed, but was never backported to PHP4, so suggest this is just closed? [2001-01-25 04:30:40] awjunkmail at anduin dot com InterBase has four functions for executing SQL commands. The current PHP wrappers use one: isc_dsql_execute. If you had to choose which of the prepared execute functions to wrap isc_dsql_execute2() would have been a better choice. This would have allowed things like EXECUTE PROCEDURE in addition to all the functionality of isc_dsql_execute(). It would also remove the need to use SELECT to run a procedure. More importantly is that isc_dsql_execute_immediate() and isc_dsql_exec_immed2() are not exposed in any form. Along the same lines functions for managing users would be nice as well (isc_add/delete/modify_user). -- Edit this bug report at https://bugs.php.net/bug.php?id=8897&edit=1
Req #54150 [Com]: Enhance phpinfo output for pdo_firebird
Edit report at https://bugs.php.net/bug.php?id=54150&edit=1 ID: 54150 Comment by: mar...@php.net Reported by:preeves at ibphoenix dot com Summary:Enhance phpinfo output for pdo_firebird Status: Assigned Type: Feature/Change Request Package:PDO related PHP Version:5.3.5 Assigned To:mariuz Block user comment: N Private report: N New Comment: I will check it and i will apply it to 5.3,5.4 and trunk Previous Comments: [2011-03-03 16:10:05] preeves at ibphoenix dot com Description: The phpinfo output for the pdo_firebird driver is a bit sparse. I've lifted the code from the interbase driver so that at least we will now output version info. It is not a lot, but at least it makes the driver seem a little more loved. -- Edit this bug report at https://bugs.php.net/bug.php?id=54150&edit=1
Bug #60406 [Csd->Bgs]: file_exists() fopen() problems with URL (http)
Edit report at https://bugs.php.net/bug.php?id=60406&edit=1
ID: 60406
Updated by: cataphr...@php.net
Reported by:simon dot georget at gmail dot com
Summary:file_exists() fopen() problems with URL (http)
-Status: Closed
+Status: Bogus
Type: Bug
Package:*General Issues
Operating System: ubuntu oneiric
PHP Version:Irrelevant
Block user comment: N
Private report: N
Previous Comments:
[2011-11-30 09:35:36] simon dot georget at gmail dot com
Hi reeze,
Many thanks for your reply. It's clear.
Sorry for the inadapted bug report. Close it now.
[2011-11-30 02:43:50] reeze dot xia at gmail dot com
Hi, simon:
@see http://docs.php.net/manual/en/wrappers.http.php
The Options "Wrapper Summary" section the http wrapper doesn't support stat()
and file_exists() rely on that. http stream wrapper support fopen.
file_exits() dones't support all the enabled stream wrappers.
You can visit http://cn2.php.net/manual/en/wrappers.php for a full supported
streams.
thanks.
[2011-11-29 17:01:04] simon dot georget at gmail dot com
**Actually fopen() works correctly!!!**
if(!fopen('http://maps.googleapis.com/maps/api/js?sensor=false', 'r')) {
echo 'Problem loading the url';
} else {
echo 'it works!';
}
returns it works!
[2011-11-29 10:41:42] simon dot georget at gmail dot com
Description:
I'm using the following version of PHP on ubuntu : PHP Version 5.3.6-13ubuntu3.2
and have problems checking if an url exists with both fopen() and file_exists()
functions.
print_r(stream_get_wrappers()); returns :
Array ( [0] => https [1] => ftps [2] => compress.zlib [3] => compress.bzip2 [4]
=> php [5] => file [6] => glob [7] => data [8] => http [9] => ftp [10] => phar
[11] => zip )
(test script is above)
Test script:
---
if(!file_exists('http://maps.googleapis.com/maps/api/js?sensor=false')) {
echo 'Problem loading the url';
} else {
echo 'it works!';
}
Expected result:
it works!
Actual result:
--
Problem loading the url
--
Edit this bug report at https://bugs.php.net/bug.php?id=60406&edit=1
Req #60482 [Opn]: Add cookies to stream_context
Edit report at https://bugs.php.net/bug.php?id=60482&edit=1 ID: 60482 Updated by: cataphr...@php.net Reported by:jille at hexon dot cx Summary:Add cookies to stream_context Status: Open Type: Feature/Change Request Package:Streams related Operating System: n/a PHP Version:Irrelevant Block user comment: N Private report: N New Comment: It is trivial to add cookies by adding Cookie: headers. Previous Comments: [2011-12-09 14:48:07] jille at hexon dot cx Description: I think cookies would be a usable addition to the possibilities of stream-context's. -- Edit this bug report at https://bugs.php.net/bug.php?id=60482&edit=1
Bug #60483 [Opn->Fbk]: 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 Updated by: cataphr...@php.net Reported by:vmiszczak at ankama dot com Summary:stream_select only selects STDIN if present in read array -Status: Open +Status: Feedback Type: Bug Package:Streams related Operating System: Linux/Debian x64 PHP Version:5.3.8 Block user comment: N Private report: N New Comment: Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. Previous Comments: [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
