Bug #47530 [Com]: Importing objects into document fragments creates bogus "default" namespace
Edit report at http://bugs.php.net/bug.php?id=47530&edit=1
ID: 47530
Comment by: mplomer at gmx dot de
Reported by:sgunderson at bigfoot dot com
Summary:Importing objects into document fragments creates
bogus "default" namespace
Status: Assigned
Type: Bug
Package:DOM XML related
Operating System: Debian
PHP Version:5.2.9
Assigned To:rrichards
Block user comment: N
Private report: N
New Comment:
This does not only affect DocumentFragments. I had this problem with a
simple importNode() when having multiple default namespaces. Here is a
simplified XML sample:
Reproduce code:
---
http://www.w3.org/2005/Atom";>
http://www.w3.org/1999/xhtml";>
Test-Text
';
$dom = new DOMDocument();
$dom->loadXML($xml);
$dom2 = new DOMDocument();
$importedNode = $dom2->importNode($dom->documentElement, true);
$dom2->appendChild($importedNode);
echo $dom2->saveXML();
?>
Actual result:
--
http://www.w3.org/2005/Atom";
xmlns:default="http://www.w3.org/1999/xhtml";>
http://www.w3.org/1999/xhtml";>
Test-Text
Previous Comments:
[2009-02-28 14:48:20] sgunderson at bigfoot dot com
Description:
Hi,
When I import a DOM node via a document fragment, suddenly a "default"
namespace comes out of nowhere (and it's really hard to remove, short of
making my own cloneNode() simulation stripping it).
IIRC PHP4 got this right (although it had lots of other issues), and all
other languages I've tested in (Perl, Python, Ruby) do as well. Note
that the code below doesn't strictly need importNode(), but I cannot
really do with cloneNode() in the real code (it's vastly simplified).
Note: On the surface, this appears to be the same bug as #46185, but I
tested 5.3 CVS (as of 2009-02-28) and it's still there.
Reproduce code:
---
loadXML('');
$root = $doc->documentElement;
$elem = $root->firstChild;
$frag = $doc->createDocumentFragment();
$frag->appendChild($doc->importNode($elem));
$root->appendChild($frag);
print $doc->saveXML();
?>
Expected result:
Actual result:
--
--
Edit this bug report at http://bugs.php.net/bug.php?id=47530&edit=1
Bug #53237 [Asn]: LinkedList max nodes Segmentation fault
Edit report at http://bugs.php.net/bug.php?id=53237&edit=1
ID: 53237
Updated by: dmi...@php.net
Reported by:lifinsky at yandex dot ru
Summary:LinkedList max nodes Segmentation fault
Status: Assigned
Type: Bug
Package:Scripting Engine problem
Operating System: Vista, Linux
PHP Version:5.3.3
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
The crash is caused by C stack overflow during deletion of very deep
data structure. It's probably unfixable.
Previous Comments:
[2010-11-04 09:45:27] lifinsky at yandex dot ru
Without this line we will not have LinkedList
Example in JSON Format:
{
data: 1
next: {
data: 2
next: {
data: 3
next: ...
}
}
}
[2010-11-03 22:01:10] fel...@php.net
I noticed crash is caused by following part:
$this->_tail->next = $node;
$this->_tail = $node; // without this line, no crash
[2010-11-03 16:53:26] lifinsky at yandex dot ru
Description:
I test linkedList performance and memory usage on Windows Vista Premium
with PHP 5.3.3. When list length > 34860 I have server fatal Error (
Segmentation fault) and my fast-cgi script closed. I try test on Linux
(PHP 5.2.6) but have some error if length ~ 32735. This error is not
related with memory limit.
Test script:
---
class LinkedList {
private $_length = 0;
private $_head;
private $_tail;
public function add($data) {
$node = (object) array('data' => $data, 'next' => null);
if ($this->_length == 0) {
$this->_head = $node;
$this->_tail = $node;
} else {
$this->_tail->next = $node;
$this->_tail = $node;
}
$this->_length++;
}
}
$a = new LinkedList();
$startMemory = memory_get_usage();
$start = microtime(true);
for ($i = 1; $i <= 34860; $i++) {
$a->add($i);
}
$endMemory = memory_get_usage();
$end = microtime(true);
print(($end - $start) . '');
print((int) (($endMemory - $startMemory) / 1024) . '');
Expected result:
If length = 34860 I got
0.12323784828186
11276
--
Edit this bug report at http://bugs.php.net/bug.php?id=53237&edit=1
Bug #53711 [Wfx]: Casting float->string->float with locale
Edit report at http://bugs.php.net/bug.php?id=53711&edit=1 ID: 53711 User updated by:luke at cywh dot com Reported by:luke at cywh dot com Summary:Casting float->string->float with locale Status: Wont fix Type: Bug Package:Math related PHP Version:5.2.17 Block user comment: N Private report: N New Comment: While I understand the problem and do agree somewhat, this is something that shouldn't be ignored. At some point this should be fixed, even if it breaks backwards compatibility. Perhaps not in the 5.3.x, series, but at some point in the future it should. The problem, as I see it, is locale is not respected when converting a string to a float, as pointed out by the bug report you mentioned. An ideal solution would be to introduce an ini setting that toggles the behavior. The default value "0" would result in the current behavior whereas "1" would make casting a string to float respect locale. That way developers can toggle it with ini_set when they want the more (correct) intuitive behavior. Later on the default can be changed to "1" and developers can set it back to "0" for backwards compatibility. Then in the distant future the setting can be removed. That would be the "safe way" of doing it. To be honest I'm not sure it would break very much... It's not particularly useful to not have float casting respect locale. Most people that are aware of this problem work around it with their own floatval function that makes use of localeconv(). Previous Comments: [2011-01-12 04:27:11] ahar...@php.net This may not be intuitive, or even particularly useful, but it is long standing (and intended) behaviour, per (among many others) bug #31963 and doc bug #38785. I don't see any way to change this without a massive backward compatibility break. [2011-01-10 23:48:02] luke at cywh dot com Description: When LC_ALL or LC_NUMERIC is used with setlocale casting a float as a string converts the number to the formatted locale (1234.56 to 1.234,56 instead of 1,234.56 for Italian). But when casting from a string to a float locale is not used and decimal precision is lost. I understand this has been a problem for a long time (since PHP 4 up to 5.3 at least). The obvious "work around" for me is avoid LC_NUMERIC and LC_ALL completely. Personally I would rather casting to a string NOT convert using the locale (so have it stay "1234.56"). A data type should not be locale aware. It's like assuming that a decimal number is monetary. If a float needed to be displayed with locale number_format should be used (where the default separators fit the locale). If casting to a string must be locale aware, shouldn't casting a string to a float be locale aware as well? On top of that, could it understand the thousands separator and simply ignore it? Test script: --- setlocale(LC_NUMERIC, 'en_US'); print (float)(string)1234.56; print ''; setlocale(LC_NUMERIC, 'it_IT'); print (string)(float)(string)1234.56; print ''; print (string)(float)'1.234,56'; Expected result: 1234.56 1234,56 1234,56 Actual result: -- 1234.56 1234 1,234 -- Edit this bug report at http://bugs.php.net/bug.php?id=53711&edit=1
[PHP-BUG] Bug #53716 [NEW]: segfault in $stmt->execute()
From:
Operating system: Ubuntu 10.04
PHP version: 5.3.5
Package: PDO related
Bug Type: Bug
Bug description:segfault in $stmt->execute()
Description:
The snippet of code shown used is a method from a class that subclasses
Zend_Db_Adapter_Abstract. We make a lot of query() calls, so caching
prepared statements reportedly gives us a 10% performance improvement.
#! /bin/sh
#
# Created by configure
'./configure' \
'--with-mysqli=mysqlnd' \
'--with-pdo-mysql=mysqlnd' \
'--with-zlib' \
'--enable-zip' \
'--with-gd' \
'--with-curl' \
'--enable-mbstring' \
'--enable-debug' \
"$@"
Test script:
---
public function query($sql, $bind = array())
{
static $cachePreparedStatement = array();
if(isset($cachePreparedStatement[$sql]))
{
if (!is_array($bind)) {
$bind = array($bind);
}
$stmt = $cachePreparedStatement[$sql];
$stmt->execute($bind);
return $stmt;
}
$stmt = parent::query($sql, $bind);
$cachePreparedStatement[$sql] = $stmt;
return $stmt;
}
Expected result:
No crash.
Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
0x003c7816 in ?? () from /lib/tls/i686/cmov/libc.so.6
(gdb) bt
#0 0x003c7816 in ?? () from /lib/tls/i686/cmov/libc.so.6
#1 0x082818c6 in do_fetch (stmt=0x99cb938, do_bind=1,
return_value=0x8f5c78c,
how=PDO_FETCH_ASSOC, ori=PDO_FETCH_ORI_NEXT, offset=0, return_all=0x0)
at /home/apang/work/php/php-5.3.5/ext/pdo/pdo_stmt.c:1044
#2 0x082825a2 in zim_PDOStatement_fetch (ht=3, return_value=0x8f5c78c,
return_value_ptr=0x0, this_ptr=0xb7ecba54, return_value_used=1)
at /home/apang/work/php/php-5.3.5/ext/pdo/pdo_stmt.c:1316
#3 0x08501e58 in zend_do_fcall_common_helper_SPEC
(execute_data=0x8bd0dc0)
at /home/apang/work/php/php-5.3.5/Zend/zend_vm_execute.h:316
#4 0x08502415 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0x8bd0dc0)
at /home/apang/work/php/php-5.3.5/Zend/zend_vm_execute.h:421
#5 0x085014f5 in execute (op_array=0x971d190)
at /home/apang/work/php/php-5.3.5/Zend/zend_vm_execute.h:107
#6 0x084c6e07 in zend_call_function (fci=0xbfffce28,
fci_cache=0xbfffce4c)
at /home/apang/work/php/php-5.3.5/Zend/zend_execute_API.c:964
#7 0x083849e1 in zif_call_user_func_array (ht=2, return_value=0x9a03db0,
return_value_ptr=0x0, this_ptr=0x0, return_value_used=0)
at /home/apang/work/php/php-5.3.5/ext/standard/basic_functions.c:4796
#8 0x08501e58 in zend_do_fcall_common_helper_SPEC
(execute_data=0x8bcffdc)
at /home/apang/work/php/php-5.3.5/Zend/zend_vm_execute.h:316
#9 0x08505918 in ZEND_DO_FCALL_SPEC_CONST_HANDLER
(execute_data=0x8bcffdc)
at /home/apang/work/php/php-5.3.5/Zend/zend_vm_execute.h:1606
#10 0x085014f5 in execute (op_array=0x8e7bd1c)
---Type to continue, or q to quit---
at /home/apang/work/php/php-5.3.5/Zend/zend_vm_execute.h:107
#11 0x084d488e in zend_execute_scripts (type=8, retval=0x0, file_count=3)
at /home/apang/work/php/php-5.3.5/Zend/zend.c:1194
#12 0x0846a4ee in php_execute_script (primary_file=0xb2e4)
at /home/apang/work/php/php-5.3.5/main/main.c:2265
#13 0x08592c71 in main (argc=2, argv=0xb474)
at /home/apang/work/php/php-5.3.5/sapi/cli/php_cli.c:1193
--
Edit bug report at http://bugs.php.net/bug.php?id=53716&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53716&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53716&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53716&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53716&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53716&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53716&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53716&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53716&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53716&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53716&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53716&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53716&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53716&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53716&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53716&r=php4
Daylight Savings:
Req #53708 [Opn->Wfx]: base_convert could go to base 62 or 64
Edit report at http://bugs.php.net/bug.php?id=53708&edit=1 ID: 53708 Updated by: ahar...@php.net Reported by:jimktrains at gmail dot com Summary:base_convert could go to base 62 or 64 -Status: Open +Status: Wont fix Type: Feature/Change Request -Package:*General Issues +Package:Math related Operating System: All PHP Version:trunk-SVN-2011-01-10 (SVN) Block user comment: N Private report: N New Comment: The mapping of values to characters occurs in a different order in "standard" Base64 to the way base_convert() currently works, so extending base_convert() out to 64 wouldn't make much sense, since it would either be inconsistent with the existing behaviour of base_convert() or base64_encode(), and either way I can only see it confusing people. Going to 62 would be possible, but as a cursory Web search for Base62 shows, there's no real standard -- even an informal one -- for how the character set is ordered: the most common order seems to be 0-9a-zA-Z, but there are plenty of examples of 0-9A-Za-z as well, not to mention implementations that are simple variants of Base64 (which is, of course, A-Za-z0-9, then two non-alphanumeric characters that nobody seems to be able to agree on). While it would be nice to have a Base62 conversion function (since it is quite useful in URLs), I don't think the PHP standard library is the place for it at the moment; developers will be better off using an implementation that implements the actual variant they want. Closing won't fix. Previous Comments: [2011-01-10 17:07:07] jimktrains at gmail dot com Description: base_convert (http://php.net/manual/en/function.base-convert.php) should/could go to base 62 (0-9a-zA-Z) or base64 (standard encoding). This change would be backwards compatible. -- Edit this bug report at http://bugs.php.net/bug.php?id=53708&edit=1
Req #53709 [Opn->Wfx]: [feat] md5_file and sha1_file should accept an additional length
Edit report at http://bugs.php.net/bug.php?id=53709&edit=1
ID: 53709
Updated by: ahar...@php.net
Reported by:jthijssen at noxlogic dot nl
Summary:[feat] md5_file and sha1_file should accept an
additional length
-Status: Open
+Status: Wont fix
Type: Feature/Change Request
-Package:Strings related
+Package:hash related
Operating System: NA
PHP Version:5.3SVN-2011-01-10 (SVN)
Block user comment: N
Private report: N
New Comment:
This seems like a bit too much of a corner case to me to justify
muddying the API with optional parameters, given that this
functionality could be replicated in userspace with a four line
function that called fopen() and fread() (or, alternatively, fopen()
and hash_update_stream()).
Beyond that, even if this were to be accepted, hash_file() would also
need the same treatment.
Given that, traditionally, feature requests that are trivial to
replicate in userspace aren't implemented, I'm closing this won't fix.
Previous Comments:
[2011-01-10 22:18:27] jthijssen at noxlogic dot nl
I've added the patch in a base64 format because of a bug in the php
bugtracker (bug #53703).
[2011-01-10 22:11:44] jthijssen at noxlogic dot nl
Description:
Sometimes you want to have the md5() or sha1() from a file, but not the
whole file. This is particularly handy when you want to sync directories
and you don't want to md5 whole files but just the first 4096 or 8192
bytes to speed up the checking.
This patch implements an additional parameter to md5_file() and
sha1_file() where you can add the number of bytes that needs to be
read/md5()'d from the source file.
Test script:
---
Returns the md5 from the first 8192 bytes from the iso-file:
md5_file('dvdimage.iso', false, 8192);
Returns the md5 from the complete file, even though length is way larger
than the file:
md5_file('dvdimage.iso', false, 8192000);
Expected result:
The md5_file() and sha1_file() functions actually accepting the
additional parameter.
Actual result:
--
Currently, it does not accept a 3rd paramter. The patch adds the
additional parameter (which defaults to -1, which means to read the
complete file).
Additionally added and fixed tests in md5_file.phpt and sha1_file.phpt
--
Edit this bug report at http://bugs.php.net/bug.php?id=53709&edit=1
Bug #53711 [Opn->Wfx]: Casting float->string->float with locale
Edit report at http://bugs.php.net/bug.php?id=53711&edit=1 ID: 53711 Updated by: ahar...@php.net Reported by:luke at cywh dot com Summary:Casting float->string->float with locale -Status: Open +Status: Wont fix Type: Bug Package:Math related PHP Version:5.2.17 Block user comment: N Private report: N New Comment: This may not be intuitive, or even particularly useful, but it is long standing (and intended) behaviour, per (among many others) bug #31963 and doc bug #38785. I don't see any way to change this without a massive backward compatibility break. Previous Comments: [2011-01-10 23:48:02] luke at cywh dot com Description: When LC_ALL or LC_NUMERIC is used with setlocale casting a float as a string converts the number to the formatted locale (1234.56 to 1.234,56 instead of 1,234.56 for Italian). But when casting from a string to a float locale is not used and decimal precision is lost. I understand this has been a problem for a long time (since PHP 4 up to 5.3 at least). The obvious "work around" for me is avoid LC_NUMERIC and LC_ALL completely. Personally I would rather casting to a string NOT convert using the locale (so have it stay "1234.56"). A data type should not be locale aware. It's like assuming that a decimal number is monetary. If a float needed to be displayed with locale number_format should be used (where the default separators fit the locale). If casting to a string must be locale aware, shouldn't casting a string to a float be locale aware as well? On top of that, could it understand the thousands separator and simply ignore it? Test script: --- setlocale(LC_NUMERIC, 'en_US'); print (float)(string)1234.56; print ''; setlocale(LC_NUMERIC, 'it_IT'); print (string)(float)(string)1234.56; print ''; print (string)(float)'1.234,56'; Expected result: 1234.56 1234,56 1234,56 Actual result: -- 1234.56 1234 1,234 -- Edit this bug report at http://bugs.php.net/bug.php?id=53711&edit=1
Bug #29234 [Com]: empty($object->property) incorrect when property has access overloaded (__get)
Edit report at http://bugs.php.net/bug.php?id=29234&edit=1 ID: 29234 Comment by: steven dot hartland at multiplay dot co dot uk Reported by:chrissy at codegoat dot com Summary:empty($object->property) incorrect when property has access overloaded (__get) Status: No Feedback Type: Bug Package:Scripting Engine problem Operating System: Windows XP PHP Version:5.0.0 Block user comment: N Private report: N New Comment: Still exists in 5.3 as well, cmon guys this bugs been open for 6 years! Previous Comments: [2006-11-13 11:04:01] phpbugs at thunder-2000 dot com The problem still exists with 5.2. [2006-09-07 23:58:18] lf at burntmail dot com The problem still exists with 5.1.5. [2006-07-16 20:48:46] info at peter-thomassen dot de The problem still exists with 5.1.4. [2005-03-14 01:00:14] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2005-03-06 20:49:52] sni...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip 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 http://bugs.php.net/bug.php?id=29234 -- Edit this bug report at http://bugs.php.net/bug.php?id=29234&edit=1
Bug #53617 [Asn->Opn]: Unable to run "make test" after building
Edit report at http://bugs.php.net/bug.php?id=53617&edit=1 ID: 53617 Updated by: s...@php.net Reported by:cvickery at gmail dot com Summary:Unable to run "make test" after building -Status: Assigned +Status: Open Type: Bug Package:Unknown/Other Function Operating System: os x 10.5.8 PHP Version:5.3.4 -Assigned To:sixd +Assigned To: Block user comment: N Private report: N Previous Comments: [2011-01-12 02:17:32] s...@php.net Thanks for the confirmation. This is a run-tests.php issue. [2011-01-12 02:09:06] cvickery at gmail dot com That was it! Also, I was wondering why the make test worked on my deployment system, and see that variables_order did include 'E' on that one. Thanks! [2011-01-11 20:06:59] s...@php.net I've seen a similar thing with PHP's run-tests.php on some Linux shells. The best solution there is to make sure php.ini's variables_order has "E", for example "EGPCS". See step 2 on p246 of the Underground PHP & Oracle Manual. Let us know if this is also a viable workaround. [2010-12-28 04:36:22] cvickery at gmail dot com In a parenthetical note, I mentioned that DYLD_LIBRARY_PATH has to be set for apache to launch successfully. But I failed to mention that, of course, it must also be set when launching the cli. [2010-12-28 04:27:18] cvickery at gmail dot com Description: After running configure with '--with- oci8=instantclient,/opt/oracle/app/oracle/lib' PHP builds, installs, and runs successfully (using both apache 2.2.14 and the cli). However, attempting to run "make test" in the build directory results in every test failing. tests/run- tests/test001.out, for example, contains: dyld: Library not loaded: /b/227/rdbms/lib/libclntsh.dylib.10.1 Referenced from: /Users/vickery/Downloads/php-5.3.4/sapi/cli/php Reason: image not found But libclntsh.dylib.10.1 is actually located in /opt/oracle/app/oracle/lib (When starting apache, the DYLD_LIBRARY_PATH environment variable must be set to /opt/oracle/app/oracle/lib.) But having DYLD_LIBRARY_PATH properly set when running "make test" does not solve the problem; the tests seem to be run in a separate environment not inherited from the command line (?) Test script: --- This is a build bug, so there is no test script available. Workaround: If I add the following statement to run-tests.php at line 1690, the problem goes away: $env['DYLD_LIBRARY_PATH'] = '/opt/oracle/app/oracle/lib'; Of course, this is not a real fix; it just demonstrates the need for build-test.php to add the value of DYLD_LIBRARY_PATH to the $env variable being passed to system_with_timeout(). On OS X. When configuring with oci8=instantclient,[path] -- Edit this bug report at http://bugs.php.net/bug.php?id=53617&edit=1
Bug #53617 [Asn]: Unable to run "make test" after building
Edit report at http://bugs.php.net/bug.php?id=53617&edit=1 ID: 53617 Updated by: s...@php.net Reported by:cvickery at gmail dot com Summary:Unable to run "make test" after building Status: Assigned Type: Bug -Package:OCI8 related +Package:Unknown/Other Function Operating System: os x 10.5.8 PHP Version:5.3.4 Assigned To:sixd Block user comment: N Private report: N New Comment: Thanks for the confirmation. This is a run-tests.php issue. Previous Comments: [2011-01-12 02:09:06] cvickery at gmail dot com That was it! Also, I was wondering why the make test worked on my deployment system, and see that variables_order did include 'E' on that one. Thanks! [2011-01-11 20:06:59] s...@php.net I've seen a similar thing with PHP's run-tests.php on some Linux shells. The best solution there is to make sure php.ini's variables_order has "E", for example "EGPCS". See step 2 on p246 of the Underground PHP & Oracle Manual. Let us know if this is also a viable workaround. [2010-12-28 04:36:22] cvickery at gmail dot com In a parenthetical note, I mentioned that DYLD_LIBRARY_PATH has to be set for apache to launch successfully. But I failed to mention that, of course, it must also be set when launching the cli. [2010-12-28 04:27:18] cvickery at gmail dot com Description: After running configure with '--with- oci8=instantclient,/opt/oracle/app/oracle/lib' PHP builds, installs, and runs successfully (using both apache 2.2.14 and the cli). However, attempting to run "make test" in the build directory results in every test failing. tests/run- tests/test001.out, for example, contains: dyld: Library not loaded: /b/227/rdbms/lib/libclntsh.dylib.10.1 Referenced from: /Users/vickery/Downloads/php-5.3.4/sapi/cli/php Reason: image not found But libclntsh.dylib.10.1 is actually located in /opt/oracle/app/oracle/lib (When starting apache, the DYLD_LIBRARY_PATH environment variable must be set to /opt/oracle/app/oracle/lib.) But having DYLD_LIBRARY_PATH properly set when running "make test" does not solve the problem; the tests seem to be run in a separate environment not inherited from the command line (?) Test script: --- This is a build bug, so there is no test script available. Workaround: If I add the following statement to run-tests.php at line 1690, the problem goes away: $env['DYLD_LIBRARY_PATH'] = '/opt/oracle/app/oracle/lib'; Of course, this is not a real fix; it just demonstrates the need for build-test.php to add the value of DYLD_LIBRARY_PATH to the $env variable being passed to system_with_timeout(). On OS X. When configuring with oci8=instantclient,[path] -- Edit this bug report at http://bugs.php.net/bug.php?id=53617&edit=1
Bug #53617 [Fbk->Asn]: Unable to run "make test" after building
Edit report at http://bugs.php.net/bug.php?id=53617&edit=1 ID: 53617 User updated by:cvickery at gmail dot com Reported by:cvickery at gmail dot com Summary:Unable to run "make test" after building -Status: Feedback +Status: Assigned Type: Bug Package:OCI8 related Operating System: os x 10.5.8 PHP Version:5.3.4 Assigned To:sixd Block user comment: N Private report: N New Comment: That was it! Also, I was wondering why the make test worked on my deployment system, and see that variables_order did include 'E' on that one. Thanks! Previous Comments: [2011-01-11 20:06:59] s...@php.net I've seen a similar thing with PHP's run-tests.php on some Linux shells. The best solution there is to make sure php.ini's variables_order has "E", for example "EGPCS". See step 2 on p246 of the Underground PHP & Oracle Manual. Let us know if this is also a viable workaround. [2010-12-28 04:36:22] cvickery at gmail dot com In a parenthetical note, I mentioned that DYLD_LIBRARY_PATH has to be set for apache to launch successfully. But I failed to mention that, of course, it must also be set when launching the cli. [2010-12-28 04:27:18] cvickery at gmail dot com Description: After running configure with '--with- oci8=instantclient,/opt/oracle/app/oracle/lib' PHP builds, installs, and runs successfully (using both apache 2.2.14 and the cli). However, attempting to run "make test" in the build directory results in every test failing. tests/run- tests/test001.out, for example, contains: dyld: Library not loaded: /b/227/rdbms/lib/libclntsh.dylib.10.1 Referenced from: /Users/vickery/Downloads/php-5.3.4/sapi/cli/php Reason: image not found But libclntsh.dylib.10.1 is actually located in /opt/oracle/app/oracle/lib (When starting apache, the DYLD_LIBRARY_PATH environment variable must be set to /opt/oracle/app/oracle/lib.) But having DYLD_LIBRARY_PATH properly set when running "make test" does not solve the problem; the tests seem to be run in a separate environment not inherited from the command line (?) Test script: --- This is a build bug, so there is no test script available. Workaround: If I add the following statement to run-tests.php at line 1690, the problem goes away: $env['DYLD_LIBRARY_PATH'] = '/opt/oracle/app/oracle/lib'; Of course, this is not a real fix; it just demonstrates the need for build-test.php to add the value of DYLD_LIBRARY_PATH to the $env variable being passed to system_with_timeout(). On OS X. When configuring with oci8=instantclient,[path] -- Edit this bug report at http://bugs.php.net/bug.php?id=53617&edit=1
Bug #50514 [Com]: failure while running make test
Edit report at http://bugs.php.net/bug.php?id=50514&edit=1 ID: 50514 Comment by: ashworth at us dot ibm dot com Reported by:pushpender007 at gmail dot com Summary:failure while running make test Status: Bogus Type: Bug Package:Compile Failure Operating System: SUSE Enterprise Server s390x PHP Version:5.2SVN-2009-12-18 (snap) Block user comment: N Private report: N New Comment: I added --enable-debug and things seem to be working fine now. Previous Comments: [2011-01-11 20:44:47] ashworth at us dot ibm dot com has anyone solved this yet? I cannot get past the phar issue without error, regardless of the version I use. [2010-01-05 05:18:18] pushpender007 at gmail dot com Hello ..Can you please confirm should I continue my installation or what else solution we have for the error in make test? Thanks [2009-12-22 15:16:21] pushpender007 at gmail dot com This is new result file with version 5.2.12. http://pushpender007.byethost6.com/php_test_results_20091222_1455.txt As you saying you are facing these errors too.Should I install as it is ,ignoring error? [2009-12-22 13:39:25] j...@php.net Well that explained a lot. First of all: You're testing 5.2.3? We're at 5.2.12 already, upgrade.. And next issue: Any tests failing fail also for me so nothing unexpected, we know about it, move along, nothing to see here.. [2009-12-22 10:42:28] pushpender007 at gmail dot com I have mailed the test report to the qa-repo...@lists.php.net and also uploaded to http://pushpender007.byethost6.com/php_test_results_20091222_0527.txt .Please check them.thanks 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 http://bugs.php.net/bug.php?id=50514 -- Edit this bug report at http://bugs.php.net/bug.php?id=50514&edit=1
Bug #52397 [Com]: json_encode display_errors dependency
Edit report at http://bugs.php.net/bug.php?id=52397&edit=1
ID: 52397
Comment by: fake at example dot com
Reported by:david at grudl dot com
Summary:json_encode display_errors dependency
Status: Bogus
Type: Bug
Package:JSON related
PHP Version:5.3.3RC3
Block user comment: N
Private report: N
New Comment:
This is a valid bug. The point of this bug is that no warning ever is
issued if display_errors is off. The warnings should still be issued,
they just shouldn't be displayed.
ini_set('display_errors', 1);
json_encode("\xFF");
print_r(error_get_last()); //nothing! wtf?
ini_set('display_errors', 0);
json_encode("\xFF");
print_r(error_get_last()); //now its there!
Previous Comments:
[2010-08-17 14:29:53] il...@php.net
The return values are the same and so is the operation...
[2010-07-22 01:00:35] david at grudl dot com
Description:
Invalid UTF-8 string throws E_WARNING depending on the configuration
directive display_errors:
ini_set('display_errors', 0);
json_encode("\xFF"); // PHP Warning: json_encode(): Invalid UTF-8
sequence in argument (in error log)
ini_set('display_errors', 1);
json_encode("\xFF"); // *nothing*
This directive determines whether errors should be printed to the screen
as part of the output or if they should be hidden from the user. It
should not be used to change json_encode behaviour.
The same bug affects htmlentities() and htmlspecialchars()
Test script:
---
ini_set('display_errors', 0);
json_encode("\xFF");
htmlspecialchars("\xFF", ENT_COMPAT, 'utf-8');
htmlentities("\xFF", ENT_COMPAT, 'utf-8');
--
Edit this bug report at http://bugs.php.net/bug.php?id=52397&edit=1
Bug #53690 [Opn->Csd]: 5.2svn: swapped memset arguments in struct initialization
Edit report at http://bugs.php.net/bug.php?id=53690&edit=1 ID: 53690 Updated by: fel...@php.net Reported by:anthon dot pang at gmail dot com Summary:5.2svn: swapped memset arguments in struct initialization -Status: Open +Status: Closed Type: Bug Package:Zip Related Operating System: Linux PHP Version:5.2SVN-2011-01-08 (SVN) -Assigned To: +Assigned To:felipe Block user comment: N Private report: N New Comment: This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2011-01-08 02:35:34] anthon dot pang at gmail dot com Description: This is already fixed in 5.3svn (see bug #53568). Please backport the fix to 5.2svn: memset(&tm, sizeof(tm), 0); causes: ext/zip/lib/zip_dirent.o: In function `memset': /usr/include/bits/string3.h:83: warning: memset used with constant zero length parameter; this could be due to transposed parameters -- Edit this bug report at http://bugs.php.net/bug.php?id=53690&edit=1
Bug #50514 [Com]: failure while running make test
Edit report at http://bugs.php.net/bug.php?id=50514&edit=1 ID: 50514 Comment by: ashworth at us dot ibm dot com Reported by:pushpender007 at gmail dot com Summary:failure while running make test Status: Bogus Type: Bug Package:Compile Failure Operating System: SUSE Enterprise Server s390x PHP Version:5.2SVN-2009-12-18 (snap) Block user comment: N Private report: N New Comment: has anyone solved this yet? I cannot get past the phar issue without error, regardless of the version I use. Previous Comments: [2010-01-05 05:18:18] pushpender007 at gmail dot com Hello ..Can you please confirm should I continue my installation or what else solution we have for the error in make test? Thanks [2009-12-22 15:16:21] pushpender007 at gmail dot com This is new result file with version 5.2.12. http://pushpender007.byethost6.com/php_test_results_20091222_1455.txt As you saying you are facing these errors too.Should I install as it is ,ignoring error? [2009-12-22 13:39:25] j...@php.net Well that explained a lot. First of all: You're testing 5.2.3? We're at 5.2.12 already, upgrade.. And next issue: Any tests failing fail also for me so nothing unexpected, we know about it, move along, nothing to see here.. [2009-12-22 10:42:28] pushpender007 at gmail dot com I have mailed the test report to the qa-repo...@lists.php.net and also uploaded to http://pushpender007.byethost6.com/php_test_results_20091222_0527.txt .Please check them.thanks [2009-12-22 10:15:43] pushpender007 at gmail dot com Can you please tell the file name of that result file? thanks 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 http://bugs.php.net/bug.php?id=50514 -- Edit this bug report at http://bugs.php.net/bug.php?id=50514&edit=1
Bug #24280 [Com]: imagettftext() randomly returns a warning
Edit report at http://bugs.php.net/bug.php?id=24280&edit=1 ID: 24280 Comment by: rasmus at mindplay dot dk Reported by:haafiz at ezwebsolutions dot ca Summary:imagettftext() randomly returns a warning Status: Bogus Type: Bug Package:GD related Operating System: Windows 2000 Server PHP Version:4.3.2 Block user comment: N Private report: N New Comment: Are you positive that this is not a bug? I ran into it today - with PHP 5.3.1 on localhost. As I am the only user on my own local machine, I don't understand how this could be a thread issue. For reasons I don't understand, it may be a thread issue, I can't say for sure of course. But if you're using a non-thread-safe library in an application or library that is designed to be thread-safe, wouldn't it make sense to surround those calls with some form of mutex/lock/unlock statements? I realize that would degrade performance on multi-threaded servers - but if you're going to use these functions at all, degraded performance is probably preferable to dead applications. Or not? Previous Comments: [2003-06-23 17:40:43] il...@php.net Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Unfortunately Freetype functions are not thread safe, so in a threaded enviroment problems such as the ones you are experiencing will occur. [2003-06-23 14:44:35] haafiz at ezwebsolutions dot ca Also, in addition to the "Problem loading glyph in..." problems, I get some "Problem setting text size" errors as well. And, this problem goes away every time you restart apache, but that means I have to keep restarting it to make it work. If I put an "@" in front of the errornous lines, it doesnt give me a Red X but just the image without the text on it. [2003-06-21 16:18:30] haafiz at ezwebsolutions dot ca Description: Every so often, I get this output from my file: Warning: imagettftext(): Problem loading glyph in g:\hostroot\a0007\default\wwwroot\images\button.php on line 81 PNG IHDR §~  TPLTE êêÕêêÔßß¿ÞÞ½ÏÏááÂdÏÏççÎÙÙ³ØرÓÓ§__G¨¨~mÐÐ °°GG5vvYÌ̲² 33&ffLLL9_rµg" ÅIDATxíÉà D§û¾ øÿÿ³6iZåDÄ¡sãx²³ù®&WX,÷5i»ÁáH5é|ú©^"$õ:VÞ#>ê¢D¾WÈX°£À°¦ YÔsyFj*O·æ BÁuf ²HMå´àã줻5ä¯"&"òNL¼àío¢Æ4 QÜWÜ |»55'Ê9Jælßɦ&ÐJ¤¦âDõèO4®*®·KMzÜÆáÁ:¨O 6IEND®B` And so ofcourse, the image displays as the notorious red X in IE Reproduce code: --- Expected result: Most of the time this works, but it randomly gives the error described above. This problem only occurs on PHP 4.3.2 and worked fine under 4.2.3. -- Edit this bug report at http://bugs.php.net/bug.php?id=24280&edit=1
Bug #53617 [Opn->Fbk]: Unable to run "make test" after building
Edit report at http://bugs.php.net/bug.php?id=53617&edit=1 ID: 53617 Updated by: s...@php.net Reported by:cvickery at gmail dot com Summary:Unable to run "make test" after building -Status: Open +Status: Feedback Type: Bug Package:OCI8 related Operating System: os x 10.5.8 PHP Version:5.3.4 Block user comment: N Private report: N New Comment: I've seen a similar thing with PHP's run-tests.php on some Linux shells. The best solution there is to make sure php.ini's variables_order has "E", for example "EGPCS". See step 2 on p246 of the Underground PHP & Oracle Manual. Let us know if this is also a viable workaround. Previous Comments: [2010-12-28 04:36:22] cvickery at gmail dot com In a parenthetical note, I mentioned that DYLD_LIBRARY_PATH has to be set for apache to launch successfully. But I failed to mention that, of course, it must also be set when launching the cli. [2010-12-28 04:27:18] cvickery at gmail dot com Description: After running configure with '--with- oci8=instantclient,/opt/oracle/app/oracle/lib' PHP builds, installs, and runs successfully (using both apache 2.2.14 and the cli). However, attempting to run "make test" in the build directory results in every test failing. tests/run- tests/test001.out, for example, contains: dyld: Library not loaded: /b/227/rdbms/lib/libclntsh.dylib.10.1 Referenced from: /Users/vickery/Downloads/php-5.3.4/sapi/cli/php Reason: image not found But libclntsh.dylib.10.1 is actually located in /opt/oracle/app/oracle/lib (When starting apache, the DYLD_LIBRARY_PATH environment variable must be set to /opt/oracle/app/oracle/lib.) But having DYLD_LIBRARY_PATH properly set when running "make test" does not solve the problem; the tests seem to be run in a separate environment not inherited from the command line (?) Test script: --- This is a build bug, so there is no test script available. Workaround: If I add the following statement to run-tests.php at line 1690, the problem goes away: $env['DYLD_LIBRARY_PATH'] = '/opt/oracle/app/oracle/lib'; Of course, this is not a real fix; it just demonstrates the need for build-test.php to add the value of DYLD_LIBRARY_PATH to the $env variable being passed to system_with_timeout(). On OS X. When configuring with oci8=instantclient,[path] -- Edit this bug report at http://bugs.php.net/bug.php?id=53617&edit=1
Bug #53044 [Opn->Bgs]: Invalid Nodetype to import
Edit report at http://bugs.php.net/bug.php?id=53044&edit=1
ID: 53044
Updated by: rricha...@php.net
Reported by:bbarnetm at yahoo dot com
Summary:Invalid Nodetype to import
-Status: Open
+Status: Bogus
Type: Bug
Package:DOM XML related
Operating System: W2K3
PHP Version:5.2.14
Block user comment: N
Private report: N
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Previous Comments:
[2010-10-12 06:55:14] bbarnetm at yahoo dot com
I modified my script following your tip I founded enough information for
incluye
aditional lines:
$xmlestilos=ereg_replace("[\\Ã]+","",($xmlestilos));
$xmlestilos=ereg_replace("[\\ð]+","",($xmlestilos));
The script was modified:
if (!($dom->loadXML($xmlestilos))){
$errors = libxml_get_errors();
foreach ($errors as $error) {
echo display_xml_error($error, $xmlestilos);
}
libxml_clear_errors();
}
Thank very much for your tip.
Let me know if in a future versions you will increment the power of xml
functions?
[2010-10-12 05:55:34] cataphr...@php.net
I'd guess the DOMDocument object is empty because the call to loadXML()
failed.
You should do
if (!$dom->loadXML(...)) {
//error loading XML. Call libxml_get_errors() to get details
}
not
if (!$dom) {
Please confirm this is the case.
In any case, the error message could be better...
[2010-10-11 21:22:24] bbarnetm at yahoo dot com
function acentos($valor){
//Le elimina los acentos al string recibido
$registro=$valor;
$registro=ereg_replace("á","a",($registro));
$registro=ereg_replace("é","e",($registro));
$registro=ereg_replace("Ã","i",($registro));
$registro=ereg_replace("ó","o",($registro));
$registro=ereg_replace("ú","u",($registro));
$registro=ereg_replace("Ã","A",($registro));
$registro=ereg_replace("Ã","E",($registro));
$registro=ereg_replace("Ã","I",($registro));
$registro=ereg_replace("Ã","O",($registro));
$registro=ereg_replace("Ã","U",($registro));
$registro=ereg_replace("ñ","n",($registro));
$registro=ereg_replace("Ã","N",($registro));
return $registro;
}
[2010-10-11 21:14:18] bbarnetm at yahoo dot com
Description:
While I'm trying to import an extensive xml, I'm recieving the same
error while I
try to transale to simple xml.
Test script:
---
libxml_use_internal_errors(true);
$xmlestilos=ereg_replace(chr(160),"",(trim($reg[0])));
$xmlestilos=ereg_replace('"',"",$xmlestilos);
$xmlestilos=ereg_replace(",",".",$xmlestilos);
$xmlestilos=ereg_replace("&","",$xmlestilos);
$xmlestilos=ereg_replace(">","",$xmlestilos);
$xmlestilos=ereg_replace("}","",$xmlestilos);
$xmlestilos=ereg_replace("#","",$xmlestilos);
$xmlestilos=ereg_replace("`","",$xmlestilos);
$xmlestilos=ereg_replace(";","",$xmlestilos);
$xmlestilos=ereg_replace("[\\|]+","",$xmlestilos);
$xmlestilos=ereg_replace("[\\]+","/",$xmlestilos);
$xmlestilos=ereg_replace("¦","",($xmlestilos));
$xmlestilos=ereg_replace("º","",($xmlestilos));
$xmlestilos=ereg_replace("´","",($xmlestilos));
$xmlestilos=ereg_replace("¨","",($xmlestilos));
$xmlestilos=ereg_replace("[\\?]+","",($xmlestilos));
$xmlestilos=ereg_replace("[\\¿]+","",($xmlestilos));
$xmlestilos=acentos($xmlestilos);
$xmlestilos=stripslashes($xmlestilos);
$xmlestilos=utf8_decode($xmlestilos);
$dom = new domDocument;
$dom->loadXML($xmlestilos);
if (!$dom) {
//Escribe la respuesta en un archivo
$formato1 = '%d%m%Y'; $hoyes = strftime($formato1);
$archivolog="estilos_".$hoyes.".log";
if (file_exists($archivolog)){unlink($archivolog);}
$fp = fopen ($archivolog, "a");
//fwrite ($fp, trim($reg[0]). PHP_EOL);
fwrite ($fp, trim($xmlestilos). PHP_EOL);
fclose($fp);
print 'MSG-18: SE DETECTO UNA RESPUESTA INVALIDA DEL INS'; die();
}
$xml = simplexml_import_dom($dom);
Expected result:
The xml imported in a simple xml object
Actual result:
--
Warning: simplexml_import_dom() [function.simplexml-import-do
Bug #53393 [Opn->Bgs]: XPath path issue with namespaced elements created with DOMDocument
Edit report at http://bugs.php.net/bug.php?id=53393&edit=1
ID: 53393
Updated by: rricha...@php.net
Reported by:paul dot visco at roswellpark dot org
Summary:XPath path issue with namespaced elements created
with DOMDocument
-Status: Open
+Status: Bogus
Type: Bug
Package:DOM XML related
Operating System: CENTOS 5.5/Fedora 14
PHP Version:5.3.3
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
must use dom level 2 namespace aware methods
Previous Comments:
[2010-11-24 04:01:43] paul dot visco at roswellpark dot org
Description:
When creating a namespaced DOMDocument programmatically (appendChild,
etc), I cannot get DOMXPath to return the same results on the same
underlying XML document as I can when use DOMDocument->loadXML() to
populate the documents XML.
I compiled and tested the latest PHP 5.3.4RC2-dev (cli) (built: Nov 23
2010 21:51:46) using --with-dom and --with-xml and used the latest
stable libxml2-devel.x86_64 2.7.7-2.fc14 from fedora 14 and the problem
still persists.
Sorry its like 25 lines of code with comments, I don't have somewhere
else to put them.
Test script:
---
//Constructing the DOMDocument from XML string allows DOMXPath to work
$xml = <<
http://www.w3.org/2005/Atom";
xmlns:other="http://other.w3.org/other";>uYG7-sPwjFg2009-05-17T18:29:31.000Z
EOT;
$doc = new DOMDocument;
$doc->loadXML($xml);
$xpath = new DOMXPath($doc);
$xpath->registerNamespace('atom', "http://www.w3.org/2005/Atom";);
$entries = $xpath->evaluate('//atom:entry/atom:published/text()');
///prints 2009-05-17T18:29:31.000Z as expected
print $entries->item(0)->nodeValue ;
//Constructing the same exact document programmatically causes DOMXPath
to not work
$doc = new DOMDocument("1.0", "UTF-8");
$entry = $doc->createElement('entry');
$doc->appendChild($entry);
$entry->setAttribute('xmlns', "http://www.w3.org/2005/Atom";);
$entry->setAttribute('xmlns:other', "http://other.w3.org/other";);
$id = $entry->appendChild($doc->createElement('id'));;
$id->appendChild($doc->createTextNode("uYG7-sPwjFg"));
$published = $entry->appendChild($doc->createElement('published'));
$published->appendChild($doc->createTextNode("2009-05-17T18:29:31.000Z"));
$xpath = new DOMXPath($doc);
$xpath->registerNamespace('atom', "http://www.w3.org/2005/Atom";);
$entries = $xpath->evaluate('//atom:entry/atom:published/text()');
//throws error as node is not found
print $entries->item(0)->nodeValue;
Expected result:
I would expect both of the above examples to print
2009-05-17T18:29:31.000Z
Actual result:
--
Example one prints 2009-05-17T18:29:31.000Z and example 2 fails because
the node is not found by Xpath
--
Edit this bug report at http://bugs.php.net/bug.php?id=53393&edit=1
Req #23313 [Opn->Wfx]: Missing DomNode->get_namespace()
Edit report at http://bugs.php.net/bug.php?id=23313&edit=1 ID: 23313 Updated by: rricha...@php.net Reported by:markus dot pfefferle at web dot de Summary:Missing DomNode->get_namespace() -Status: Open +Status: Wont fix Type: Feature/Change Request Package:DOM XML related Operating System: * PHP Version:* 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: [2003-04-23 06:56:03] markus dot pfefferle at web dot de It's nice that you can create nodes with namespaces, using DomDocument->create_element_ns() and DomNode->add_namespaces(), but for actually reading them, there is no counterpart method (other than prefix(), which is not very safe). My specific problem is that I want to clone a node without its child nodes, but can't use DomNode->clone_node(false), since this does not copy any namespace declarations and attributes either. Adding a DomNode->get_namespace() in future versions would be greatly appreciated. -- Edit this bug report at http://bugs.php.net/bug.php?id=23313&edit=1
Bug #52713 [Com]: Can't call undefined methods (using __call) on parent
Edit report at http://bugs.php.net/bug.php?id=52713&edit=1 ID: 52713 Comment by: ghosh at q-one dot com Reported by:michael at wakeless dot net Summary:Can't call undefined methods (using __call) on parent Status: Open Type: Bug Package:Scripting Engine problem Operating System: All PHP Version:5.3.3 Block user comment: N Private report: N New Comment: Is this still problem with PHP 5.3.4? Following the discussion here: http://www.serverphorums.com/read.php?7,220473,220473#msg-220473 it seems this should already been fixed. This bug, however, is still marked as open. Previous Comments: [2010-08-31 14:48:25] giovanni at giacobbi dot net @michael: I think the situation is perfectly clear. I think they screwed up on this one. @felipe: this change is absolutely not reasonable and breaks backward compatibility. I understand that the behaviour for #51176 is inconvenient, but that's the way it is, you cannot change this in a minor release. My suggestion (and wish) is that you revert this change to the previous behaviour. Shall we discuss this in the internals mailing list? Sounds like an interesting issue without a straightforward solution.giov [2010-08-31 06:06:45] michael at wakeless dot net I'm pretty sure everyone should be aware of this but I'll say it nonetheless. parent:: isn't necessarily a static call. When it's used within an object context it should remain within an object context, but the subsequent call to __callStatic seems to lose it. I tried a workaround of testing for $this in __callStatic but it seems to have gone missing. Is there anything I can do to help this out? Write a more comprehensive test case that can be checked into the suite? [2010-08-31 01:06:05] fel...@php.net The change was introduced as a fix for the bug #51176. [2010-08-31 01:05:07] fel...@php.net The difference introduced was that the __call() just will be called when __callStatic() is not implemented, on such static method calls. [2010-08-28 22:38:40] giovanni at giacobbi dot net I ran into the same problem. It's a serious breakage! I just tested on php 5.3.2 and it works as expected! 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 http://bugs.php.net/bug.php?id=52713 -- Edit this bug report at http://bugs.php.net/bug.php?id=52713&edit=1
[PHP-BUG] Req #53713 [NEW]: Add sqlite3 session handler
From:
Operating system:
PHP version: 5.3.5
Package: SQLite related
Bug Type: Feature/Change Request
Bug description:Add sqlite3 session handler
Description:
ext/sqlite will disappear soon, it's seem good to add support for sqlite3
session handler (merge ext/sqlite/sess_sqlite.c)
;)
Test script:
---
session_module_name('sqlite3');
Actual result:
--
Warning: session_module_name(): Cannot find named PHP session module
(sqlite3)
--
Edit bug report at http://bugs.php.net/bug.php?id=53713&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53713&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53713&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53713&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53713&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53713&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53713&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53713&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53713&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53713&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53713&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53713&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53713&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53713&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53713&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53713&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53713&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53713&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53713&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53713&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53713&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53713&r=mysqlcfg
Bug #49532 [Com]: php5ts.dll access violation exception php5ts!_zend_mm_free_int
Edit report at http://bugs.php.net/bug.php?id=49532&edit=1 ID: 49532 Comment by: eb at upcl dot univ-lyon1 dot fr Reported by:matroy at investpsp dot ca Summary:php5ts.dll access violation exception php5ts!_zend_mm_free_int Status: Feedback Type: Bug Package:*General Issues Operating System: win32 only - Windows 2003 SP2 PHP Version:5.2.11 Block user comment: N Private report: N New Comment: I modify my php.ini file for it expresses error messages. PHP, on loading, claimed beeing unable to load a few modules though available in the appropriate directory; commenting out the loading of these modules in the php file fixed the problem. These modules were ; extension=php_oci8.dll ; extension=php_oci8_11g.dll ; extension=php_pdo_oci.dll ; extension=php_sybase_ct.dll Previous Comments: [2011-01-11 10:52:44] eb at upcl dot univ-lyon1 dot fr Well, actually, adding a line such as "LoadModule php5_module "C:/HD3/apache_php_mysql/software/php/php5apache2_2.dll" in the configuration file of the apache server is enough to lead it failing to start and issuing a "Application défaillante httpd.exe, version 2.2.17.0, module défaillant php5ts.dll, version 5.3.5.0, adresse de défaillance 0x000e890c." in the windows log file. As I told you, this occurs ONLY after the system has rebooted. Right after the installation, all works well. [2011-01-11 09:55:39] paj...@php.net @eb at upcl dot univ-lyon1 dot fr Many things can cause this error message. We still need a way to reproduce it, a small script. [2011-01-11 09:29:09] eb at upcl dot univ-lyon1 dot fr Hello, I am experiencing quite the same situation though i'm running Apache 2.2 under windows xp sp3. PHP version is 5.3.5. The weird part of all this is that, right after the installation of PHP, it works fine (no bug), the PHP module interpreting quite well php code. But after rebooting, the apache server fails starting when loading the php module (php5apache2_2.dll) claiming an "application error" due to php5ts.dll module. I installed and uninstalled it twice and each time the same prolem occurred the same way. HTTP: Apache 2.2.17.0 PHP : 5.3.5.0 Windows : XP SP3 [2009-09-20 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2009-09-12 11:15:53] paj...@php.net For what I see in the crashlog, it uses ISAPI. To use PHP with IIS, the recommended way is FastCGI (nts build, non thread safe). If you are using it only in the command line, please use the NTS (non thread safe) as well. We also need a script to reproduce the crash. 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 http://bugs.php.net/bug.php?id=49532 -- Edit this bug report at http://bugs.php.net/bug.php?id=49532&edit=1
Bug #50512 [Com]: Yuml is missing in HTML translation table
Edit report at http://bugs.php.net/bug.php?id=50512&edit=1 ID: 50512 Comment by: neil at weboutreach dot co dot uk Reported by:anotherhero at gmail dot com Summary:Yuml is missing in HTML translation table Status: Open Type: Bug Package:*General Issues Operating System: * PHP Version:5.*, 6 Block user comment: N Private report: N New Comment: It appears also that the following are missing: ‘ ’ “ ” Previous Comments: [2009-12-18 10:52:14] anotherhero at gmail dot com Not that I've noticed, at least none that got a lower case variant but missing their upper case relative or visa versa. [2009-12-18 09:20:04] j...@php.net Indeed it is missing. Any idea if any other such are missing there? Quick look would suggest there aren't but.. :) [2009-12-18 07:26:10] anotherhero at gmail dot com Description: The HTML entity for which is Ÿ is missing Reproduce code: --- http://bugs.php.net/bug.php?id=50512&edit=1
Bug #53712 [Opn]: DateTime::createFromFormat using format ('W') doesn't work
Edit report at http://bugs.php.net/bug.php?id=53712&edit=1
ID: 53712
User updated by:mpchanzy at proxecom dot fr
Reported by:mpchanzy at proxecom dot fr
-Summary:Weeks format ('W') doesn't work
+Summary:DateTime::createFromFormat using format ('W')
doesn't work
Status: Open
Type: Bug
Package:Unknown/Other Function
Operating System: XP Pro
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
I just changed the title to make it more explicit
Previous Comments:
[2011-01-11 11:35:29] mpchanzy at proxecom dot fr
Description:
---
>From manual page: http://www.php.net/datetime.createfromformat#Liste de
paramètres
---
DateTime::createFromFormat('W','1')
returns false when it should probably return the date of the first week
of the year.
'W' is a date() compatible format
Test script:
---
$date = DateTime::createFromFormat('W','1');
Expected result:
it should return something like this:
public 'date' => string '2011-01-03 10:17:40' (length=19)
public 'timezone_type' => int 3
public 'timezone' => string 'UTC' (length=3)
Actual result:
--
false
--
Edit this bug report at http://bugs.php.net/bug.php?id=53712&edit=1
[PHP-BUG] Bug #53712 [NEW]: Weeks format ('W') doesn't work
From:
Operating system: XP Pro
PHP version: 5.3.5
Package: Unknown/Other Function
Bug Type: Bug
Bug description:Weeks format ('W') doesn't work
Description:
---
>From manual page: http://www.php.net/datetime.createfromformat#Liste de
paramètres
---
DateTime::createFromFormat('W','1')
returns false when it should probably return the date of the first week of
the year.
'W' is a date() compatible format
Test script:
---
$date = DateTime::createFromFormat('W','1');
Expected result:
it should return something like this:
public 'date' => string '2011-01-03 10:17:40' (length=19)
public 'timezone_type' => int 3
public 'timezone' => string 'UTC' (length=3)
Actual result:
--
false
--
Edit bug report at http://bugs.php.net/bug.php?id=53712&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53712&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53712&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53712&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53712&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53712&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53712&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53712&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53712&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53712&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53712&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53712&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53712&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53712&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53712&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53712&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53712&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53712&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53712&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53712&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53712&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53712&r=mysqlcfg
Bug #49532 [Com]: php5ts.dll access violation exception php5ts!_zend_mm_free_int
Edit report at http://bugs.php.net/bug.php?id=49532&edit=1 ID: 49532 Comment by: eb at upcl dot univ-lyon1 dot fr Reported by:matroy at investpsp dot ca Summary:php5ts.dll access violation exception php5ts!_zend_mm_free_int Status: Feedback Type: Bug Package:*General Issues Operating System: win32 only - Windows 2003 SP2 PHP Version:5.2.11 Block user comment: N Private report: N New Comment: Well, actually, adding a line such as "LoadModule php5_module "C:/HD3/apache_php_mysql/software/php/php5apache2_2.dll" in the configuration file of the apache server is enough to lead it failing to start and issuing a "Application défaillante httpd.exe, version 2.2.17.0, module défaillant php5ts.dll, version 5.3.5.0, adresse de défaillance 0x000e890c." in the windows log file. As I told you, this occurs ONLY after the system has rebooted. Right after the installation, all works well. Previous Comments: [2011-01-11 09:55:39] paj...@php.net @eb at upcl dot univ-lyon1 dot fr Many things can cause this error message. We still need a way to reproduce it, a small script. [2011-01-11 09:29:09] eb at upcl dot univ-lyon1 dot fr Hello, I am experiencing quite the same situation though i'm running Apache 2.2 under windows xp sp3. PHP version is 5.3.5. The weird part of all this is that, right after the installation of PHP, it works fine (no bug), the PHP module interpreting quite well php code. But after rebooting, the apache server fails starting when loading the php module (php5apache2_2.dll) claiming an "application error" due to php5ts.dll module. I installed and uninstalled it twice and each time the same prolem occurred the same way. HTTP: Apache 2.2.17.0 PHP : 5.3.5.0 Windows : XP SP3 [2009-09-20 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2009-09-12 11:15:53] paj...@php.net For what I see in the crashlog, it uses ISAPI. To use PHP with IIS, the recommended way is FastCGI (nts build, non thread safe). If you are using it only in the command line, please use the NTS (non thread safe) as well. We also need a script to reproduce the crash. [2009-09-11 18:28:54] matroy at investpsp dot ca Same problem with 5.2.11 Tested with 5.2.11, 5.2.10, 5.2.6 I thought it was due to mssql ext. so I've switched to sqlsrv and still go the crash. loaded extension are: php_curl.dll php_mcrypt.dll php_mysql.dll php_sockets.dll php_zip.dll php_sqlsrv_ts.dll 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 http://bugs.php.net/bug.php?id=49532 -- Edit this bug report at http://bugs.php.net/bug.php?id=49532&edit=1
Bug #49532 [NoF->Fbk]: php5ts.dll access violation exception php5ts!_zend_mm_free_int
Edit report at http://bugs.php.net/bug.php?id=49532&edit=1 ID: 49532 Updated by: paj...@php.net Reported by:matroy at investpsp dot ca Summary:php5ts.dll access violation exception php5ts!_zend_mm_free_int -Status: No Feedback +Status: Feedback Type: Bug Package:*General Issues Operating System: win32 only - Windows 2003 SP2 PHP Version:5.2.11 Block user comment: N Private report: N New Comment: @eb at upcl dot univ-lyon1 dot fr Many things can cause this error message. We still need a way to reproduce it, a small script. Previous Comments: [2011-01-11 09:29:09] eb at upcl dot univ-lyon1 dot fr Hello, I am experiencing quite the same situation though i'm running Apache 2.2 under windows xp sp3. PHP version is 5.3.5. The weird part of all this is that, right after the installation of PHP, it works fine (no bug), the PHP module interpreting quite well php code. But after rebooting, the apache server fails starting when loading the php module (php5apache2_2.dll) claiming an "application error" due to php5ts.dll module. I installed and uninstalled it twice and each time the same prolem occurred the same way. HTTP: Apache 2.2.17.0 PHP : 5.3.5.0 Windows : XP SP3 [2009-09-20 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2009-09-12 11:15:53] paj...@php.net For what I see in the crashlog, it uses ISAPI. To use PHP with IIS, the recommended way is FastCGI (nts build, non thread safe). If you are using it only in the command line, please use the NTS (non thread safe) as well. We also need a script to reproduce the crash. [2009-09-11 18:28:54] matroy at investpsp dot ca Same problem with 5.2.11 Tested with 5.2.11, 5.2.10, 5.2.6 I thought it was due to mssql ext. so I've switched to sqlsrv and still go the crash. loaded extension are: php_curl.dll php_mcrypt.dll php_mysql.dll php_sockets.dll php_zip.dll php_sqlsrv_ts.dll [2009-09-11 14:52:24] matroy at investpsp dot ca I'm not using it in a web server, it's as a command line using the php.exe. I've got the same proble with 5.2.6 and trying with 5.2.11RC3... 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 http://bugs.php.net/bug.php?id=49532 -- Edit this bug report at http://bugs.php.net/bug.php?id=49532&edit=1
Bug #49532 [Com]: php5ts.dll access violation exception php5ts!_zend_mm_free_int
Edit report at http://bugs.php.net/bug.php?id=49532&edit=1 ID: 49532 Comment by: eb at upcl dot univ-lyon1 dot fr Reported by:matroy at investpsp dot ca Summary:php5ts.dll access violation exception php5ts!_zend_mm_free_int Status: No Feedback Type: Bug Package:*General Issues Operating System: win32 only - Windows 2003 SP2 PHP Version:5.2.11 Block user comment: N Private report: N New Comment: Hello, I am experiencing quite the same situation though i'm running Apache 2.2 under windows xp sp3. PHP version is 5.3.5. The weird part of all this is that, right after the installation of PHP, it works fine (no bug), the PHP module interpreting quite well php code. But after rebooting, the apache server fails starting when loading the php module (php5apache2_2.dll) claiming an "application error" due to php5ts.dll module. I installed and uninstalled it twice and each time the same prolem occurred the same way. HTTP: Apache 2.2.17.0 PHP : 5.3.5.0 Windows : XP SP3 Previous Comments: [2009-09-20 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2009-09-12 11:15:53] paj...@php.net For what I see in the crashlog, it uses ISAPI. To use PHP with IIS, the recommended way is FastCGI (nts build, non thread safe). If you are using it only in the command line, please use the NTS (non thread safe) as well. We also need a script to reproduce the crash. [2009-09-11 18:28:54] matroy at investpsp dot ca Same problem with 5.2.11 Tested with 5.2.11, 5.2.10, 5.2.6 I thought it was due to mssql ext. so I've switched to sqlsrv and still go the crash. loaded extension are: php_curl.dll php_mcrypt.dll php_mysql.dll php_sockets.dll php_zip.dll php_sqlsrv_ts.dll [2009-09-11 14:52:24] matroy at investpsp dot ca I'm not using it in a web server, it's as a command line using the php.exe. I've got the same proble with 5.2.6 and trying with 5.2.11RC3... [2009-09-11 14:49:59] paj...@php.net ISAPI is deprecated and not maintained anymore. Please try the same script using the FastCGI interface instead (works with IIS5/6/7). 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 http://bugs.php.net/bug.php?id=49532 -- Edit this bug report at http://bugs.php.net/bug.php?id=49532&edit=1
