#46260 [Com]: __FILE__ should not resolve symlink paths
ID: 46260 Comment by: glideraerobatics at hotmail dot com Reported By: bugs dot php dot net at callum-macdonald dot com Status: Open Bug Type: Feature/Change Request Operating System: Linux PHP Version: 5.2.6 New Comment: I have the same problem with PHP. I have a slave site that shares most (but not all!) code with a master site using symlinks. The code consists of CLI scripts, web pages, and includes (one of which is a common include for setting up the include_path and error handling). It is critical that this include_path refers to paths in the slave site even though the real common include resides in the master site. I can't achieve this using __FILE__ unfortunately due to the symlink resolution problem. It would be nice to have an alternative to __FILE__, perhaps __LINK__, with unresolved symlinks. Please PHP developers add this!!! PHP needs it so much and it must be a very simple thing to add. In the mean time, I've created a function in the common include that jumps though hoops in order to set the include_path correctly by using argv[0] in CLI scripts (and traversing up until a htdocs dir is found) or else $_SERVER['DOCUMENT_ROOT'] in web scripts. It's horrible, but the only solution I've found so far. Previous Comments: [2009-07-02 16:43:32] raphael dot roulet at univ-st-etienne dot fr If there is no security issue, Why don't PHP make life easier ? [2009-01-31 23:12:49] bugs dot php dot net at callum-macdonald dot com $_SERVER['PHP_SELF'] only relates to the main script, not the currently included file. It's useful, but a completely separate issue. There is, as far as I can see, no way to get the non symlink resolved path of the currently included file. [2009-01-31 22:54:44] luke_phpbugs at dashjr dot org $_SERVER[PHP_SELF] helps a little. [2008-10-09 01:32:07] bugs dot php dot net at callum-macdonald dot com Description: See these bugs: http://bugs.php.net/bug.php?id=38790 http://bugs.php.net/bug.php?id=42516 http://bugs.php.net/bug.php?id=37603 The __FILE__ constant should not, in my opinion, resolve symbolic links on *nix operating systems. At the very least, there should be an option to control this behaviour. Because __FILE__ returns only the symlink resolved path, there is no way to get the symlink path of the currently included file. If __FILE__ returned the symlinkpath, the resolved path could be retrieved with realpath(__FILE__). The opposite is not true. There is no way to go from the resolved path to the original link path. I realise this is a feature not a bug, but I believe it is a serious shortcoming and limits the ability of PHP in symlinked situations. Reproduce code: --- See http://bugs.php.net/bug.php?id=37603 Expected result: __FILE__ should return the symlink path Actual result: -- __FILE__ returns the resolved path -- Edit this bug report at http://bugs.php.net/?id=46260edit=1
#49521 [Ver]: PDO fetchObject sets values before calling constructor
ID: 49521
User updated by: waps at pisem dot net
Reported By: waps at pisem dot net
Status: Verified
Bug Type: PDO related
Operating System: Ubuntu 8.10 x64
PHP Version: 5.2.10
New Comment:
sjoerd, yes!
Im my php5 framework phpDays (http://phpdays.sf.net) I faced with this
problem. Pleae, fix it in php 5.2.x and 5.3.x and 6.x.x. Thnanks!
P.S. Maybe this problem exists in other php components. Need to code
review to find this problem in all components.
P.P.S. Please, tell me about fix this problem in future. Thanks!
Previous Comments:
[2009-09-21 18:45:30] sjo...@php.net
Confirmed. If the constructor sets default values for some fields, as
is typical, the constructor will overwrite the values just retrieved
from the database.
?php
class Book {
function __construct() {
$this-title = Default;
}
}
$pdo = new PDO('mysql:dbname=books', 'root');
$statement = $pdo-prepare('SELECT * FROM book WHERE
title=\'Peopleware\'');
$statement-execute();
$obj = $statement-fetchObject('Book');
echo $obj-title; // Expected: Peopleware. Actual: Default
?
[2009-09-10 11:45:31] waps at pisem dot net
Description:
Incorrect creating user object: set data before call constructor
method.
Reproduce code:
---
---
From manual page: pdostatement.fetchobject
---
class Product {
public function __construct() {
echo 'create object, ';
}
public function __set($offset, $value) {
echo 'set value, ';
}
}
// fetch object
$stmt-fetchObject('Product', array());
Expected result:
Expected result: create object, set value,
Actual result:
--
Actual result: set value, create object,
--
Edit this bug report at http://bugs.php.net/?id=49521edit=1
#49567 [Opn]: DOM/XSL: Suggestion: registerObjectMethods()
ID: 49567
User updated by: mjs at beebo dot org
Reported By: mjs at beebo dot org
Status: Open
Bug Type: Feature/Change Request
Operating System: OS X
PHP Version: 5.3.0
New Comment:
Had a look at how the xsl extension works, and had a shot at
implementing this myself--the patch is below.
Instead of adding a new function I enhanced registerPHPFunctions() so
that it can take an object. It works like this: if an object is
provided (say $foo), then xsl:value-of select=php:function('quux',
44)/ in the XSL results in a call to $foo-quux(44).
i.e. in PHP:
$foo = new Foo();
$processor-registerPHPFunctions($foo);
In XSL:
xsl:value-of select=php:function('quux', 44)/
Two of the tests in ext/xsl failed, but they fail without this patch
also.
The patch is:
Index: ext/xsl/tests/xsltprocessor_registerPHPFunctions-method.phpt
===
--- ext/xsl/tests/xsltprocessor_registerPHPFunctions-method.phpt
(revision 0)
+++ ext/xsl/tests/xsltprocessor_registerPHPFunctions-method.phpt
(revision 0)
@@ -0,0 +1,38 @@
+--TEST--
+Checks XSLTProcessor::registerPHPFunctions($obj) where the
functions
+exposed in the XSL file are methods of $obj.
+--SKIPIF--
+?php
+if (!extension_loaded('xsl')) {
+die(skip\n);
+}
+?
+--FILE--
+?php
+
+class Foo {
+public function greet($name) {
+return Hello, $name;
+}
+public function add($i, $j) {
+return $i + $j;
+}
+}
+
+$xml = new DOMDocument();
+$xml-loadXML(root/);
+$xsl = new DOMDocument();
+$xsl-load(dirname(__FILE__) . /phpmethod.xsl);
+
+$proc = new XSLTProcessor();
+$proc-importStylesheet($xsl);
+
+$foo = new Foo();
+
+$proc-registerPHPFunctions($foo);
+
+echo $proc-transformToXml($xml);
+--EXPECTF--
+result greet=Hello, Clem add=7/
+--CREDITS--
+Michael Stillwell m...@beebo.org
\ No newline at end of file
Index: ext/xsl/tests/phpmethod.xsl
===
--- ext/xsl/tests/phpmethod.xsl (revision 0)
+++ ext/xsl/tests/phpmethod.xsl (revision 0)
@@ -0,0 +1,15 @@
+xsl:stylesheet
+ version=1.0
+ xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
+ xmlns:php=http://php.net/xsl;
+ exclude-result-prefixes=php
+ xsl:output omit-xml-declaration=yes/
+xsl:template match=/
+ result
+ !-- pass a single string argument --
+ xsl:attribute name=greetxsl:value-of
select=php:function('greet', 'Clem')//xsl:attribute
+ !-- pass two integer arguments --
+ xsl:attribute name=addxsl:value-of select=php:function('add',
3, 4)//xsl:attribute
+ /result
+/xsl:template
+/xsl:stylesheet
\ No newline at end of file
Index: ext/xsl/php_xsl.h
===
--- ext/xsl/php_xsl.h (revision 288545)
+++ ext/xsl/php_xsl.h (working copy)
@@ -55,6 +55,7 @@
HashTable *node_list;
php_libxml_node_object *doc;
char *profiling;
+ zval *object_ptr;
} xsl_object;
void php_xsl_set_object(zval *wrapper, void *obj TSRMLS_DC);
Index: ext/xsl/xsltprocessor.c
===
--- ext/xsl/xsltprocessor.c (revision 288545)
+++ ext/xsl/xsltprocessor.c (working copy)
@@ -308,11 +308,11 @@
fci.function_name = handler;
fci.symbol_table = NULL;
- fci.object_ptr = NULL;
fci.retval_ptr_ptr = retval;
fci.no_separation = 0;
+ fci.object_ptr = intern-object_ptr ? intern-object_ptr :
NULL;
/*fci.function_handler_cache = function_ptr;*/
- if (!zend_make_callable(handler, callable TSRMLS_CC)) {
+ if ((intern-registerPhpFunctions != 3)
!zend_make_callable(handler, callable TSRMLS_CC)) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, Unable to
call handler %s(), callable);
} else if ( intern-registerPhpFunctions == 2
zend_hash_exists(intern-registered_phpfunctions, callable,
strlen(callable) + 1) == 0) {
@@ -320,6 +320,9 @@
/* Push an empty string, so that we at least have an
xslt result... */
valuePush(ctxt, xmlXPathNewString());
} else {
+ if (intern-object_ptr) {
+ fci.object_ptr = intern-object_ptr;
+ }
result = zend_call_function(fci, NULL TSRMLS_CC);
if (result == FAILURE) {
if (Z_TYPE(handler) == IS_STRING) {
@@ -794,6 +797,7 @@
zval *id;
xsl_object *intern;
zval *array_value, **entry, *new_string;
+ zval *obj_ptr;
int name_len = 0;
char *name;
@@ -823,6 +827,12 @@
zend_hash_update(intern-registered_phpfunctions,
name, name_len + 1, new_string, sizeof(zval*), NULL);
intern-registerPhpFunctions = 2;
+ } else if (zend_parse_parameters_ex(ZEND_PARSE_PARAMS_QUIET,
ZEND_NUM_ARGS() TSRMLS_CC, o, obj_ptr)
#49620 [NEW]: is_writeable does not work using netshare and normal user rights
From: philipp at servicemail24 dot de
Operating system: Windows XP SP2
PHP version: 5.3.0
PHP Bug Type: *Directory/Filesystem functions
Bug description: is_writeable does not work using netshare and normal user
rights
Description:
PHP 5.3.0 and 5.3.1RC1 has a bug in the is_readable and is_writeable
function if you execute a script with normal windows user rights.
The same test script works fine using PHP 5.2.x. Providing admin rights
for the user solves the problem but this is not a long term solution for
us.
All tested PHP releases are VC6 TS
PHP 5.2.10 - OK
PHP 5.2.11 - OK
PHP 5.3.0 - FAILED
PHP 5.3.1RC1 - FAILED
Reproduce code:
---
$folders = array( '10.1.1.1\\share',
'srv\\share',
'd:/temp'
);
foreach($folders as $folder) {
if(@!is_readable($folder)) {
echo('FAILED is_readable: ' . $folder . \n);
} else {
echo OK is_readable: . $folder . \n;
}
if(@!is_writeable($folder)) {
echo('FAILED is_writeable: ' . $folder . \n);
} else {
echo OK is_writeable: . $folder . \n;
}
$filename = $folder . '\\test.txt';
if(@!file_put_contents($filename, 'php test')) {
echo('FAILED file_put_contents: ' . $filename . \n);
} else {
echo OK file_put_contents: . $filename . \n;
}
}
Expected result:
OK is_readable: \\10.1.1.1\share
OK is_writeable: \\10.1.1.1\share
OK file_put_contents: \\10.1.1.1\share\test.txt
OK is_readable: \\srv\share
OK is_writeable: \\srv\share
OK file_put_contents: \\srv\share\test.txt
OK is_readable: d:/temp
OK is_writeable: d:/temp
OK file_put_contents: d:/temp\test.txt
Actual result:
--
FAILED is_readable: \\10.1.1.1\share
FAILED is_writeable: \\10.1.1.1\share
OK file_put_contents: \\10.1.1.1\share\test.txt
FAILED is_readable: \\srv\share
FAILED is_writeable: \\srv\share
OK file_put_contents: \\srv\share\test.txt
OK is_readable: d:/temp
OK is_writeable: d:/temp
OK file_put_contents: d:/temp\test.txt
--
Edit bug report at http://bugs.php.net/?id=49620edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49620r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49620r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49620r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49620r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49620r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49620r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49620r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49620r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49620r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49620r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49620r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49620r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49620r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49620r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49620r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49620r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49620r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49620r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49620r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49620r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49620r=mysqlcfg
#49478 [Opn-Fbk]: shell_exec does not work
ID: 49478
Updated by: paj...@php.net
Reported By: elmue at gmx dot de
-Status: Open
+Status: Feedback
Bug Type: Program Execution
Operating System: Windows
PHP Version: 6SVN-2009-09-06 (snap)
-Assigned To:
+Assigned To: pajoye
New Comment:
I can't reproduce it with php6 neither with 5.3 or 5.2 in CLI or FCGI.
Can you try it with CLI/CGI too please?
Previous Comments:
[2009-09-22 05:18:15] ian at iglou dot com
Also broken in PHP Version 5.2.10; safe mode off.
An earlier version (no record of which) did work when used thus to get
a Windows dvd volume label:
if (preg_match('#Volume in drive [a-zA-Z]* is (.*)\n#i',
shell_exec('dir '.$drive.':'), $m)) {
$volname = ' ('.$m[1].')';
[2009-09-06 00:49:59] elmue at gmx dot de
Description:
On PHP 6 VC 6 from 3.sept.2009 the shell_exec command is broken.
Tested on Xampp on Windows XP with Apache 2.2.9.
Whatever you put into shell_exec e.g.
shell_exec(dir C:\\)
produces a
Warning shell_exec() [function.shell-exec]: Unable to execute 'dir
c:\'
The same script works fine on PHP 5
--
Edit this bug report at http://bugs.php.net/?id=49478edit=1
#49620 [Opn-Fbk]: is_writeable does not work using netshare and normal user rights
ID: 49620
Updated by: paj...@php.net
Reported By: philipp at servicemail24 dot de
-Status: Open
+Status: Feedback
Bug Type: *Directory/Filesystem functions
Operating System: Windows XP SP2
PHP Version: 5.3.0
-Assigned To:
+Assigned To: pajoye
New Comment:
Under which SAPI do you run it? CLI, FCGI or apache?
Can you try again using
http://windows.php.net/downloads/qa/test/php-5.3.2-dev-nts-Win32-VC9-x86.zip
please?
Previous Comments:
[2009-09-22 07:52:52] philipp at servicemail24 dot de
Description:
PHP 5.3.0 and 5.3.1RC1 has a bug in the is_readable and is_writeable
function if you execute a script with normal windows user rights.
The same test script works fine using PHP 5.2.x. Providing admin rights
for the user solves the problem but this is not a long term solution for
us.
All tested PHP releases are VC6 TS
PHP 5.2.10 - OK
PHP 5.2.11 - OK
PHP 5.3.0 - FAILED
PHP 5.3.1RC1 - FAILED
Reproduce code:
---
$folders = array( '10.1.1.1\\share',
'srv\\share',
'd:/temp'
);
foreach($folders as $folder) {
if(@!is_readable($folder)) {
echo('FAILED is_readable: ' . $folder . \n);
} else {
echo OK is_readable: . $folder . \n;
}
if(@!is_writeable($folder)) {
echo('FAILED is_writeable: ' . $folder . \n);
} else {
echo OK is_writeable: . $folder . \n;
}
$filename = $folder . '\\test.txt';
if(@!file_put_contents($filename, 'php test')) {
echo('FAILED file_put_contents: ' . $filename . \n);
} else {
echo OK file_put_contents: . $filename . \n;
}
}
Expected result:
OK is_readable: \\10.1.1.1\share
OK is_writeable: \\10.1.1.1\share
OK file_put_contents: \\10.1.1.1\share\test.txt
OK is_readable: \\srv\share
OK is_writeable: \\srv\share
OK file_put_contents: \\srv\share\test.txt
OK is_readable: d:/temp
OK is_writeable: d:/temp
OK file_put_contents: d:/temp\test.txt
Actual result:
--
FAILED is_readable: \\10.1.1.1\share
FAILED is_writeable: \\10.1.1.1\share
OK file_put_contents: \\10.1.1.1\share\test.txt
FAILED is_readable: \\srv\share
FAILED is_writeable: \\srv\share
OK file_put_contents: \\srv\share\test.txt
OK is_readable: d:/temp
OK is_writeable: d:/temp
OK file_put_contents: d:/temp\test.txt
--
Edit this bug report at http://bugs.php.net/?id=49620edit=1
#49621 [NEW]: Output from scripts not sent correctly to the browser
From: qwirks at libero dot it Operating system: Windows 2003 Std Edition SP2 PHP version: 5.3.0 PHP Bug Type: Output Control Bug description: Output from scripts not sent correctly to the browser Description: Output string from scripts, which may take long time to execute, running under MySql5.1+Apache2.2+Php5.3, is not sent fully to the browser. Adding some echos into the code, the output stream stops in different lines of code each time. Installing Php5.2.11 with same configuration of Php5.3, seems to solve the problem. -- Edit bug report at http://bugs.php.net/?id=49621edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49621r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49621r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49621r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49621r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49621r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49621r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49621r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49621r=needscript Try newer version: http://bugs.php.net/fix.php?id=49621r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49621r=support Expected behavior: http://bugs.php.net/fix.php?id=49621r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49621r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49621r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49621r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49621r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49621r=dst IIS Stability: http://bugs.php.net/fix.php?id=49621r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49621r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49621r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49621r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49621r=mysqlcfg
#49621 [Opn-Fbk]: Output from scripts not sent correctly to the browser
ID: 49621 Updated by: paj...@php.net Reported By: qwirks at libero dot it -Status: Open +Status: Feedback Bug Type: Output Control Operating System: Windows 2003 Std Edition SP2 PHP Version: 5.3.0 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 ?php and ends 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: [2009-09-22 08:50:45] qwirks at libero dot it Description: Output string from scripts, which may take long time to execute, running under MySql5.1+Apache2.2+Php5.3, is not sent fully to the browser. Adding some echos into the code, the output stream stops in different lines of code each time. Installing Php5.2.11 with same configuration of Php5.3, seems to solve the problem. -- Edit this bug report at http://bugs.php.net/?id=49621edit=1
#49620 [Com]: is_writeable does not work using netshare and normal user rights
ID: 49620
Comment by: philipp at servicemail24 dot de
Reported By: philipp at servicemail24 dot de
Status: Feedback
Bug Type: *Directory/Filesystem functions
Operating System: Windows XP SP2
PHP Version: 5.3.0
Assigned To: pajoye
New Comment:
php-5.3.2-dev-nts-Win32-VC9-x86 has the same problem.
I run this script using CLI (cmd.exe Terminal running php.exe)
Previous Comments:
[2009-09-22 08:43:37] paj...@php.net
Under which SAPI do you run it? CLI, FCGI or apache?
Can you try again using
http://windows.php.net/downloads/qa/test/php-5.3.2-dev-nts-Win32-VC9-x86.zip
please?
[2009-09-22 07:52:52] philipp at servicemail24 dot de
Description:
PHP 5.3.0 and 5.3.1RC1 has a bug in the is_readable and is_writeable
function if you execute a script with normal windows user rights.
The same test script works fine using PHP 5.2.x. Providing admin rights
for the user solves the problem but this is not a long term solution for
us.
All tested PHP releases are VC6 TS
PHP 5.2.10 - OK
PHP 5.2.11 - OK
PHP 5.3.0 - FAILED
PHP 5.3.1RC1 - FAILED
Reproduce code:
---
$folders = array( '10.1.1.1\\share',
'srv\\share',
'd:/temp'
);
foreach($folders as $folder) {
if(@!is_readable($folder)) {
echo('FAILED is_readable: ' . $folder . \n);
} else {
echo OK is_readable: . $folder . \n;
}
if(@!is_writeable($folder)) {
echo('FAILED is_writeable: ' . $folder . \n);
} else {
echo OK is_writeable: . $folder . \n;
}
$filename = $folder . '\\test.txt';
if(@!file_put_contents($filename, 'php test')) {
echo('FAILED file_put_contents: ' . $filename . \n);
} else {
echo OK file_put_contents: . $filename . \n;
}
}
Expected result:
OK is_readable: \\10.1.1.1\share
OK is_writeable: \\10.1.1.1\share
OK file_put_contents: \\10.1.1.1\share\test.txt
OK is_readable: \\srv\share
OK is_writeable: \\srv\share
OK file_put_contents: \\srv\share\test.txt
OK is_readable: d:/temp
OK is_writeable: d:/temp
OK file_put_contents: d:/temp\test.txt
Actual result:
--
FAILED is_readable: \\10.1.1.1\share
FAILED is_writeable: \\10.1.1.1\share
OK file_put_contents: \\10.1.1.1\share\test.txt
FAILED is_readable: \\srv\share
FAILED is_writeable: \\srv\share
OK file_put_contents: \\srv\share\test.txt
OK is_readable: d:/temp
OK is_writeable: d:/temp
OK file_put_contents: d:/temp\test.txt
--
Edit this bug report at http://bugs.php.net/?id=49620edit=1
#49618 [Opn-Bgs]: spl_autoload_register destroys __autoload hook
ID: 49618
Updated by: sjo...@php.net
Reported By: jost dot boekemeier at googlemail dot com
-Status: Open
+Status: Bogus
Bug Type: SPL related
Operating System: Any
PHP Version: 5.2.11
New Comment:
Thank you for your report.
I do not think the behavior you describe is a bug. The documentation is
clear about this:
If your code has an existing __autoload function then this function
must be explicitly registered on the __autoload stack. This is because
spl_autoload_register() will effectively replace the engine cache for
the __autoload function by either spl_autoload() or
spl_autoload_call().
Thus, calling spl_autoload_register() replaces __autoload().
Previous Comments:
[2009-09-22 05:24:02] jost dot boekemeier at googlemail dot com
Description:
The first call to spl_autoload_register destroys an existing __autoload
hook.
Please either deprecate __autoload and/or register __autoload with
spl_autoload.
Complete problem description is here:
http://sourceforge.net/mailarchive/forum.php?
thread_name=3afa16cf0909210312v3e102491n18701bcca0f5e030%40mail.gmail.com
forum_name=php-java-bridge-users
Reproduce code:
---
?php
function autoload_legacy($x) {echo legacy ; return false;}
function autoload_spl1($x) {echo spl1 ; return false;}
function autoload_spl2($x) {echo spl2 ; return false;}
function autoload_spl3($x) {echo spl3 ; return false;}
spl_autoload_register(autoload_spl1);
function __autoload($x) {return autoload_legacy($x);}
spl_autoload_register(autoload_spl2);
spl_autoload_register(autoload_spl3);
@new Foo();
?
Expected result:
spl1 spl2 spl3 legacy
Actual result:
--
spl1 spl2 spl3
--
Edit this bug report at http://bugs.php.net/?id=49618edit=1
#49621 [Com]: Output from scripts not sent correctly to the browser
ID: 49621 Comment by: qwirks at libero dot it Reported By: qwirks at libero dot it Status: Feedback Bug Type: Output Control Operating System: Windows 2003 Std Edition SP2 PHP Version: 5.3.0 New Comment: The script which causes the problem is a very long and complex one with a lot of database queries from multiple tables, on a remote server. There is no way I can report the script here. However the script reads from database, executes calculations and presents the results to the user using smarty template engine. Previous Comments: [2009-09-22 08:56:25] paj...@php.net Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with ?php and ends 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. [2009-09-22 08:50:45] qwirks at libero dot it Description: Output string from scripts, which may take long time to execute, running under MySql5.1+Apache2.2+Php5.3, is not sent fully to the browser. Adding some echos into the code, the output stream stops in different lines of code each time. Installing Php5.2.11 with same configuration of Php5.3, seems to solve the problem. -- Edit this bug report at http://bugs.php.net/?id=49621edit=1
#49618 [Bgs]: spl_autoload_register destroys __autoload hook
ID: 49618
User updated by: jost dot boekemeier at googlemail dot com
Reported By: jost dot boekemeier at googlemail dot com
Status: Bogus
Bug Type: SPL related
Operating System: Any
PHP Version: 5.2.11
New Comment:
My code doesn't use __autoload.
My code uses spl_autoloload.
I have received a bug report because my code has destroyed an existing
library.
By issuing this bug report I have asked you to stop this, by either:
* deprecating __autoload altogether
* fix spl_autoload to honor an existing __autoload or
* let library authors check for an existing (or upcoming) __autoload so
that their
library doesn't destroy existing code
With the current behaviour I have no other choice but to not use
spl_autoload at all,
since I don't know whether the user will or will not include a library
which uses
__autoload later on.
Previous Comments:
[2009-09-22 09:11:12] sjo...@php.net
Thank you for your report.
I do not think the behavior you describe is a bug. The documentation is
clear about this:
If your code has an existing __autoload function then this function
must be explicitly registered on the __autoload stack. This is because
spl_autoload_register() will effectively replace the engine cache for
the __autoload function by either spl_autoload() or
spl_autoload_call().
Thus, calling spl_autoload_register() replaces __autoload().
[2009-09-22 05:24:02] jost dot boekemeier at googlemail dot com
Description:
The first call to spl_autoload_register destroys an existing __autoload
hook.
Please either deprecate __autoload and/or register __autoload with
spl_autoload.
Complete problem description is here:
http://sourceforge.net/mailarchive/forum.php?
thread_name=3afa16cf0909210312v3e102491n18701bcca0f5e030%40mail.gmail.com
forum_name=php-java-bridge-users
Reproduce code:
---
?php
function autoload_legacy($x) {echo legacy ; return false;}
function autoload_spl1($x) {echo spl1 ; return false;}
function autoload_spl2($x) {echo spl2 ; return false;}
function autoload_spl3($x) {echo spl3 ; return false;}
spl_autoload_register(autoload_spl1);
function __autoload($x) {return autoload_legacy($x);}
spl_autoload_register(autoload_spl2);
spl_autoload_register(autoload_spl3);
@new Foo();
?
Expected result:
spl1 spl2 spl3 legacy
Actual result:
--
spl1 spl2 spl3
--
Edit this bug report at http://bugs.php.net/?id=49618edit=1
#49616 [Opn]: Impossible to increase SOMAXCONN
ID: 49616 Updated by: sjo...@php.net Reported By: ben at realitychecknetwork dot com Status: Open Bug Type: Sockets related Operating System: Linux 2.6.18 PHP Version: 5.2.11 New Comment: PHP uses the SOMAXCONN from sys/socket.h at compile time. Previous Comments: [2009-09-21 20:22:24] ben at realitychecknetwork dot com Description: Impossible to increase SOMAXCONN value by updating system OS variable. PHP must be compiled with --enable-sockets for this bug to be produced. OS setting updated with: # sysctl -w net.core.somaxconn=2048 net.core.somaxconn = 2048 PHP will always return 128 for SOMAXCONN and will not respect the OS setting. Additionally, it will ignore a define statement in PHP code and return 128 as well. Reproduce code: --- define(SOMAXCONN, 2048); echo SOMAXCONN; Expected result: Should return 2048 Actual result: -- Returns 128 -- Edit this bug report at http://bugs.php.net/?id=49616edit=1
#49617 [Ver]: Problem with references
ID: 49617
Updated by: j...@php.net
-Summary: Pointers problem
Reported By: mstf at mstf dot name dot tr
Status: Verified
-Bug Type: Reproducible crash
+Bug Type: Scripting Engine problem
-Operating System: Windows XP
+Operating System: *
-PHP Version: 5.3.0
+PHP Version: 5.*, 6
New Comment:
PHP does not have pointers..
Previous Comments:
[2009-09-22 09:30:11] sjo...@php.net
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x
0x00470df9 in ZEND_FETCH_DIM_W_SPEC_CV_CONST_HANDLER
(execute_data=0xb68040) at zend_vm_execute.h:23568
23568 Z_DELREF_PP(EX_T(opline-result.u.var).var.ptr_ptr);
(gdb) bt
#0 0x00470df9 in ZEND_FETCH_DIM_W_SPEC_CV_CONST_HANDLER
(execute_data=0xb68040) at zend_vm_execute.h:23568
#1 0x003ec80e in execute (op_array=0xa109f0) at zend_vm_execute.h:104
#2 0x003bd57a in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /Users/sjoerd/Sources/php-src-5.3/Zend/zend.c:1188
#3 0x0034193d in php_execute_script (primary_file=0xb7fc) at
/Users/sjoerd/Sources/php-src-5.3/main/main.c:2213
#4 0x0049650f in main (argc=4, argv=0xb8e8) at
/Users/sjoerd/Sources/php-src-5.3/sapi/cli/php_cli.c:1190
(gdb)
[2009-09-22 01:18:48] mstf at mstf dot name dot tr
Description:
Pointers problem.
Reproduce code:
---
$a = array('a' = array('b' = 'c'));
$b = $a;
$b = $b['a'];
$b = $b['b'];
$b = $b['c'];
echo $b;
Expected result:
NULL
Actual result:
--
Apache Send Error Report
Apache error.log:
[Sat Aug 22 04:11:34 2009] [notice] Child 3408: Child process is
running
[Sat Aug 22 04:11:34 2009] [notice] Child 3408: Acquired the start
mutex.
[Sat Aug 22 04:11:34 2009] [notice] Child 3408: Starting 150 worker
threads.
[Sat Aug 22 04:11:34 2009] [notice] Child 3408: Starting thread to
listen on port 80.
[Sat Aug 22 04:11:34 2009] [notice] Child 3408: Starting thread to
listen on port 443.
--
Edit this bug report at http://bugs.php.net/?id=49617edit=1
#49617 [Ver]: Problem with references
ID: 49617
Updated by: j...@php.net
Reported By: mstf at mstf dot name dot tr
Status: Verified
Bug Type: Scripting Engine problem
Operating System: *
-PHP Version: 5.*, 6
+PHP Version: 5.3, 6 (2009-09-22)
New Comment:
# build/php_5_2/sapi/cli/php -n t.php
Fatal error: Cannot create references to/from string offsets nor
overloaded objects in /home/jani/src/t.php on line 8
# build/php_5_3/sapi/cli/php -n t.php
Segmentation fault
# build/php_6/sapi/cli/php -n t.php
Segmentation fault
Previous Comments:
[2009-09-22 09:43:09] j...@php.net
PHP does not have pointers..
[2009-09-22 09:30:11] sjo...@php.net
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x
0x00470df9 in ZEND_FETCH_DIM_W_SPEC_CV_CONST_HANDLER
(execute_data=0xb68040) at zend_vm_execute.h:23568
23568 Z_DELREF_PP(EX_T(opline-result.u.var).var.ptr_ptr);
(gdb) bt
#0 0x00470df9 in ZEND_FETCH_DIM_W_SPEC_CV_CONST_HANDLER
(execute_data=0xb68040) at zend_vm_execute.h:23568
#1 0x003ec80e in execute (op_array=0xa109f0) at zend_vm_execute.h:104
#2 0x003bd57a in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /Users/sjoerd/Sources/php-src-5.3/Zend/zend.c:1188
#3 0x0034193d in php_execute_script (primary_file=0xb7fc) at
/Users/sjoerd/Sources/php-src-5.3/main/main.c:2213
#4 0x0049650f in main (argc=4, argv=0xb8e8) at
/Users/sjoerd/Sources/php-src-5.3/sapi/cli/php_cli.c:1190
(gdb)
[2009-09-22 01:18:48] mstf at mstf dot name dot tr
Description:
Pointers problem.
Reproduce code:
---
$a = array('a' = array('b' = 'c'));
$b = $a;
$b = $b['a'];
$b = $b['b'];
$b = $b['c'];
echo $b;
Expected result:
NULL
Actual result:
--
Apache Send Error Report
Apache error.log:
[Sat Aug 22 04:11:34 2009] [notice] Child 3408: Child process is
running
[Sat Aug 22 04:11:34 2009] [notice] Child 3408: Acquired the start
mutex.
[Sat Aug 22 04:11:34 2009] [notice] Child 3408: Starting 150 worker
threads.
[Sat Aug 22 04:11:34 2009] [notice] Child 3408: Starting thread to
listen on port 80.
[Sat Aug 22 04:11:34 2009] [notice] Child 3408: Starting thread to
listen on port 443.
--
Edit this bug report at http://bugs.php.net/?id=49617edit=1
#49611 [Opn-Fbk]: file_get_contents() automatically including headers in output
ID: 49611
Updated by: j...@php.net
Reported By: d dot reade at readesresidential dot com
-Status: Open
+Status: Feedback
Bug Type: Filesystem function related
Operating System: CentOS 5.3 x86
PHP Version: 5.2.11
New Comment:
I can not reproduce this. Please provide the full script that causes
this, including the $url..
Previous Comments:
[2009-09-21 08:11:21] d dot reade at readesresidential dot com
I have managed to replicate the issue, multiple times. Here's the
code:
?
$array = array(1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1);
foreach($array as $val) {
$tmp= tempnam('/tmp', 'test_img_');
$file = file_get_contents($url);
file_put_contents($tmp, $file);
$img= imagecreatefrompng($tmp);
imagedestroy($img);
}
?
In my case $url was the direct http:// path to the image, in this
instance a high quality PNG over 1MB in size.
The script repeats 80 times (to mimic what my scripts are trying to
do). After the first run it stated 15 out of 80 of the PNGs were invalid
PNG files. On the second run it said 12 were invalid. The results are
different each time.
The error generated by PHP is:
Warning: imagecreatefrompng() [function.imagecreatefrompng]:
'/tmp/test_img_92M2J2' is not a valid PNG file in
/home/readesre/public_html/dev/img.php on line 12
Warning: imagedestroy(): supplied argument is not a valid Image
resource in /home/readesre/public_html/dev/img.php on line 14
Here's the list of files from the tmp folder:
-rw--- 1 nobody nobody 1778247 Sep 21 09:01 test_img_92M2J2
-rw--- 1 nobody nobody 1777966 Sep 21 09:01 test_img_bHZKlf
-rw--- 1 nobody nobody 1777966 Sep 21 09:01 test_img_btMJcI
-rw--- 1 nobody nobody 1777966 Sep 21 09:01 test_img_DctHCw
-rw--- 1 nobody nobody 1777966 Sep 21 09:01 test_img_dnosxg
-rw--- 1 nobody nobody 1777966 Sep 21 09:01 test_img_DOZKw1
-rw--- 1 nobody nobody 1777966 Sep 21 09:01 test_img_DxQcqp
-rw--- 1 nobody nobody 1777966 Sep 21 09:01 test_img_f95art
-rw--- 1 nobody nobody 1778247 Sep 21 09:01 test_img_H5SukI
-rw--- 1 nobody nobody 1777966 Sep 21 09:01 test_img_LcT3ss
-rw--- 1 nobody nobody 1777966 Sep 21 09:01 test_img_lkEMhQ
-rw--- 1 nobody nobody 1777966 Sep 21 09:01 test_img_lucjnA
-rw--- 1 nobody nobody 1777966 Sep 21 09:01 test_img_nksxx7
-rw--- 1 nobody nobody 1777966 Sep 21 09:01 test_img_To6cXV
-rw--- 1 nobody nobody 1777966 Sep 21 09:01 test_img_vEzSrY
-rw--- 1 nobody nobody 1777966 Sep 21 09:01 test_img_vqmVzZ
-rw--- 1 nobody nobody 1777966 Sep 21 09:01 test_img_x8cIzF
-rw--- 1 nobody nobody 1778247 Sep 21 09:01 test_img_XzAwHt
-rw--- 1 nobody nobody 1777966 Sep 21 09:01 test_img_ZA0s5W
-rw--- 1 nobody nobody 1778247 Sep 21 09:01 test_img_ZgkSty
-rw--- 1 nobody nobody 1777966 Sep 21 09:01 test_img_zVa5gj
This is only a snippet of the full list, but notice the file sizes. The
files that are 1778247 in size contain the following header info:
HTTP/1.1 200 OK
Date: Mon, 21 Sep 2009 08:01:24 GMT
Server: Apache
Last-Modified: Fri, 18 Sep 2009 10:26:04 GMT
Accept-Ranges: bytes
Content-Length: 1777966
Cache-Control: max-age=2592000
Expires: Wed, 21 Oct 2009 08:01:24 GMT
Connection: close
Content-Type: image/png
�PNG
Followed by the rest of the PNG file...
[2009-09-20 23:03:15] ras...@php.net
It would be really helpful if you could create an actual script that
reproduces this. It isn't until the 8th comment on this bug that we
learn that it only happens if you are doing a whole bunch of them
together. Your original reproducing script not only didn't have any
network component, but it also didn't have anything about multiple
connections.
How are you doing these multiple connections? Just a big loop around
file_get_contents? The best way to report a bug is to simplify your
problem down into a script that we can run ourselves and see the
problem. If we can see it, we can fix it. Otherwise we are guessing as
to what might be happening on your end.
[2009-09-20 22:44:06] paj...@php.net
I was thinking about a bug the curl stream wrapper, but no. I can't
reproduce this problem either, no matter the web server/OS/platform.
[2009-09-20 22:21:10] d dot reade at readesresidential dot com
Sure, here it is:
'./configure' '--disable-pdo' '--enable-bcmath' '--enable-calendar'
'--enable-ftp'
#49617 [Opn-Ver]: Pointers problem
ID: 49617
Updated by: sjo...@php.net
Reported By: mstf at mstf dot name dot tr
-Status: Open
+Status: Verified
-Bug Type: *General Issues
+Bug Type: Reproducible crash
Operating System: Windows XP
PHP Version: 5.3.0
New Comment:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x
0x00470df9 in ZEND_FETCH_DIM_W_SPEC_CV_CONST_HANDLER
(execute_data=0xb68040) at zend_vm_execute.h:23568
23568 Z_DELREF_PP(EX_T(opline-result.u.var).var.ptr_ptr);
(gdb) bt
#0 0x00470df9 in ZEND_FETCH_DIM_W_SPEC_CV_CONST_HANDLER
(execute_data=0xb68040) at zend_vm_execute.h:23568
#1 0x003ec80e in execute (op_array=0xa109f0) at zend_vm_execute.h:104
#2 0x003bd57a in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /Users/sjoerd/Sources/php-src-5.3/Zend/zend.c:1188
#3 0x0034193d in php_execute_script (primary_file=0xb7fc) at
/Users/sjoerd/Sources/php-src-5.3/main/main.c:2213
#4 0x0049650f in main (argc=4, argv=0xb8e8) at
/Users/sjoerd/Sources/php-src-5.3/sapi/cli/php_cli.c:1190
(gdb)
Previous Comments:
[2009-09-22 01:18:48] mstf at mstf dot name dot tr
Description:
Pointers problem.
Reproduce code:
---
$a = array('a' = array('b' = 'c'));
$b = $a;
$b = $b['a'];
$b = $b['b'];
$b = $b['c'];
echo $b;
Expected result:
NULL
Actual result:
--
Apache Send Error Report
Apache error.log:
[Sat Aug 22 04:11:34 2009] [notice] Child 3408: Child process is
running
[Sat Aug 22 04:11:34 2009] [notice] Child 3408: Acquired the start
mutex.
[Sat Aug 22 04:11:34 2009] [notice] Child 3408: Starting 150 worker
threads.
[Sat Aug 22 04:11:34 2009] [notice] Child 3408: Starting thread to
listen on port 80.
[Sat Aug 22 04:11:34 2009] [notice] Child 3408: Starting thread to
listen on port 443.
--
Edit this bug report at http://bugs.php.net/?id=49617edit=1
#49621 [Fbk-Bgs]: Output from scripts not sent correctly to the browser
ID: 49621 Updated by: j...@php.net Reported By: qwirks at libero dot it -Status: Feedback +Status: Bogus Bug Type: Output Control Operating System: Windows 2003 Std Edition SP2 PHP Version: 5.3.0 New Comment: You're propably doing something wrong then. Can not reproduce - bogus. Previous Comments: [2009-09-22 09:15:16] qwirks at libero dot it The script which causes the problem is a very long and complex one with a lot of database queries from multiple tables, on a remote server. There is no way I can report the script here. However the script reads from database, executes calculations and presents the results to the user using smarty template engine. [2009-09-22 08:56:25] paj...@php.net Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with ?php and ends 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. [2009-09-22 08:50:45] qwirks at libero dot it Description: Output string from scripts, which may take long time to execute, running under MySql5.1+Apache2.2+Php5.3, is not sent fully to the browser. Adding some echos into the code, the output stream stops in different lines of code each time. Installing Php5.2.11 with same configuration of Php5.3, seems to solve the problem. -- Edit this bug report at http://bugs.php.net/?id=49621edit=1
#49620 [Fbk-Asn]: is_writeable does not work using netshare and normal user rights
ID: 49620
Updated by: j...@php.net
Reported By: philipp at servicemail24 dot de
-Status: Feedback
+Status: Assigned
Bug Type: *Directory/Filesystem functions
-Operating System: Windows XP SP2
+Operating System: win32 only - Windows XP SP2
PHP Version: 5.3.0
Assigned To: pajoye
New Comment:
Why did you add a comment? The link sent to you does not take you to
the Add comment page but to the edit your submission. Next time when
someone asks for feedback, use the proper method in replying.
Previous Comments:
[2009-09-22 08:58:03] philipp at servicemail24 dot de
php-5.3.2-dev-nts-Win32-VC9-x86 has the same problem.
I run this script using CLI (cmd.exe Terminal running php.exe)
[2009-09-22 08:43:37] paj...@php.net
Under which SAPI do you run it? CLI, FCGI or apache?
Can you try again using
http://windows.php.net/downloads/qa/test/php-5.3.2-dev-nts-Win32-VC9-x86.zip
please?
[2009-09-22 07:52:52] philipp at servicemail24 dot de
Description:
PHP 5.3.0 and 5.3.1RC1 has a bug in the is_readable and is_writeable
function if you execute a script with normal windows user rights.
The same test script works fine using PHP 5.2.x. Providing admin rights
for the user solves the problem but this is not a long term solution for
us.
All tested PHP releases are VC6 TS
PHP 5.2.10 - OK
PHP 5.2.11 - OK
PHP 5.3.0 - FAILED
PHP 5.3.1RC1 - FAILED
Reproduce code:
---
$folders = array( '10.1.1.1\\share',
'srv\\share',
'd:/temp'
);
foreach($folders as $folder) {
if(@!is_readable($folder)) {
echo('FAILED is_readable: ' . $folder . \n);
} else {
echo OK is_readable: . $folder . \n;
}
if(@!is_writeable($folder)) {
echo('FAILED is_writeable: ' . $folder . \n);
} else {
echo OK is_writeable: . $folder . \n;
}
$filename = $folder . '\\test.txt';
if(@!file_put_contents($filename, 'php test')) {
echo('FAILED file_put_contents: ' . $filename . \n);
} else {
echo OK file_put_contents: . $filename . \n;
}
}
Expected result:
OK is_readable: \\10.1.1.1\share
OK is_writeable: \\10.1.1.1\share
OK file_put_contents: \\10.1.1.1\share\test.txt
OK is_readable: \\srv\share
OK is_writeable: \\srv\share
OK file_put_contents: \\srv\share\test.txt
OK is_readable: d:/temp
OK is_writeable: d:/temp
OK file_put_contents: d:/temp\test.txt
Actual result:
--
FAILED is_readable: \\10.1.1.1\share
FAILED is_writeable: \\10.1.1.1\share
OK file_put_contents: \\10.1.1.1\share\test.txt
FAILED is_readable: \\srv\share
FAILED is_writeable: \\srv\share
OK file_put_contents: \\srv\share\test.txt
OK is_readable: d:/temp
OK is_writeable: d:/temp
OK file_put_contents: d:/temp\test.txt
--
Edit this bug report at http://bugs.php.net/?id=49620edit=1
#49606 [Fbk]: empty( $this-variable )
ID: 49606
Updated by: j...@php.net
Reported By: clin dot isbut at gmail dot com
Status: Feedback
Bug Type: Scripting Engine problem
Operating System: Windows Xp
PHP Version: 5.3.0
New Comment:
I still can not reproduce this with the class extending mysqli. Please
try the snapshot. (And next time, DO NOT use the Add comment tab when
you add comments to your _own_ report! Use the Edit Submission tab!)
Previous Comments:
[2009-09-20 18:25:21] clin dot isbut at gmail dot com
Sorry, expected and actual result are as this:
Expected result:
Publish_date: 45678
publish IS NOT EMPTY!
Actual result:
---
Publish_date: 45678
publish IS EMPTY!
[2009-09-20 18:14:32] clin dot isbut at gmail dot com
Ok, I found the root of problems. Seems it fails when the class extends
mysqli class (?¿). See this:
Reproduce code:
---
FooClass.php
class FooClass extends mysqli
{
var $publish_date;
function __construct()
{
}
function foo( $var )
{
$this-publish_date = $var;
echo Publish_date:.$this-publish_date.br;
if( empty( $this-publish_date ) )
echo publish IS EMPTY!br;
else
echo publish IS NOT EMPTY!br;
}
}
Index.php
include (FooClass.php);
$obj = new FooClass();
$obj-foo( '45678' );
Expected result:
Publish_date: 45678
publish IS NOT EMPTY!
Actual result:
---
Publish_date: 45678
publish IS NOT EMPTY!
I expect this time you can reproduce it.
[2009-09-20 17:45:24] clin dot isbut at gmail dot com
Seems like my example code does not reproduce the error. I'll try to
reduce my failing code to write here.
[2009-09-20 17:23:18] j...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Works fine for me..
[2009-09-20 11:15:04] clin dot isbut at gmail dot com
Description:
empty( $this-variable ) returns always true.
Reproduce code:
---
class FooClass
{
var $publish;
function foo()
{
$this-publish = '123456';
if( empty( $this-publish ) )
echo publish is empty.;
else
echo publish is NOT empty.;
}
}
Expected result:
publish is NOT empty.
Actual result:
--
publish is empty.
--
Edit this bug report at http://bugs.php.net/?id=49606edit=1
#49570 [Fbk-Opn]: $_POST is empty with large file uploads
ID: 49570 Updated by: j...@php.net Reported By: erikvernsmith at yahoo dot com -Status: Feedback +Status: Open Bug Type: Filesystem function related Operating System: Mac OS 10.6.1 PHP Version: 5.3.0 Previous Comments: [2009-09-16 13:48:18] erikvernsmith at yahoo dot com Description: I set upload_max_filesize in php.ini to 64M I'm using a simple html form to post/upload a file to a simple php script. If I upload files smaller than 8MB everything works fine. If I upload a file larger than 8MB, print_r( $_POST ) and print_r( $_FILES ) are empty. Important note: 8MB is not a magic number. On my localhost 10MB files do upload, but 50MB files do not. 8MB files will not work on my remote website, but 7MB files will work. Reproduce code: --- complete HTML file: form enctype=multipart/form-data action=simpleuploadtest.php method=POST input type=text name=mytitle value=junkjunk and more junk / Choose a file to upload: input name=uploadedfile value= type=file /br / input type=submit value=Upload File / /form complete PHP file: ?php echo 'testing123BRBR'; echo $_POST['mytitle']; echo 'BRBR'; print_r( $_POST ); echo 'BRBR'; print_r( $_FILES ); ? Expected result: I expect the $_POST and $_FILES arrays to have contents, like this: testing123 junkjunk and more junk Array ( [mytitle] = junkjunk and more junk ) Array ( [uploadedfile] = Array ( [name] = junk.bin [type] = application/macbinary [tmp_name] = /private/var/tmp/php0tupN2 [error] = 0 [size] = 10485760 ) ) Actual result: -- The $_POST and $_FILES arrays are empty, like this: testing123 Array ( ) Array ( ) -- Edit this bug report at http://bugs.php.net/?id=49570edit=1
#49559 [Fbk-Bgs]: php: free(): invalid pointer: 0x0a48f6b0 ***
ID: 49559 Updated by: j...@php.net Reported By: 12985462 at QQ dot com -Status: Feedback +Status: Bogus Bug Type: CGI related Operating System: CentOS 5.3 32bit PHP Version: 5.2.10 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Previous Comments: [2009-09-16 03:21:48] 1298462 at QQ dot com and if who want to goolge tcmalloc,please don't link tcmalloc to mysql client. if your mysql client with '--enable-thread-safe-client' with/without tcmalloc ,the zend optimizer it's can't working. if you mysql clinet with '--disable-thread-safe-client' and without google tcmalloc, the zend optimizer it's working. Tested on centos 5.3 32bit and ubuntu server 9.04 64bit. [2009-09-16 03:15:49] 12985462 at QQ dot com Fixed! I have remake mysql with '--disable-thread-safe-client' Zend Optimizer it's working!!with '--enable-thread-safe-client' Zend Optimizer it's can't working. In Zend 3.3.9 don't support thread-safe,The Zend 3.3.9 don't include TS edition. working : ./configure --prefix='/var/webserver/mysql' '--libexecdir=/var/webserver/mysql/bin' '--with-comment=MySQL Server XTM Edition(GPL)''--disable-thread-safe-client' '--enable-local-infile' '--enable-assembler' '--with-pic' '--with-readline' '--without-debug' '--with-unix-socket-path=/tmp/mysqld.sock' '--with-extra-charsets=complex' CFLAGS='-O2 -unroll2 -ip -xW' CXXFLAGS='-O2 -unroll2 -ip -fno-implicit-templates -fno-exceptions -fno-rtti -xW' '--with-low-memory' '--without-server' make [2009-09-15 10:56:26] 12985462 at QQ dot com Zend optimizer Removed ,it's working! [2009-09-15 06:19:56] paj...@php.net Please remove the Zend optimizer and try again. [2009-09-15 06:16:55] 12985462 at QQ dot com Description: OS:CentOS 5.3 CPU:Intel(R) Core(TM)2 Quad CPU Q9300 @ 2.50GHz MEM:256M PHP Version:PHP 5.2.10 + Zend Optimizer v3.3.9 - SELinux is disabled!!! - Compiler : icc -V Intel(R) C Compiler for applications running on IA-32, Version 10.1 Build 20090817 Package ID: l_cc_p_10.1.025 Copyright (C) 1985-2009 Intel Corporation. All rights reserved. FOR NON-COMMERCIAL USE ONLY - gcc -v Using built-in specs. Target: i386-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=i386-redhat-linux Thread model: posix gcc version 4.1.2 20080704 (Red Hat 4.1.2-44) --- compiling with CC=icc CXX=icpc CFLAGS='-O2 -unroll2 -ip -fp-model source -restrict -xW ' CXXFLAGS='-O2 -unroll2 -ip -fp-model source -restrict -fno-implicit-templates -fno-exceptions -fno-rtti -xW ' ./configure --prefix=/var/webserver/php --with-config-file-path=/var/webserver/php/etc --with-mysql=/var/webserver/mysql --with-mysqli=/var/webserver/mysql/bin/mysql_config --with-iconv-dir=/usr/local --with-freetype-dir --with-jpeg-dir --with-png-dir --with-zlib --with-libxml-dir=/usr --enable-xml --disable-rpath --enable-discard-path --enable-bcmath --enable-shmop --enable-sysvsem --enable-inline-optimization --with-curl --with-curlwrappers --enable-mbregex --enable-fastcgi --enable-fpm --enable-force-cgi-redirect --enable-mbstring --with-gd --enable-gd-native-ttf --with-openssl --enable-pcntl --enable-sockets --with-mcrypt --with-mhash --without-pear --disable-debug --disable-ipv6 php.ini [Zend] zend_extension=/var/webserver/zend/ZendOptimizer.so zend_optimizer.optimization_level=1023 ldd /var/webserver/php/bin/php libcrypt.so.1 = /lib/libcrypt.so.1 (0xb7f8f000) librt.so.1 = /lib/librt.so.1 (0xb7f86000) libmhash.so.2 = /usr/lib/libmhash.so.2 (0xb7f3f000) libmcrypt.so.4 = /usr/lib/libmcrypt.so.4
#49622 [NEW]: allow usage of json and/or php standard serialize format for sessions
From: giunta dot gaetano at gmail dot com Operating system: !important PHP version: 5.3.0 PHP Bug Type: Feature/Change Request Bug description: allow usage of json and/or php standard serialize format for sessions Description: The current session_decode() function is good when the user needs to decode a serialized session string, but it - needs to have session_start() called beforehand - has an impact on the current session state A lot of comments in the php man pages for unserialize() and session_decode() are from users trying to write a preg_ based decoder of session data (and failing). A new function that session_decode_to_array() that - returned the deserialized data as an array - did not impact current session state would imho be quite useful (or adding a flag param to the existing function, to the same effect) Since this feat. request has already been filed and closed as bogus (http://bugs.php.net/bug.php?id=42725), what I am proposing here is slightly different: besides 'wddx' and 'php', allow usage of 'json' and 'serialize' as native serialization formats for session data - the latter corresponding to the native serialize function. If there is some information loss involved in using those two formats (ie. references), just make it clear in the docs. -- Edit bug report at http://bugs.php.net/?id=49622edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49622r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49622r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49622r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49622r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49622r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49622r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49622r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49622r=needscript Try newer version: http://bugs.php.net/fix.php?id=49622r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49622r=support Expected behavior: http://bugs.php.net/fix.php?id=49622r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49622r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49622r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49622r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49622r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49622r=dst IIS Stability: http://bugs.php.net/fix.php?id=49622r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49622r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49622r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49622r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49622r=mysqlcfg
#49567 [Opn]: DOM/XSL: Suggestion: registerObjectMethods()
ID: 49567
Updated by: chr...@php.net
Reported By: mjs at beebo dot org
Status: Open
Bug Type: Feature/Change Request
Operating System: OS X
PHP Version: 5.3.0
New Comment:
Thanks for your work. I didn't test it out, but looking at the code 2
questions pop up:
You can register exactly one object?
and
What happens, if there's a function with that name? eg. 'add' in your
test?
Not sure, if I'm happy how it is right now, but it certainly goes into
the right direction.
Previous Comments:
[2009-09-22 07:14:34] mjs at beebo dot org
Had a look at how the xsl extension works, and had a shot at
implementing this myself--the patch is below.
Instead of adding a new function I enhanced registerPHPFunctions() so
that it can take an object. It works like this: if an object is
provided (say $foo), then xsl:value-of select=php:function('quux',
44)/ in the XSL results in a call to $foo-quux(44).
i.e. in PHP:
$foo = new Foo();
$processor-registerPHPFunctions($foo);
In XSL:
xsl:value-of select=php:function('quux', 44)/
Two of the tests in ext/xsl failed, but they fail without this patch
also.
The patch is:
Index: ext/xsl/tests/xsltprocessor_registerPHPFunctions-method.phpt
===
--- ext/xsl/tests/xsltprocessor_registerPHPFunctions-method.phpt
(revision 0)
+++ ext/xsl/tests/xsltprocessor_registerPHPFunctions-method.phpt
(revision 0)
@@ -0,0 +1,38 @@
+--TEST--
+Checks XSLTProcessor::registerPHPFunctions($obj) where the
functions
+exposed in the XSL file are methods of $obj.
+--SKIPIF--
+?php
+if (!extension_loaded('xsl')) {
+die(skip\n);
+}
+?
+--FILE--
+?php
+
+class Foo {
+public function greet($name) {
+return Hello, $name;
+}
+public function add($i, $j) {
+return $i + $j;
+}
+}
+
+$xml = new DOMDocument();
+$xml-loadXML(root/);
+$xsl = new DOMDocument();
+$xsl-load(dirname(__FILE__) . /phpmethod.xsl);
+
+$proc = new XSLTProcessor();
+$proc-importStylesheet($xsl);
+
+$foo = new Foo();
+
+$proc-registerPHPFunctions($foo);
+
+echo $proc-transformToXml($xml);
+--EXPECTF--
+result greet=Hello, Clem add=7/
+--CREDITS--
+Michael Stillwell m...@beebo.org
\ No newline at end of file
Index: ext/xsl/tests/phpmethod.xsl
===
--- ext/xsl/tests/phpmethod.xsl (revision 0)
+++ ext/xsl/tests/phpmethod.xsl (revision 0)
@@ -0,0 +1,15 @@
+xsl:stylesheet
+ version=1.0
+ xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
+ xmlns:php=http://php.net/xsl;
+ exclude-result-prefixes=php
+ xsl:output omit-xml-declaration=yes/
+xsl:template match=/
+ result
+ !-- pass a single string argument --
+ xsl:attribute name=greetxsl:value-of
select=php:function('greet', 'Clem')//xsl:attribute
+ !-- pass two integer arguments --
+ xsl:attribute name=addxsl:value-of select=php:function('add',
3, 4)//xsl:attribute
+ /result
+/xsl:template
+/xsl:stylesheet
\ No newline at end of file
Index: ext/xsl/php_xsl.h
===
--- ext/xsl/php_xsl.h (revision 288545)
+++ ext/xsl/php_xsl.h (working copy)
@@ -55,6 +55,7 @@
HashTable *node_list;
php_libxml_node_object *doc;
char *profiling;
+ zval *object_ptr;
} xsl_object;
void php_xsl_set_object(zval *wrapper, void *obj TSRMLS_DC);
Index: ext/xsl/xsltprocessor.c
===
--- ext/xsl/xsltprocessor.c (revision 288545)
+++ ext/xsl/xsltprocessor.c (working copy)
@@ -308,11 +308,11 @@
fci.function_name = handler;
fci.symbol_table = NULL;
- fci.object_ptr = NULL;
fci.retval_ptr_ptr = retval;
fci.no_separation = 0;
+ fci.object_ptr = intern-object_ptr ? intern-object_ptr :
NULL;
/*fci.function_handler_cache = function_ptr;*/
- if (!zend_make_callable(handler, callable TSRMLS_CC)) {
+ if ((intern-registerPhpFunctions != 3)
!zend_make_callable(handler, callable TSRMLS_CC)) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, Unable to
call handler %s(), callable);
} else if ( intern-registerPhpFunctions == 2
zend_hash_exists(intern-registered_phpfunctions, callable,
strlen(callable) + 1) == 0) {
@@ -320,6 +320,9 @@
/* Push an empty string, so that we at least have an
xslt result... */
valuePush(ctxt, xmlXPathNewString());
} else {
+ if (intern-object_ptr) {
+ fci.object_ptr = intern-object_ptr;
+ }
result = zend_call_function(fci, NULL TSRMLS_CC);
if (result == FAILURE) {
if (Z_TYPE(handler) == IS_STRING) {
@@ -794,6 +797,7 @@
zval *id;
xsl_object *intern;
#49623 [NEW]: PHP shows deprecation warning BEFORE compressed body
From: 3 at 14 dot by
Operating system: 2.6.28-15-generic #49-Ubuntu SMP
PHP version: 5.3.0
PHP Bug Type: Output Control
Bug description: PHP shows deprecation warning BEFORE compressed body
Description:
I have set Error_Reporting(0) both in the script in the php.ini.
I have an PHPBB forum (3.0.6) with zlib compression turned on.
Most of the warnings are gone, but in some cases (when some data is sent
via POST), I am still getting a Notice bdate(): It is not safe to rely
on the system's timezone settings., and it is printed BEFORE compressed
page body, so that browser reports broken encoding.
After disabling zlib compression browser started to show notice and page
content. After setting date.timezone in php.ini Notice is gone.
Reproduce code:
---
Install PHPBB 3.0.6: turn zlib compression = on, make sure to unset
date.timezone in php.ini. Then try to reply to a private message.
Expected result:
No notices on the screen, no broken encoding
Actual result:
--
HTTP/1.1 200 OK
Server: nginx
Date: Tue, 22 Sep 2009 13:09:15 GMT
Content-Type: text/html; charset=UTF-8
Connection: close
Expires: 0
Last-Modified: Tue, 22 Sep 2009 13:09:15 GMT
Cache-Control: private, no-cache=set-cookie
Pragma: no-cache
Content-Encoding: gzip
Vary: Accept-Encoding
Content-Length: 3181
b[phpBB Debug] PHP Notice/b: in file
b/includes/functions_messenger.php/b on line b390/b: bdate(): It
is not safe to rely on the system's timezone settings. You are *required*
to use the date.timezone setting or the date_default_timezone_set()
function. In case you used any of those methods and you are still getting
this warning, you most likely misspelled the timezone identifier. We
selected 'Europe/Moscow' for 'MSD/4.0/DST' instead/bbr /
.n.8...
V.I[[..\j[..4.)..l.@iu
.Cv_...%{.)..%i.S#.E...d9.t,..w./.3..o../H..O.u._9...N..;^[fSw..{.T:.V...i.:tF..ar..Dy[.t.yb.s...h2.h8j6.1..
2.,.-.H.C...hv.]d2 AD3...n|.:v.;[here goes the rest of the
compressed page]
--
Edit bug report at http://bugs.php.net/?id=49623edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49623r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49623r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49623r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49623r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49623r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49623r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49623r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49623r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49623r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49623r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49623r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49623r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49623r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49623r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49623r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49623r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49623r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49623r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49623r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49623r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49623r=mysqlcfg
#49624 [NEW]: xxxxxxxxxxxxxxxxxxxxx
From: js8jim at msn dot com Operating system: windows xpsp3 PHP version: 5.3.0 PHP Bug Type: Unknown/Other Function Bug description: x Description: i have screenshot to send. please reply. thank you. -jim Reproduce code: --- x Expected result: Actual result: -- xx -- Edit bug report at http://bugs.php.net/?id=49624edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49624r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49624r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49624r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49624r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49624r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49624r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49624r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49624r=needscript Try newer version: http://bugs.php.net/fix.php?id=49624r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49624r=support Expected behavior: http://bugs.php.net/fix.php?id=49624r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49624r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49624r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49624r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49624r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49624r=dst IIS Stability: http://bugs.php.net/fix.php?id=49624r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49624r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49624r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49624r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49624r=mysqlcfg
#49478 [Fbk-Opn]: shell_exec does not work
ID: 49478
User updated by: elmue at gmx dot de
Reported By: elmue at gmx dot de
-Status: Feedback
+Status: Open
Bug Type: Program Execution
Operating System: Windows
PHP Version: 6SVN-2009-09-06 (snap)
Assigned To: pajoye
New Comment:
Hello
On which PHP6 version did you test it ?
Did you test on Windows ?
I used version build Sep 3 2009 21:23:55
Previous Comments:
[2009-09-22 08:41:40] paj...@php.net
I can't reproduce it with php6 neither with 5.3 or 5.2 in CLI or FCGI.
Can you try it with CLI/CGI too please?
[2009-09-22 05:18:15] ian at iglou dot com
Also broken in PHP Version 5.2.10; safe mode off.
An earlier version (no record of which) did work when used thus to get
a Windows dvd volume label:
if (preg_match('#Volume in drive [a-zA-Z]* is (.*)\n#i',
shell_exec('dir '.$drive.':'), $m)) {
$volname = ' ('.$m[1].')';
[2009-09-06 00:49:59] elmue at gmx dot de
Description:
On PHP 6 VC 6 from 3.sept.2009 the shell_exec command is broken.
Tested on Xampp on Windows XP with Apache 2.2.9.
Whatever you put into shell_exec e.g.
shell_exec(dir C:\\)
produces a
Warning shell_exec() [function.shell-exec]: Unable to execute 'dir
c:\'
The same script works fine on PHP 5
--
Edit this bug report at http://bugs.php.net/?id=49478edit=1
#49262 [Opn]: PDO MySQL doesn't take STRING params
ID: 49262
Updated by: u...@php.net
Reported By: grzegorz at heex dot pl
Status: Open
Bug Type: PDO related
Operating System: Win XP Sp3
PHP Version: 5.3.0
New Comment:
Ok, great. Your character set is uft8 (uft8_general_ci is the
collation).
Can you paste SHOW VARIABLES LIKE '%character%' to give details about
your MySQL settings?
Thanks!
Previous Comments:
[2009-09-20 22:44:06] grzegorz at heex dot pl
Column lng_name and a whole table they have utf8_general_ci charset.
[2009-09-18 08:39:34] u...@php.net
Can you say anything about the character sets you are using?
[2009-08-25 07:57:54] grzegorz at heex dot pl
FunctionArg 1 Arg 2 Arg 3 Source
php5ts!mysqlnd_cset_escape_slashes+30 05652000
0565fb58
php_pdo_mysql!_pdo_mysql_error+6f7 0565f5880565fb58
0006
php5ts!pdo_parse_params+394 05662d5005662e780026
php5ts!pdo_stmt_describe_columns+7720565f638
php5ts!execute+10b9 05690070015e5801007f66b8
php5ts!execute+156d 015e585803e8fbe0
php5ts!execute+298 0565dbf0015e5800015e5858
php5ts!zend_execute_scripts+fe 0008015e5858
php5ts!php_execute_script+231 03e8fe6c015e58580005
php5apache2_2!zm_info_apache+1744 007aa7600073a400
007aa760
libhttpd!ap_run_handler+21 007aa760007aa760007aa760
libhttpd!ap_invoke_handler+ae 007a771803e8ff38
libhttpd!ap_die+24e 007aa7600073aac8
libhttpd!ap_get_request_note+1c6c 007a7718007a7718
007a7718
libhttpd!ap_run_process_connection+21 007a77180074a198
03e8ff80
libhttpd!ap_process_connection+33 007a7718007a26d8
0006fb80
libhttpd!ap_regkey_value_remove+c0c 007a77100006fb80
00eb0650
msvcrt!_endthreadex+a9 0079ef880006fb8000eb0650
kernel32!BaseThreadStart+37 77c2a3410079ef88
PHP5TS!MYSQLND_CSET_ESCAPE_SLASHES+30In
httpd__PID__4604__Date__08_25_2009__Time_09_37_39AM__46__Second_Chance_Exception_C005.dmp
the assembly instruction at php5ts!mysqlnd_cset_escape_slashes+30 in
C:\php5\php5ts.dll from The PHP Group has caused an access violation
exception (0xC005) when trying to read from memory location
0x0010 on thread 157
[2009-08-24 19:55:42] sjo...@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32
Once you have generated a backtrace, please submit it to this bug
report and change the status back to Open. Thank you for helping
us make PHP better.
[2009-08-14 20:23:43] grzegorz at heex dot pl
Description:
Now, PDO in PHP 5.3 is usless.
Reproduce code:
---
$name = 'same_name';
$pdo= new
PDO(mysql:host=localhost;dbname=[base];,'[user]','[pass]');
$sth = $pdo-prepare(SELECT * FROM lng WHERE lng_name=:Name);
$sth-bindValue(':Name',$name,PDO::PARAM_STR);
$sth-execute();
die('OK');
Expected result:
OK
Actual result:
--
PHP CGI / FastCGI crash
--
Edit this bug report at http://bugs.php.net/?id=49262edit=1
#49478 [Opn]: shell_exec does not work
ID: 49478
Updated by: paj...@php.net
Reported By: elmue at gmx dot de
Status: Open
Bug Type: Program Execution
Operating System: Windows
PHP Version: 6SVN-2009-09-06 (snap)
Assigned To: pajoye
New Comment:
Windows, today snaps.
Previous Comments:
[2009-09-22 13:46:42] elmue at gmx dot de
Hello
On which PHP6 version did you test it ?
Did you test on Windows ?
I used version build Sep 3 2009 21:23:55
[2009-09-22 08:41:40] paj...@php.net
I can't reproduce it with php6 neither with 5.3 or 5.2 in CLI or FCGI.
Can you try it with CLI/CGI too please?
[2009-09-22 05:18:15] ian at iglou dot com
Also broken in PHP Version 5.2.10; safe mode off.
An earlier version (no record of which) did work when used thus to get
a Windows dvd volume label:
if (preg_match('#Volume in drive [a-zA-Z]* is (.*)\n#i',
shell_exec('dir '.$drive.':'), $m)) {
$volname = ' ('.$m[1].')';
[2009-09-06 00:49:59] elmue at gmx dot de
Description:
On PHP 6 VC 6 from 3.sept.2009 the shell_exec command is broken.
Tested on Xampp on Windows XP with Apache 2.2.9.
Whatever you put into shell_exec e.g.
shell_exec(dir C:\\)
produces a
Warning shell_exec() [function.shell-exec]: Unable to execute 'dir
c:\'
The same script works fine on PHP 5
--
Edit this bug report at http://bugs.php.net/?id=49478edit=1
#49478 [Opn-Fbk]: shell_exec does not work
ID: 49478
Updated by: paj...@php.net
Reported By: elmue at gmx dot de
-Status: Open
+Status: Feedback
Bug Type: Program Execution
Operating System: Windows
PHP Version: 6SVN-2009-09-06 (snap)
Assigned To: pajoye
New Comment:
Try with a recent snap please
Previous Comments:
[2009-09-22 14:06:37] paj...@php.net
Windows, today snaps.
[2009-09-22 13:46:42] elmue at gmx dot de
Hello
On which PHP6 version did you test it ?
Did you test on Windows ?
I used version build Sep 3 2009 21:23:55
[2009-09-22 08:41:40] paj...@php.net
I can't reproduce it with php6 neither with 5.3 or 5.2 in CLI or FCGI.
Can you try it with CLI/CGI too please?
[2009-09-22 05:18:15] ian at iglou dot com
Also broken in PHP Version 5.2.10; safe mode off.
An earlier version (no record of which) did work when used thus to get
a Windows dvd volume label:
if (preg_match('#Volume in drive [a-zA-Z]* is (.*)\n#i',
shell_exec('dir '.$drive.':'), $m)) {
$volname = ' ('.$m[1].')';
[2009-09-06 00:49:59] elmue at gmx dot de
Description:
On PHP 6 VC 6 from 3.sept.2009 the shell_exec command is broken.
Tested on Xampp on Windows XP with Apache 2.2.9.
Whatever you put into shell_exec e.g.
shell_exec(dir C:\\)
produces a
Warning shell_exec() [function.shell-exec]: Unable to execute 'dir
c:\'
The same script works fine on PHP 5
--
Edit this bug report at http://bugs.php.net/?id=49478edit=1
#49620 [Asn]: is_writeable does not work using netshare and normal user rights
ID: 49620
Updated by: paj...@php.net
Reported By: philipp at servicemail24 dot de
Status: Assigned
Bug Type: *Directory/Filesystem functions
Operating System: win32 only - Windows XP SP2
PHP Version: 5.3.0
Assigned To: pajoye
New Comment:
Please try
http://windows.php.net/downloads/qa/test/php-5.3.2-dev-nts-Win32-VC9-x86-200909221530.zip
I have tested it successfully using various shares (and other ACL
related issues).
Previous Comments:
[2009-09-22 10:11:47] j...@php.net
Why did you add a comment? The link sent to you does not take you to
the Add comment page but to the edit your submission. Next time when
someone asks for feedback, use the proper method in replying.
[2009-09-22 08:58:03] philipp at servicemail24 dot de
php-5.3.2-dev-nts-Win32-VC9-x86 has the same problem.
I run this script using CLI (cmd.exe Terminal running php.exe)
[2009-09-22 08:43:37] paj...@php.net
Under which SAPI do you run it? CLI, FCGI or apache?
Can you try again using
http://windows.php.net/downloads/qa/test/php-5.3.2-dev-nts-Win32-VC9-x86.zip
please?
[2009-09-22 07:52:52] philipp at servicemail24 dot de
Description:
PHP 5.3.0 and 5.3.1RC1 has a bug in the is_readable and is_writeable
function if you execute a script with normal windows user rights.
The same test script works fine using PHP 5.2.x. Providing admin rights
for the user solves the problem but this is not a long term solution for
us.
All tested PHP releases are VC6 TS
PHP 5.2.10 - OK
PHP 5.2.11 - OK
PHP 5.3.0 - FAILED
PHP 5.3.1RC1 - FAILED
Reproduce code:
---
$folders = array( '10.1.1.1\\share',
'srv\\share',
'd:/temp'
);
foreach($folders as $folder) {
if(@!is_readable($folder)) {
echo('FAILED is_readable: ' . $folder . \n);
} else {
echo OK is_readable: . $folder . \n;
}
if(@!is_writeable($folder)) {
echo('FAILED is_writeable: ' . $folder . \n);
} else {
echo OK is_writeable: . $folder . \n;
}
$filename = $folder . '\\test.txt';
if(@!file_put_contents($filename, 'php test')) {
echo('FAILED file_put_contents: ' . $filename . \n);
} else {
echo OK file_put_contents: . $filename . \n;
}
}
Expected result:
OK is_readable: \\10.1.1.1\share
OK is_writeable: \\10.1.1.1\share
OK file_put_contents: \\10.1.1.1\share\test.txt
OK is_readable: \\srv\share
OK is_writeable: \\srv\share
OK file_put_contents: \\srv\share\test.txt
OK is_readable: d:/temp
OK is_writeable: d:/temp
OK file_put_contents: d:/temp\test.txt
Actual result:
--
FAILED is_readable: \\10.1.1.1\share
FAILED is_writeable: \\10.1.1.1\share
OK file_put_contents: \\10.1.1.1\share\test.txt
FAILED is_readable: \\srv\share
FAILED is_writeable: \\srv\share
OK file_put_contents: \\srv\share\test.txt
OK is_readable: d:/temp
OK is_writeable: d:/temp
OK file_put_contents: d:/temp\test.txt
--
Edit this bug report at http://bugs.php.net/?id=49620edit=1
#49620 [Asn]: is_writeable does not work using netshare and normal user rights
ID: 49620
Updated by: paj...@php.net
Reported By: philipp at servicemail24 dot de
Status: Assigned
Bug Type: *Directory/Filesystem functions
Operating System: win32 only - Windows XP SP2
PHP Version: 5.3.0
Assigned To: pajoye
New Comment:
@Jani
I don't use mails to reply but only the web frontend. This tracker is
almost useless, there is really no need to make it even worst by
polluting issues with unrelated comments :)
Previous Comments:
[2009-09-22 14:38:50] paj...@php.net
Please try
http://windows.php.net/downloads/qa/test/php-5.3.2-dev-nts-Win32-VC9-x86-200909221530.zip
I have tested it successfully using various shares (and other ACL
related issues).
[2009-09-22 10:11:47] j...@php.net
Why did you add a comment? The link sent to you does not take you to
the Add comment page but to the edit your submission. Next time when
someone asks for feedback, use the proper method in replying.
[2009-09-22 08:58:03] philipp at servicemail24 dot de
php-5.3.2-dev-nts-Win32-VC9-x86 has the same problem.
I run this script using CLI (cmd.exe Terminal running php.exe)
[2009-09-22 08:43:37] paj...@php.net
Under which SAPI do you run it? CLI, FCGI or apache?
Can you try again using
http://windows.php.net/downloads/qa/test/php-5.3.2-dev-nts-Win32-VC9-x86.zip
please?
[2009-09-22 07:52:52] philipp at servicemail24 dot de
Description:
PHP 5.3.0 and 5.3.1RC1 has a bug in the is_readable and is_writeable
function if you execute a script with normal windows user rights.
The same test script works fine using PHP 5.2.x. Providing admin rights
for the user solves the problem but this is not a long term solution for
us.
All tested PHP releases are VC6 TS
PHP 5.2.10 - OK
PHP 5.2.11 - OK
PHP 5.3.0 - FAILED
PHP 5.3.1RC1 - FAILED
Reproduce code:
---
$folders = array( '10.1.1.1\\share',
'srv\\share',
'd:/temp'
);
foreach($folders as $folder) {
if(@!is_readable($folder)) {
echo('FAILED is_readable: ' . $folder . \n);
} else {
echo OK is_readable: . $folder . \n;
}
if(@!is_writeable($folder)) {
echo('FAILED is_writeable: ' . $folder . \n);
} else {
echo OK is_writeable: . $folder . \n;
}
$filename = $folder . '\\test.txt';
if(@!file_put_contents($filename, 'php test')) {
echo('FAILED file_put_contents: ' . $filename . \n);
} else {
echo OK file_put_contents: . $filename . \n;
}
}
Expected result:
OK is_readable: \\10.1.1.1\share
OK is_writeable: \\10.1.1.1\share
OK file_put_contents: \\10.1.1.1\share\test.txt
OK is_readable: \\srv\share
OK is_writeable: \\srv\share
OK file_put_contents: \\srv\share\test.txt
OK is_readable: d:/temp
OK is_writeable: d:/temp
OK file_put_contents: d:/temp\test.txt
Actual result:
--
FAILED is_readable: \\10.1.1.1\share
FAILED is_writeable: \\10.1.1.1\share
OK file_put_contents: \\10.1.1.1\share\test.txt
FAILED is_readable: \\srv\share
FAILED is_writeable: \\srv\share
OK file_put_contents: \\srv\share\test.txt
OK is_readable: d:/temp
OK is_writeable: d:/temp
OK file_put_contents: d:/temp\test.txt
--
Edit this bug report at http://bugs.php.net/?id=49620edit=1
#48507 [Com]: fgetcsv() ignoring special characters
ID: 48507 Comment by: phofstetter at sensational dot ch Reported By: krynble at yahoo dot com dot br Status: Verified Bug Type: Filesystem function related Operating System: Unix PHP Version: 5.2.9 New Comment: I was looking into this (after having been bitten by it) and I can add another tidbit that might help tracking this down: The bug doesn't happen if the file fgetcsv() is reading is in UTF-8-format. I have created a test-file in ISO-8859-1 and then used file_put_contents(utf8encode(file_get_contents())) to create the UTF8-version of it (explaining this here because I'm not sure whether this would write a BOM or not - probably not though). That version could be read correctly. I'm now writing a stream filter that does the UTF-8 conversion on the fly to hook that in between the file and fgetcsv() - while I would lose a bit of performance, in my case, this is the cleanest workaround. Previous Comments: [2009-09-21 18:11:47] dmulryan at calendarwiz dot com Note: Previous comment has error where URL is shown in array element. This is not a bug but my error in the example. Bug is in special characters. [2009-09-21 18:07:42] dmulryan at calendarwiz dot com Similar problem when parsing the following line: 0909211132,1,ØÊááàÑ,äÆæç,CForm,Y,1,1,1,97.95.176.240,2530 which produces empty array elements for fields with special characters: Array ( [0] = 0909211132 [1] = 1 [2] = [3] = [4] = URL [5] = Y [6] = 1 [7] = 1 [8] = 1 [9] = 97.95.176.240 [10] = 2530 ) [2009-06-26 19:35:22] sjoerd-php at linuxonly dot nl Could reproduce with php 5.2.10, php 5.2.11-dev (200906261830) and php 5.3rc4. Example code: ?php $fp = tmpfile(); $str = WEIRD#\xD3TICA#BEHAVIOR; fwrite($fp, $str); fseek($fp, 0); $arr = fgetcsv($fp, 100, '#'); var_dump($arr[1]); fclose($fp); ? Expected: string(5) ?TICA Actual: string(4) TICA [2009-06-13 18:10:03] krynble at yahoo dot com dot br Unfortunately I'm unable to test it because the server is running in a Datacenter. If someone can give a feedback about it, I would apreciate. Still, thanks for the help! [2009-06-10 12:47:52] j...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ 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/48507 -- Edit this bug report at http://bugs.php.net/?id=48507edit=1
#48507 [Com]: fgetcsv() ignoring special characters
ID: 48507
Comment by: phofstetter at sensational dot ch
Reported By: krynble at yahoo dot com dot br
Status: Verified
Bug Type: Filesystem function related
Operating System: Unix
PHP Version: 5.2.9
New Comment:
below you'll find a small script which shows how to implement a user
filter that can be used to on-the-fly utf8-encode the data so that
fgetcsv is happy and returns correct output even if the first character
in a field has its high-bit set and is not valid utf-8:
Remember: This is a workaround and impacts performance. This is not a
valid fix for the bug.
I didn't yet have time to deeply look into the C implementation for
fgetcsv, but all these calls to php_mblen() feel suspicious to me.
I'll try and have a look into this later today, but for now, I'm just
glad I have this workaround (quickly hacked together - keep that in
mind):
?php
class utf8encode_filter extends php_user_filter {
function is_utf8($string){
return preg_match('%(?:
[\xC2-\xDF][\x80-\xBF]# non-overlong 2-byte
|\xE0[\xA0-\xBF][\x80-\xBF] # excluding
overlongs
|[\xE1-\xEC\xEE\xEF][\x80-\xBF]{2} # straight 3-byte
|\xED[\x80-\x9F][\x80-\xBF] # excluding
surrogates
|\xF0[\x90-\xBF][\x80-\xBF]{2}# planes 1-3
|[\xF1-\xF3][\x80-\xBF]{3} # planes 4-15
|\xF4[\x80-\x8F][\x80-\xBF]{2}# plane 16
)+%xs', $string);
}
function filter($in, $out, $consumed, $closing)
{
while ($bucket = stream_bucket_make_writeable($in)) {
if (!$this-is_utf8($bucket-data))
$bucket-data = utf8_encode($bucket-data);
$consumed += $bucket-datalen;
stream_bucket_append($out, $bucket);
}
return PSFS_PASS_ON;
}
}
/* Register our filter with PHP */
stream_filter_register(utf8encode, utf8encode_filter)
or die(Failed to register filter);
$fp = fopen($_SERVER['argv'][1], r);
/* Attach the registered filter to the stream just opened */
stream_filter_prepend($fp, utf8encode);
while($data = fgetcsv($fp, 0, ';', ''))
print_r($data);
fclose($fp);
Previous Comments:
[2009-09-22 14:45:22] phofstetter at sensational dot ch
I was looking into this (after having been bitten by it) and I can add
another tidbit that might help tracking this down:
The bug doesn't happen if the file fgetcsv() is reading is in
UTF-8-format.
I have created a test-file in ISO-8859-1 and then used
file_put_contents(utf8encode(file_get_contents())) to create the
UTF8-version of it (explaining this here because I'm not sure whether
this would write a BOM or not - probably not though).
That version could be read correctly.
I'm now writing a stream filter that does the UTF-8 conversion on the
fly to hook that in between the file and fgetcsv() - while I would lose
a bit of performance, in my case, this is the cleanest workaround.
[2009-09-21 18:11:47] dmulryan at calendarwiz dot com
Note: Previous comment has error where URL is shown in array element.
This is not a bug but my error in the example. Bug is in special
characters.
[2009-09-21 18:07:42] dmulryan at calendarwiz dot com
Similar problem when parsing the following line:
0909211132,1,ØÊááàÑ,äÆæç,CForm,Y,1,1,1,97.95.176.240,2530
which produces empty array elements for fields with special
characters:
Array ( [0] = 0909211132 [1] = 1 [2] = [3] = [4] = URL [5] = Y
[6] = 1 [7] = 1 [8] = 1 [9] = 97.95.176.240 [10] = 2530 )
[2009-06-26 19:35:22] sjoerd-php at linuxonly dot nl
Could reproduce with php 5.2.10, php 5.2.11-dev (200906261830) and php
5.3rc4. Example code:
?php
$fp = tmpfile();
$str = WEIRD#\xD3TICA#BEHAVIOR;
fwrite($fp, $str);
fseek($fp, 0);
$arr = fgetcsv($fp, 100, '#');
var_dump($arr[1]);
fclose($fp);
?
Expected: string(5) ?TICA
Actual: string(4) TICA
[2009-06-13 18:10:03] krynble at yahoo dot com dot br
Unfortunately I'm unable to test it because the server is running in a
Datacenter.
If someone can give a feedback about it, I would apreciate.
Still, thanks for the help!
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/48507
--
Edit this bug report at http://bugs.php.net/?id=48507edit=1
#49620 [Asn-Fbk]: is_writeable does not work using netshare and normal user rights
ID: 49620 Updated by: paj...@php.net Reported By: philipp at servicemail24 dot de -Status: Assigned +Status: Feedback Bug Type: *Directory/Filesystem functions Operating System: win32 only - Windows XP SP2 PHP Version: 5.3.0 Assigned To: pajoye Previous Comments: [2009-09-22 14:39:49] paj...@php.net @Jani I don't use mails to reply but only the web frontend. This tracker is almost useless, there is really no need to make it even worst by polluting issues with unrelated comments :) [2009-09-22 14:38:50] paj...@php.net Please try http://windows.php.net/downloads/qa/test/php-5.3.2-dev-nts-Win32-VC9-x86-200909221530.zip I have tested it successfully using various shares (and other ACL related issues). [2009-09-22 10:11:47] j...@php.net Why did you add a comment? The link sent to you does not take you to the Add comment page but to the edit your submission. Next time when someone asks for feedback, use the proper method in replying. [2009-09-22 08:58:03] philipp at servicemail24 dot de php-5.3.2-dev-nts-Win32-VC9-x86 has the same problem. I run this script using CLI (cmd.exe Terminal running php.exe) [2009-09-22 08:43:37] paj...@php.net Under which SAPI do you run it? CLI, FCGI or apache? Can you try again using http://windows.php.net/downloads/qa/test/php-5.3.2-dev-nts-Win32-VC9-x86.zip please? 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/49620 -- Edit this bug report at http://bugs.php.net/?id=49620edit=1
#49625 [NEW]: spl_autoload and case sensitivity
From: jo at feuersee dot de
Operating system: Linux
PHP version: 5.3.0
PHP Bug Type: SPL related
Bug description: spl_autoload and case sensitivity
Description:
This is basically the same as PHP bug #48129.
Yes, I have read it won't fix
My opinion on this is won't fix is not an option because it _is_ a bug
and not fixing bugs does not work:
1) It is common practice in OO languages (including PHP) to give classes
case sensitive names. Even the classes of PHP itself are case sensitive and
usually start with capital letters (eg. DateTime, Exception, ...). PHP
related projects like PEAR, Zend Framework etc. do the same.
2) In order to get a proper 1:1 mapping from class name to the file
containing the PHP class definition, projects like PEAR or Zend Framework
use the case sensitive class name, eg. System.php contains the class
System. Again, this is common practice in other OO languages like C++.
3) What happens when the file system is case sensitive?
See example: the script fails because the PEAR class System will be looked
for in a file named system.php which does not exist because it is called
System.php
The workaround is using SPL_autoload_suxx instead. But look at the code:
there are several compatibility issues (include_path separator : vs. ;), it
does work but is not at all convenient.
4) What would happen if spl_autoload() wouldn't lowercase the class name
when looking for a class definition?
a) Filesystem is case sensitive
It would work!
The spl_autoload() would look for a file called System.php which exists,
thus will be require'd
b) Filesystem is not case sensitive
It would still work!
The spl_autoload() would look for a file called System.php
Because the file system is case insensitive, it would use either
System.php or system.php (or sYSTEM.PHP - you got the point?).
Because on case insentive filesystems both files System.php and
system.php are not allowed in the same directory, there is _no_ issue
with backward compatibility.
The only circumstances where it would break backwards compatibility would
be on filesystem which is case insensitive but does not allow capital
letters. Any real live examples of such a file system?
Conclusion:
The current specification of spl_autoload() with implicit lowercasing is
excactly wrong. There has been, is and never will be any gain in this
'feature' since the class name itself inside PHP is case sensitive.
Reproduce code:
---
?php
/**
* Demonstration of the current incompatibility
* Make sure you have PEAR inside your PHP include_path
*/
// this should work but doesn't
spl_autoload_register('spl_autoload');
// this does work
//spl_autoload_register('SPL_autoload_suxx');
/**
* Does the same as spl_autoload, but without lowercasing
*/
function SPL_autoload_suxx($name)
{
$rc = FALSE;
$exts = explode(',', spl_autoload_extensions());
$sep = (substr(PHP_OS, 0, 3) == 'Win') ? ';' : ':';
$paths = explode($sep, ini_get('include_path'));
foreach($paths as $path) {
foreach($exts as $ext) {
$file = $path . DIRECTORY_SEPARATOR . $name . $ext;
if(is_readable($file)) {
require_once $file;
$rc = $file;
break;
}
}
}
return $rc;
}
$binaries = array(
'mysql' = System::which('mysql'),
'mysqlbinlog' = System::which('mysqlbinlog'),
'php' = System::which('php')
);
print_r($binaries);
?
Expected result:
Array
(
[mysql] = /usr/bin/mysql
[mysqlbinlog] = /usr/bin/mysqlbinlog
[php] = /usr/local/bin/php
)
Actual result:
--
PHP Fatal error: Class 'System' not found in
/srv/www/vhosts/www.easy-sew.de/ftpjung/bin/autoload.php on line 38
--
Edit bug report at http://bugs.php.net/?id=49625edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49625r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49625r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49625r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49625r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49625r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49625r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49625r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49625r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49625r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49625r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49625r=notwrong
Not enough info:
#49624 [Opn-Bgs]: xxxxxxxxxxxxxxxxxxxxx
ID: 49624 Updated by: sjo...@php.net Reported By: js8jim at msn dot com -Status: Open +Status: Bogus Bug Type: Unknown/Other Function Operating System: windows xpsp3 PHP Version: 5.3.0 New Comment: x Previous Comments: [2009-09-22 13:40:26] js8jim at msn dot com Description: i have screenshot to send. please reply. thank you. -jim Reproduce code: --- x Expected result: Actual result: -- xx -- Edit this bug report at http://bugs.php.net/?id=49624edit=1
#49623 [Opn]: PHP shows deprication warning BEFORE compressed body
ID: 49623
User updated by: 3 at 14 dot by
-Summary: PHP shows deprecation warning BEFORE compressed body
Reported By: 3 at 14 dot by
Status: Open
Bug Type: Output Control
Operating System: 2.6.28-15-generic #49-Ubuntu SMP
PHP Version: 5.3.0
New Comment:
typo
Previous Comments:
[2009-09-22 13:32:23] 3 at 14 dot by
Description:
I have set Error_Reporting(0) both in the script in the php.ini.
I have an PHPBB forum (3.0.6) with zlib compression turned on.
Most of the warnings are gone, but in some cases (when some data is
sent via POST), I am still getting a Notice bdate(): It is not safe
to rely on the system's timezone settings., and it is printed BEFORE
compressed page body, so that browser reports broken encoding.
After disabling zlib compression browser started to show notice and
page content. After setting date.timezone in php.ini Notice is gone.
Reproduce code:
---
Install PHPBB 3.0.6: turn zlib compression = on, make sure to unset
date.timezone in php.ini. Then try to reply to a private message.
Expected result:
No notices on the screen, no broken encoding
Actual result:
--
HTTP/1.1 200 OK
Server: nginx
Date: Tue, 22 Sep 2009 13:09:15 GMT
Content-Type: text/html; charset=UTF-8
Connection: close
Expires: 0
Last-Modified: Tue, 22 Sep 2009 13:09:15 GMT
Cache-Control: private, no-cache=set-cookie
Pragma: no-cache
Content-Encoding: gzip
Vary: Accept-Encoding
Content-Length: 3181
b[phpBB Debug] PHP Notice/b: in file
b/includes/functions_messenger.php/b on line b390/b: bdate():
It is not safe to rely on the system's timezone settings. You are
*required* to use the date.timezone setting or the
date_default_timezone_set() function. In case you used any of those
methods and you are still getting this warning, you most likely
misspelled the timezone identifier. We selected 'Europe/Moscow' for
'MSD/4.0/DST' instead/bbr /
.n.8...
V.I[[..\j[..4.)..l.@iu
.Cv_...%{.)..%i.S#.E...d9.t,..w./.3..o../H..O.u._9...N..;^[fSw..{.T:.V...i.:tF..ar..Dy[.t.yb.s...h2.h8j6.1..
2.,.-.H.C...hv.]d2 AD3...n|.:v.;[here goes the rest of
the compressed page]
--
Edit this bug report at http://bugs.php.net/?id=49623edit=1
#49623 [Opn]: PHP shows deprication warning BEFORE compressed body
ID: 49623
Updated by: sjo...@php.net
Reported By: 3 at 14 dot by
Status: Open
Bug Type: Output Control
Operating System: 2.6.28-15-generic #49-Ubuntu SMP
PHP Version: 5.3.0
New Comment:
Thank you for your bug report.
That PHP shows a warning even though error reporting is disabled sounds
like bug #49362, Deprecated php.ini options warnings output even with
display_errors=off.
Previous Comments:
[2009-09-22 16:11:25] 3 at 14 dot by
typo
[2009-09-22 13:32:23] 3 at 14 dot by
Description:
I have set Error_Reporting(0) both in the script in the php.ini.
I have an PHPBB forum (3.0.6) with zlib compression turned on.
Most of the warnings are gone, but in some cases (when some data is
sent via POST), I am still getting a Notice bdate(): It is not safe
to rely on the system's timezone settings., and it is printed BEFORE
compressed page body, so that browser reports broken encoding.
After disabling zlib compression browser started to show notice and
page content. After setting date.timezone in php.ini Notice is gone.
Reproduce code:
---
Install PHPBB 3.0.6: turn zlib compression = on, make sure to unset
date.timezone in php.ini. Then try to reply to a private message.
Expected result:
No notices on the screen, no broken encoding
Actual result:
--
HTTP/1.1 200 OK
Server: nginx
Date: Tue, 22 Sep 2009 13:09:15 GMT
Content-Type: text/html; charset=UTF-8
Connection: close
Expires: 0
Last-Modified: Tue, 22 Sep 2009 13:09:15 GMT
Cache-Control: private, no-cache=set-cookie
Pragma: no-cache
Content-Encoding: gzip
Vary: Accept-Encoding
Content-Length: 3181
b[phpBB Debug] PHP Notice/b: in file
b/includes/functions_messenger.php/b on line b390/b: bdate():
It is not safe to rely on the system's timezone settings. You are
*required* to use the date.timezone setting or the
date_default_timezone_set() function. In case you used any of those
methods and you are still getting this warning, you most likely
misspelled the timezone identifier. We selected 'Europe/Moscow' for
'MSD/4.0/DST' instead/bbr /
.n.8...
V.I[[..\j[..4.)..l.@iu
.Cv_...%{.)..%i.S#.E...d9.t,..w./.3..o../H..O.u._9...N..;^[fSw..{.T:.V...i.:tF..ar..Dy[.t.yb.s...h2.h8j6.1..
2.,.-.H.C...hv.]d2 AD3...n|.:v.;[here goes the rest of
the compressed page]
--
Edit this bug report at http://bugs.php.net/?id=49623edit=1
#49625 [Opn-Bgs]: spl_autoload and case sensitivity
ID: 49625
Updated by: sjo...@php.net
Reported By: jo at feuersee dot de
-Status: Open
+Status: Bogus
Bug Type: SPL related
Operating System: Linux
PHP Version: 5.3.0
New Comment:
Thank you for your bug report.
Wontfix means: we agree that there is a bug, but there are reasons not
to fix it. The reason here is that is spl_autoload becomes case
sensitive, it will break scripts which depend on spl_autoload being case
insensitive.
Previous Comments:
[2009-09-22 16:01:15] jo at feuersee dot de
Description:
This is basically the same as PHP bug #48129.
Yes, I have read it won't fix
My opinion on this is won't fix is not an option because it _is_ a
bug and not fixing bugs does not work:
1) It is common practice in OO languages (including PHP) to give
classes case sensitive names. Even the classes of PHP itself are case
sensitive and usually start with capital letters (eg. DateTime,
Exception, ...). PHP related projects like PEAR, Zend Framework etc. do
the same.
2) In order to get a proper 1:1 mapping from class name to the file
containing the PHP class definition, projects like PEAR or Zend
Framework use the case sensitive class name, eg. System.php contains the
class System. Again, this is common practice in other OO languages like
C++.
3) What happens when the file system is case sensitive?
See example: the script fails because the PEAR class System will be
looked for in a file named system.php which does not exist because it is
called System.php
The workaround is using SPL_autoload_suxx instead. But look at the
code: there are several compatibility issues (include_path separator :
vs. ;), it does work but is not at all convenient.
4) What would happen if spl_autoload() wouldn't lowercase the class
name when looking for a class definition?
a) Filesystem is case sensitive
It would work!
The spl_autoload() would look for a file called System.php which
exists, thus will be require'd
b) Filesystem is not case sensitive
It would still work!
The spl_autoload() would look for a file called System.php
Because the file system is case insensitive, it would use either
System.php or system.php (or sYSTEM.PHP - you got the point?).
Because on case insentive filesystems both files System.php and
system.php are not allowed in the same directory, there is _no_ issue
with backward compatibility.
The only circumstances where it would break backwards compatibility
would be on filesystem which is case insensitive but does not allow
capital letters. Any real live examples of such a file system?
Conclusion:
The current specification of spl_autoload() with implicit lowercasing
is excactly wrong. There has been, is and never will be any gain in this
'feature' since the class name itself inside PHP is case sensitive.
Reproduce code:
---
?php
/**
* Demonstration of the current incompatibility
* Make sure you have PEAR inside your PHP include_path
*/
// this should work but doesn't
spl_autoload_register('spl_autoload');
// this does work
//spl_autoload_register('SPL_autoload_suxx');
/**
* Does the same as spl_autoload, but without lowercasing
*/
function SPL_autoload_suxx($name)
{
$rc = FALSE;
$exts = explode(',', spl_autoload_extensions());
$sep = (substr(PHP_OS, 0, 3) == 'Win') ? ';' : ':';
$paths = explode($sep, ini_get('include_path'));
foreach($paths as $path) {
foreach($exts as $ext) {
$file = $path . DIRECTORY_SEPARATOR . $name . $ext;
if(is_readable($file)) {
require_once $file;
$rc = $file;
break;
}
}
}
return $rc;
}
$binaries = array(
'mysql' = System::which('mysql'),
'mysqlbinlog' = System::which('mysqlbinlog'),
'php' = System::which('php')
);
print_r($binaries);
?
Expected result:
Array
(
[mysql] = /usr/bin/mysql
[mysqlbinlog] = /usr/bin/mysqlbinlog
[php] = /usr/local/bin/php
)
Actual result:
--
PHP Fatal error: Class 'System' not found in
/srv/www/vhosts/www.easy-sew.de/ftpjung/bin/autoload.php on line 38
--
Edit this bug report at http://bugs.php.net/?id=49625edit=1
#49262 [Opn]: PDO MySQL doesn't take STRING params
ID: 49262 User updated by: grzegorz at heex dot pl Reported By: grzegorz at heex dot pl Status: Open Bug Type: PDO related Operating System: Win XP Sp3 PHP Version: 5.3.0 New Comment: Variable_name Value character_set_clientutf8 character_set_connectionutf8 character_set_database utf8 character_set_filesystembinary character_set_results utf8 character_set_serverutf8 character_set_systemutf8 character_sets_dir C:\Program Files\MySQL\MySQL Server 6.0\share\char.. Previous Comments: [2009-09-22 13:53:00] u...@php.net Ok, great. Your character set is uft8 (uft8_general_ci is the collation). Can you paste SHOW VARIABLES LIKE '%character%' to give details about your MySQL settings? Thanks! [2009-09-20 22:44:06] grzegorz at heex dot pl Column lng_name and a whole table they have utf8_general_ci charset. [2009-09-18 08:39:34] u...@php.net Can you say anything about the character sets you are using? [2009-08-25 07:57:54] grzegorz at heex dot pl FunctionArg 1 Arg 2 Arg 3 Source php5ts!mysqlnd_cset_escape_slashes+30 05652000 0565fb58 php_pdo_mysql!_pdo_mysql_error+6f7 0565f5880565fb58 0006 php5ts!pdo_parse_params+394 05662d5005662e780026 php5ts!pdo_stmt_describe_columns+7720565f638 php5ts!execute+10b9 05690070015e5801007f66b8 php5ts!execute+156d 015e585803e8fbe0 php5ts!execute+298 0565dbf0015e5800015e5858 php5ts!zend_execute_scripts+fe 0008015e5858 php5ts!php_execute_script+231 03e8fe6c015e58580005 php5apache2_2!zm_info_apache+1744 007aa7600073a400 007aa760 libhttpd!ap_run_handler+21 007aa760007aa760007aa760 libhttpd!ap_invoke_handler+ae 007a771803e8ff38 libhttpd!ap_die+24e 007aa7600073aac8 libhttpd!ap_get_request_note+1c6c 007a7718007a7718 007a7718 libhttpd!ap_run_process_connection+21 007a77180074a198 03e8ff80 libhttpd!ap_process_connection+33 007a7718007a26d8 0006fb80 libhttpd!ap_regkey_value_remove+c0c 007a77100006fb80 00eb0650 msvcrt!_endthreadex+a9 0079ef880006fb8000eb0650 kernel32!BaseThreadStart+37 77c2a3410079ef88 PHP5TS!MYSQLND_CSET_ESCAPE_SLASHES+30In httpd__PID__4604__Date__08_25_2009__Time_09_37_39AM__46__Second_Chance_Exception_C005.dmp the assembly instruction at php5ts!mysqlnd_cset_escape_slashes+30 in C:\php5\php5ts.dll from The PHP Group has caused an access violation exception (0xC005) when trying to read from memory location 0x0010 on thread 157 [2009-08-24 19:55:42] sjo...@php.net Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to Open. Thank you for helping us make PHP better. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/49262 -- Edit this bug report at http://bugs.php.net/?id=49262edit=1
#49626 [NEW]: Access violation in php.exe
From: jbreiding at hotmail dot com Operating system: windows server 2008 x64 PHP version: 5.3.0 PHP Bug Type: Reproducible crash Bug description: Access violation in php.exe Description: (b64.11a8): Access violation - code c005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. php5ts!guess_timezone+0x20: 100f3d20 8b4204 mov eax,dword ptr [edx+4] ds:002b:180050ac= Reproduce code: --- ?php phpinfo(); ? Expected result: phpinfo output Actual result: -- call stack: 00c0f9e0 100f3f1e 0001 02ebfe68 0020 php5ts!guess_timezone+0x20 [d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\ext\date\php_date.c @ 843] 00c0f9f0 100f4c1b 02ab1250 02ab1250 0003 php5ts!get_timezone_info+0x1e [d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\ext\date\php_date.c @ 928] 00c0fa00 100bda11 1036a294 000b 4ab8fb18 php5ts!php_format_date+0x1b [d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\ext\date\php_date.c @ 1179] 00c0fa2c 100be4e4 02c42850 02ab1250 00c0fa74 php5ts!php_log_err+0xa1 [d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\main\main.c @ 542] 00c0fa88 10002909 0020 1035b924 php5ts!php_error_cb+0x354 [d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\main\main.c @ 952] 00c0fad4 100be066 0020 1035b99c 02c42600 php5ts!zend_error+0x4d9 [d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\zend\zend.c @ 1020] 00c0fb20 100be0d3 10520bcf 0020 php5ts!php_verror+0x566 [d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\main\main.c @ 780] 00c0fb3c 101cd357 02ab1250 0020 php5ts!php_error_docref0+0x23 [d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\main\main.c @ 791] 00c0fb74 100c5825 02c4f398 0001 php5ts!php_load_extension+0x1e7 [d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\ext\standard\dl.c @ 212] 00c0fb88 100a950c 02e536c0 02ab1250 000a php5ts!php_load_php_extension_cb+0x15 [d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\main\php_ini.c @ 330] 00c0fba0 100c6115 1054c7e8 100c5810 02ab1250 php5ts!zend_llist_apply+0x1c [d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\zend\zend_llist.c @ 193] 00c0fbc0 100c0d61 02ab1250 00c0fbf0 php5ts!php_ini_register_extensions+0x25 [d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\main\php_ini.c @ 720] 00c0fdc8 004014bf 00407010 php5ts!php_module_startup+0x8e1 [d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\main\main.c @ 1992] 00c0fdd8 00401cb3 00407010 0040742c 0001 php!php_cli_startup+0xf [d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\sapi\cli\php_cli.c @ 399] 00c0ff44 00402e5a 0002 02ab2f38 02ab1ac0 php!main+0x363 [d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\sapi\cli\php_cli.c @ 771] 00c0ff88 75f0eccb 7efde000 00c0ffd4 77c7d24d php!__tmainCRTStartup+0x10f [f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 586] 00c0ff94 77c7d24d 7efde000 684dc29c kernel32!BaseThreadInitThunk+0xe 00c0ffd4 77c7d45f 00402fa2 7efde000 ntdll32!__RtlUserThreadStart+0x23 00c0ffec 00402fa2 7efde000 ntdll32!_RtlUserThreadStart+0x1b -- Edit bug report at http://bugs.php.net/?id=49626edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49626r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49626r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49626r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49626r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49626r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49626r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49626r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49626r=needscript Try newer version: http://bugs.php.net/fix.php?id=49626r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49626r=support Expected behavior: http://bugs.php.net/fix.php?id=49626r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49626r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49626r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49626r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49626r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49626r=dst IIS Stability: http://bugs.php.net/fix.php?id=49626r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49626r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49626r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49626r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49626r=mysqlcfg
#49626 [Com]: Access violation in php.exe
ID: 49626
Comment by: jbreiding at hotmail dot com
Reported By: jbreiding at hotmail dot com
Status: Open
Bug Type: Reproducible crash
Operating System: windows server 2008 x64
PHP Version: 5.3.0
New Comment:
adding exception analysis from windbg:
FAULTING_IP:
php5ts!guess_timezone+20
[d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\ext\date\php_date.c @ 843]
100f3d20 8b4204 mov eax,dword ptr [edx+4]
EXCEPTION_RECORD: -- (.exr 0x)
ExceptionAddress: 100f3d20
(php5ts!guess_timezone+0x0020)
ExceptionCode: c005 (Access violation)
ExceptionFlags:
NumberParameters: 2
Parameter[0]:
Parameter[1]: 180050ac
Attempt to read from address 180050ac
FAULTING_THREAD: 11a8
DEFAULT_BUCKET_ID: INVALID_POINTER_READ
PROCESS_NAME: php.exe
ERROR_CODE: (NTSTATUS) 0xc005 - The instruction at 0x%08lx
referenced memory at 0x%08lx. The memory could not be %s.
EXCEPTION_CODE: (NTSTATUS) 0xc005 - The instruction at 0x%08lx
referenced memory at 0x%08lx. The memory could not be %s.
EXCEPTION_PARAMETER1:
EXCEPTION_PARAMETER2: 180050ac
READ_ADDRESS: 180050ac
FOLLOWUP_IP:
php5ts!guess_timezone+20
[d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\ext\date\php_date.c @ 843]
100f3d20 8b4204 mov eax,dword ptr [edx+4]
NTGLOBALFLAG: 70
APPLICATION_VERIFIER_FLAGS: 0
PRIMARY_PROBLEM_CLASS: INVALID_POINTER_READ
BUGCHECK_STR: APPLICATION_FAULT_INVALID_POINTER_READ
LAST_CONTROL_TRANSFER: from 100f3f1e to 100f3d20
STACK_TEXT:
00c0f9e0 100f3f1e 0001 02ebfe68 0020 php5ts!guess_timezone+0x20
[d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\ext\date\php_date.c @ 843]
00c0f9f0 100f4c1b 02ab1250 02ab1250 0003
php5ts!get_timezone_info+0x1e
[d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\ext\date\php_date.c @ 928]
00c0fa00 100bda11 1036a294 000b 4ab8fb18
php5ts!php_format_date+0x1b
[d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\ext\date\php_date.c @ 1179]
00c0fa2c 100be4e4 02c42850 02ab1250 00c0fa74 php5ts!php_log_err+0xa1
[d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\main\main.c @ 542]
00c0fa88 10002909 0020 1035b924 php5ts!php_error_cb+0x354
[d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\main\main.c @ 952]
00c0fad4 100be066 0020 1035b99c 02c42600 php5ts!zend_error+0x4d9
[d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\zend\zend.c @ 1020]
00c0fb20 100be0d3 10520bcf 0020 php5ts!php_verror+0x566
[d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\main\main.c @ 780]
00c0fb3c 101cd357 02ab1250 0020
php5ts!php_error_docref0+0x23
[d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\main\main.c @ 791]
00c0fb74 100c5825 02c4f398 0001
php5ts!php_load_extension+0x1e7
[d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\ext\standard\dl.c @ 212]
00c0fb88 100a950c 02e536c0 02ab1250 000a
php5ts!php_load_php_extension_cb+0x15
[d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\main\php_ini.c @ 330]
00c0fba0 100c6115 1054c7e8 100c5810 02ab1250
php5ts!zend_llist_apply+0x1c
[d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\zend\zend_llist.c @ 193]
00c0fbc0 100c0d61 02ab1250 00c0fbf0
php5ts!php_ini_register_extensions+0x25
[d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\main\php_ini.c @ 720]
00c0fdc8 004014bf 00407010
php5ts!php_module_startup+0x8e1
[d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\main\main.c @ 1992]
00c0fdd8 00401cb3 00407010 0040742c 0001 php!php_cli_startup+0xf
[d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\sapi\cli\php_cli.c @ 399]
00c0ff44 00402e5a 0002 02ab2f38 02ab1ac0 php!main+0x363
[d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\sapi\cli\php_cli.c @ 771]
00c0ff88 75f0eccb 7efde000 00c0ffd4 77c7d24d
php!__tmainCRTStartup+0x10f
[f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 586]
00c0ff94 77c7d24d 7efde000 684dc29c
kernel32!BaseThreadInitThunk+0xe
00c0ffd4 77c7d45f 00402fa2 7efde000
ntdll32!__RtlUserThreadStart+0x23
00c0ffec 00402fa2 7efde000
ntdll32!_RtlUserThreadStart+0x1b
FAULTING_SOURCE_CODE:
839: {
840: char *env;
841:
842: /* Checking configure timezone */
843: if (DATEG(timezone) (strlen(DATEG(timezone)) 0)) {
844: return DATEG(timezone);
845: }
846: /* Check environment variable */
847: env = getenv(TZ);
848: if (env *env timelib_timezone_id_is_valid(env, tzdb)) {
SYMBOL_STACK_INDEX: 0
SYMBOL_NAME: php5ts!guess_timezone+20
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: php5ts
IMAGE_NAME: php5ts.dll
DEBUG_FLR_IMAGE_TIMESTAMP: 4a4929bb
STACK_COMMAND: ~0s ; kb
FAILURE_BUCKET_ID:
INVALID_POINTER_READ_c005_php5ts.dll!guess_timezone
BUCKET_ID:
X64_APPLICATION_FAULT_INVALID_POINTER_READ_php5ts!guess_timezone+20
WATSON_IBUCKET: 1347127945
WATSON_IBUCKETTABLE: 1
WATSON_STAGEONE_URL:
#48855 [Opn-Ver]: Decimals are rounded with PDO bindValue in mysql double/float fields
ID: 48855
Updated by: u...@php.net
Reported By: lorenzo-99 at libero dot it
-Status: Open
+Status: Verified
Bug Type: PDO related
Operating System: Windows XP
PHP Version: 5.2.10
New Comment:
That is a PDO bug not a PDO_MYSQL bug. It has been fixed in PHP 5.3+.
ext/pdo/pdo_stmt.c:330 needs something like this:
int len = spprintf(p, 0, %.*H, (int) EG(precision),
Z_DVAL_P(param-parameter));
I don't know what the policy is with PHP 5.2. Would be nice if someone
else could apply the patch. I am quite sure to have seen this bug before
and I am also sure the 5.3 tests cover it. Though, I can't say which
test from top of my head.
Previous Comments:
[2009-07-08 16:48:03] lorenzo-99 at libero dot it
Description:
I'm inserting a new record in a Mysql table with a PDO routine, the
table have a double field (not specified the scale and size for the
field), I'm using the bindValue function, I try to save the value
9.1234567 in the field, after the insert I found it saves 9.123457, so
maximum 6 decimals (with rounding).
The same problem happens with a float field, in this case it saves
maximum 5 decimals
I didn't try with other dbms, my Mysql version is 5.1.36 (i verified
that the problem happens also with older versions)
Reproduce code:
---
This saves only 6 decimal (using bindValue):
$sth = $dbh-prepare(INSERT INTO `intrapportal`.`regioni` (
`idRegione` ,`descrRegione` , `provadouble` )
VALUES ('', 'y', :value));
/*** bind values ***/
$sth-bindValue(':value', 9.1234567, PDO::PARAM_STR);
/*** execute the prepared statement ***/
$sth-execute();
This saves all decimals (without bindValue)
$sth = $dbh-prepare(INSERT INTO `intrapportal`.`regioni` (
`idRegione` ,`descrRegione` , `provadouble` )
VALUES ('', 'y', 9.1234567));
/*** execute the prepared statement ***/
$sth-execute();
--
Edit this bug report at http://bugs.php.net/?id=48855edit=1
#49626 [Opn-Fbk]: Access violation in php.exe
ID: 49626
Updated by: paj...@php.net
Reported By: jbreiding at hotmail dot com
-Status: Open
+Status: Feedback
Bug Type: Reproducible crash
Operating System: windows server 2008 x64
PHP Version: 5.3.0
New Comment:
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Previous Comments:
[2009-09-22 16:41:25] jbreiding at hotmail dot com
adding exception analysis from windbg:
FAULTING_IP:
php5ts!guess_timezone+20
[d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\ext\date\php_date.c @ 843]
100f3d20 8b4204 mov eax,dword ptr [edx+4]
EXCEPTION_RECORD: -- (.exr 0x)
ExceptionAddress: 100f3d20
(php5ts!guess_timezone+0x0020)
ExceptionCode: c005 (Access violation)
ExceptionFlags:
NumberParameters: 2
Parameter[0]:
Parameter[1]: 180050ac
Attempt to read from address 180050ac
FAULTING_THREAD: 11a8
DEFAULT_BUCKET_ID: INVALID_POINTER_READ
PROCESS_NAME: php.exe
ERROR_CODE: (NTSTATUS) 0xc005 - The instruction at 0x%08lx
referenced memory at 0x%08lx. The memory could not be %s.
EXCEPTION_CODE: (NTSTATUS) 0xc005 - The instruction at 0x%08lx
referenced memory at 0x%08lx. The memory could not be %s.
EXCEPTION_PARAMETER1:
EXCEPTION_PARAMETER2: 180050ac
READ_ADDRESS: 180050ac
FOLLOWUP_IP:
php5ts!guess_timezone+20
[d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\ext\date\php_date.c @ 843]
100f3d20 8b4204 mov eax,dword ptr [edx+4]
NTGLOBALFLAG: 70
APPLICATION_VERIFIER_FLAGS: 0
PRIMARY_PROBLEM_CLASS: INVALID_POINTER_READ
BUGCHECK_STR: APPLICATION_FAULT_INVALID_POINTER_READ
LAST_CONTROL_TRANSFER: from 100f3f1e to 100f3d20
STACK_TEXT:
00c0f9e0 100f3f1e 0001 02ebfe68 0020 php5ts!guess_timezone+0x20
[d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\ext\date\php_date.c @ 843]
00c0f9f0 100f4c1b 02ab1250 02ab1250 0003
php5ts!get_timezone_info+0x1e
[d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\ext\date\php_date.c @ 928]
00c0fa00 100bda11 1036a294 000b 4ab8fb18
php5ts!php_format_date+0x1b
[d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\ext\date\php_date.c @ 1179]
00c0fa2c 100be4e4 02c42850 02ab1250 00c0fa74 php5ts!php_log_err+0xa1
[d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\main\main.c @ 542]
00c0fa88 10002909 0020 1035b924 php5ts!php_error_cb+0x354
[d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\main\main.c @ 952]
00c0fad4 100be066 0020 1035b99c 02c42600 php5ts!zend_error+0x4d9
[d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\zend\zend.c @ 1020]
00c0fb20 100be0d3 10520bcf 0020 php5ts!php_verror+0x566
[d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\main\main.c @ 780]
00c0fb3c 101cd357 02ab1250 0020
php5ts!php_error_docref0+0x23
[d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\main\main.c @ 791]
00c0fb74 100c5825 02c4f398 0001
php5ts!php_load_extension+0x1e7
[d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\ext\standard\dl.c @ 212]
00c0fb88 100a950c 02e536c0 02ab1250 000a
php5ts!php_load_php_extension_cb+0x15
[d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\main\php_ini.c @ 330]
00c0fba0 100c6115 1054c7e8 100c5810 02ab1250
php5ts!zend_llist_apply+0x1c
[d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\zend\zend_llist.c @ 193]
00c0fbc0 100c0d61 02ab1250 00c0fbf0
php5ts!php_ini_register_extensions+0x25
[d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\main\php_ini.c @ 720]
00c0fdc8 004014bf 00407010
php5ts!php_module_startup+0x8e1
[d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\main\main.c @ 1992]
00c0fdd8 00401cb3 00407010 0040742c 0001 php!php_cli_startup+0xf
[d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\sapi\cli\php_cli.c @ 399]
00c0ff44 00402e5a 0002 02ab2f38 02ab1ac0 php!main+0x363
[d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\sapi\cli\php_cli.c @ 771]
00c0ff88 75f0eccb 7efde000 00c0ffd4 77c7d24d
php!__tmainCRTStartup+0x10f
[f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 586]
00c0ff94 77c7d24d 7efde000 684dc29c
kernel32!BaseThreadInitThunk+0xe
00c0ffd4 77c7d45f 00402fa2 7efde000
ntdll32!__RtlUserThreadStart+0x23
00c0ffec 00402fa2 7efde000
ntdll32!_RtlUserThreadStart+0x1b
FAULTING_SOURCE_CODE:
839: {
840: char *env;
841:
842: /* Checking configure timezone */
843: if (DATEG(timezone) (strlen(DATEG(timezone)) 0)) {
844: return DATEG(timezone);
845: }
846: /* Check environment variable */
847: env = getenv(TZ);
848: if (env *env timelib_timezone_id_is_valid(env, tzdb)) {
SYMBOL_STACK_INDEX: 0
SYMBOL_NAME: php5ts!guess_timezone+20
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: php5ts
IMAGE_NAME: php5ts.dll
DEBUG_FLR_IMAGE_TIMESTAMP: 4a4929bb
STACK_COMMAND: ~0s ; kb
FAILURE_BUCKET_ID:
#49262 [Opn]: PDO MySQL doesn't take STRING params
ID: 49262 Updated by: u...@php.net Reported By: grzegorz at heex dot pl Status: Open Bug Type: PDO related Operating System: Win XP Sp3 PHP Version: 5.3.0 New Comment: Thanks again, utf8 everywhere. We guessed so. I don't know if its of much relevance but one last question: what version of MySQL 6.0 are you using? .oO( MySQL 6.0 is something I don't like to see here. I wouldn't want to debug a non-GA server, if I had a choice. ) Thanks! Previous Comments: [2009-09-22 16:35:59] grzegorz at heex dot pl Variable_name Value character_set_clientutf8 character_set_connectionutf8 character_set_database utf8 character_set_filesystembinary character_set_results utf8 character_set_serverutf8 character_set_systemutf8 character_sets_dir C:\Program Files\MySQL\MySQL Server 6.0\share\char.. [2009-09-22 13:53:00] u...@php.net Ok, great. Your character set is uft8 (uft8_general_ci is the collation). Can you paste SHOW VARIABLES LIKE '%character%' to give details about your MySQL settings? Thanks! [2009-09-20 22:44:06] grzegorz at heex dot pl Column lng_name and a whole table they have utf8_general_ci charset. [2009-09-18 08:39:34] u...@php.net Can you say anything about the character sets you are using? [2009-08-25 07:57:54] grzegorz at heex dot pl FunctionArg 1 Arg 2 Arg 3 Source php5ts!mysqlnd_cset_escape_slashes+30 05652000 0565fb58 php_pdo_mysql!_pdo_mysql_error+6f7 0565f5880565fb58 0006 php5ts!pdo_parse_params+394 05662d5005662e780026 php5ts!pdo_stmt_describe_columns+7720565f638 php5ts!execute+10b9 05690070015e5801007f66b8 php5ts!execute+156d 015e585803e8fbe0 php5ts!execute+298 0565dbf0015e5800015e5858 php5ts!zend_execute_scripts+fe 0008015e5858 php5ts!php_execute_script+231 03e8fe6c015e58580005 php5apache2_2!zm_info_apache+1744 007aa7600073a400 007aa760 libhttpd!ap_run_handler+21 007aa760007aa760007aa760 libhttpd!ap_invoke_handler+ae 007a771803e8ff38 libhttpd!ap_die+24e 007aa7600073aac8 libhttpd!ap_get_request_note+1c6c 007a7718007a7718 007a7718 libhttpd!ap_run_process_connection+21 007a77180074a198 03e8ff80 libhttpd!ap_process_connection+33 007a7718007a26d8 0006fb80 libhttpd!ap_regkey_value_remove+c0c 007a77100006fb80 00eb0650 msvcrt!_endthreadex+a9 0079ef880006fb8000eb0650 kernel32!BaseThreadStart+37 77c2a3410079ef88 PHP5TS!MYSQLND_CSET_ESCAPE_SLASHES+30In httpd__PID__4604__Date__08_25_2009__Time_09_37_39AM__46__Second_Chance_Exception_C005.dmp the assembly instruction at php5ts!mysqlnd_cset_escape_slashes+30 in C:\php5\php5ts.dll from The PHP Group has caused an access violation exception (0xC005) when trying to read from memory location 0x0010 on thread 157 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/49262 -- Edit this bug report at http://bugs.php.net/?id=49262edit=1
#49626 [Com]: Access violation in php.exe
ID: 49626
Comment by: jbreiding at hotmail dot com
Reported By: jbreiding at hotmail dot com
Status: Feedback
Bug Type: Reproducible crash
Operating System: windows server 2008 x64
PHP Version: 5.3.0
New Comment:
nogo, same problem. am i possibly missing some configuration?
Previous Comments:
[2009-09-22 16:56:57] paj...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2009-09-22 16:41:25] jbreiding at hotmail dot com
adding exception analysis from windbg:
FAULTING_IP:
php5ts!guess_timezone+20
[d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\ext\date\php_date.c @ 843]
100f3d20 8b4204 mov eax,dword ptr [edx+4]
EXCEPTION_RECORD: -- (.exr 0x)
ExceptionAddress: 100f3d20
(php5ts!guess_timezone+0x0020)
ExceptionCode: c005 (Access violation)
ExceptionFlags:
NumberParameters: 2
Parameter[0]:
Parameter[1]: 180050ac
Attempt to read from address 180050ac
FAULTING_THREAD: 11a8
DEFAULT_BUCKET_ID: INVALID_POINTER_READ
PROCESS_NAME: php.exe
ERROR_CODE: (NTSTATUS) 0xc005 - The instruction at 0x%08lx
referenced memory at 0x%08lx. The memory could not be %s.
EXCEPTION_CODE: (NTSTATUS) 0xc005 - The instruction at 0x%08lx
referenced memory at 0x%08lx. The memory could not be %s.
EXCEPTION_PARAMETER1:
EXCEPTION_PARAMETER2: 180050ac
READ_ADDRESS: 180050ac
FOLLOWUP_IP:
php5ts!guess_timezone+20
[d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\ext\date\php_date.c @ 843]
100f3d20 8b4204 mov eax,dword ptr [edx+4]
NTGLOBALFLAG: 70
APPLICATION_VERIFIER_FLAGS: 0
PRIMARY_PROBLEM_CLASS: INVALID_POINTER_READ
BUGCHECK_STR: APPLICATION_FAULT_INVALID_POINTER_READ
LAST_CONTROL_TRANSFER: from 100f3f1e to 100f3d20
STACK_TEXT:
00c0f9e0 100f3f1e 0001 02ebfe68 0020 php5ts!guess_timezone+0x20
[d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\ext\date\php_date.c @ 843]
00c0f9f0 100f4c1b 02ab1250 02ab1250 0003
php5ts!get_timezone_info+0x1e
[d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\ext\date\php_date.c @ 928]
00c0fa00 100bda11 1036a294 000b 4ab8fb18
php5ts!php_format_date+0x1b
[d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\ext\date\php_date.c @ 1179]
00c0fa2c 100be4e4 02c42850 02ab1250 00c0fa74 php5ts!php_log_err+0xa1
[d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\main\main.c @ 542]
00c0fa88 10002909 0020 1035b924 php5ts!php_error_cb+0x354
[d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\main\main.c @ 952]
00c0fad4 100be066 0020 1035b99c 02c42600 php5ts!zend_error+0x4d9
[d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\zend\zend.c @ 1020]
00c0fb20 100be0d3 10520bcf 0020 php5ts!php_verror+0x566
[d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\main\main.c @ 780]
00c0fb3c 101cd357 02ab1250 0020
php5ts!php_error_docref0+0x23
[d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\main\main.c @ 791]
00c0fb74 100c5825 02c4f398 0001
php5ts!php_load_extension+0x1e7
[d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\ext\standard\dl.c @ 212]
00c0fb88 100a950c 02e536c0 02ab1250 000a
php5ts!php_load_php_extension_cb+0x15
[d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\main\php_ini.c @ 330]
00c0fba0 100c6115 1054c7e8 100c5810 02ab1250
php5ts!zend_llist_apply+0x1c
[d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\zend\zend_llist.c @ 193]
00c0fbc0 100c0d61 02ab1250 00c0fbf0
php5ts!php_ini_register_extensions+0x25
[d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\main\php_ini.c @ 720]
00c0fdc8 004014bf 00407010
php5ts!php_module_startup+0x8e1
[d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\main\main.c @ 1992]
00c0fdd8 00401cb3 00407010 0040742c 0001 php!php_cli_startup+0xf
[d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\sapi\cli\php_cli.c @ 399]
00c0ff44 00402e5a 0002 02ab2f38 02ab1ac0 php!main+0x363
[d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\sapi\cli\php_cli.c @ 771]
00c0ff88 75f0eccb 7efde000 00c0ffd4 77c7d24d
php!__tmainCRTStartup+0x10f
[f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 586]
00c0ff94 77c7d24d 7efde000 684dc29c
kernel32!BaseThreadInitThunk+0xe
00c0ffd4 77c7d45f 00402fa2 7efde000
ntdll32!__RtlUserThreadStart+0x23
00c0ffec 00402fa2 7efde000
ntdll32!_RtlUserThreadStart+0x1b
FAULTING_SOURCE_CODE:
839: {
840: char *env;
841:
842: /* Checking configure timezone */
843: if (DATEG(timezone) (strlen(DATEG(timezone)) 0)) {
844: return DATEG(timezone);
845: }
846: /* Check environment variable */
847: env = getenv(TZ);
848: if (env *env timelib_timezone_id_is_valid(env, tzdb)) {
SYMBOL_STACK_INDEX: 0
SYMBOL_NAME:
#49626 [Fbk]: Access violation in php.exe
ID: 49626
Updated by: paj...@php.net
Reported By: jbreiding at hotmail dot com
Status: Feedback
Bug Type: Reproducible crash
Operating System: windows server 2008 x64
PHP Version: 5.3.0
New Comment:
Most likely yes, I can't reproduce it, no matter which SAPI I use.
fastcgi, apache or CLI. Which one do you use?
Can you try using CLI and then using your server without any extension
loaded (no php.ini either, be sure that no php.ini are in windows\ or
common directories).
Previous Comments:
[2009-09-22 17:12:31] jbreiding at hotmail dot com
nogo, same problem. am i possibly missing some configuration?
[2009-09-22 16:56:57] paj...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2009-09-22 16:41:25] jbreiding at hotmail dot com
adding exception analysis from windbg:
FAULTING_IP:
php5ts!guess_timezone+20
[d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\ext\date\php_date.c @ 843]
100f3d20 8b4204 mov eax,dword ptr [edx+4]
EXCEPTION_RECORD: -- (.exr 0x)
ExceptionAddress: 100f3d20
(php5ts!guess_timezone+0x0020)
ExceptionCode: c005 (Access violation)
ExceptionFlags:
NumberParameters: 2
Parameter[0]:
Parameter[1]: 180050ac
Attempt to read from address 180050ac
FAULTING_THREAD: 11a8
DEFAULT_BUCKET_ID: INVALID_POINTER_READ
PROCESS_NAME: php.exe
ERROR_CODE: (NTSTATUS) 0xc005 - The instruction at 0x%08lx
referenced memory at 0x%08lx. The memory could not be %s.
EXCEPTION_CODE: (NTSTATUS) 0xc005 - The instruction at 0x%08lx
referenced memory at 0x%08lx. The memory could not be %s.
EXCEPTION_PARAMETER1:
EXCEPTION_PARAMETER2: 180050ac
READ_ADDRESS: 180050ac
FOLLOWUP_IP:
php5ts!guess_timezone+20
[d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\ext\date\php_date.c @ 843]
100f3d20 8b4204 mov eax,dword ptr [edx+4]
NTGLOBALFLAG: 70
APPLICATION_VERIFIER_FLAGS: 0
PRIMARY_PROBLEM_CLASS: INVALID_POINTER_READ
BUGCHECK_STR: APPLICATION_FAULT_INVALID_POINTER_READ
LAST_CONTROL_TRANSFER: from 100f3f1e to 100f3d20
STACK_TEXT:
00c0f9e0 100f3f1e 0001 02ebfe68 0020 php5ts!guess_timezone+0x20
[d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\ext\date\php_date.c @ 843]
00c0f9f0 100f4c1b 02ab1250 02ab1250 0003
php5ts!get_timezone_info+0x1e
[d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\ext\date\php_date.c @ 928]
00c0fa00 100bda11 1036a294 000b 4ab8fb18
php5ts!php_format_date+0x1b
[d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\ext\date\php_date.c @ 1179]
00c0fa2c 100be4e4 02c42850 02ab1250 00c0fa74 php5ts!php_log_err+0xa1
[d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\main\main.c @ 542]
00c0fa88 10002909 0020 1035b924 php5ts!php_error_cb+0x354
[d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\main\main.c @ 952]
00c0fad4 100be066 0020 1035b99c 02c42600 php5ts!zend_error+0x4d9
[d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\zend\zend.c @ 1020]
00c0fb20 100be0d3 10520bcf 0020 php5ts!php_verror+0x566
[d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\main\main.c @ 780]
00c0fb3c 101cd357 02ab1250 0020
php5ts!php_error_docref0+0x23
[d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\main\main.c @ 791]
00c0fb74 100c5825 02c4f398 0001
php5ts!php_load_extension+0x1e7
[d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\ext\standard\dl.c @ 212]
00c0fb88 100a950c 02e536c0 02ab1250 000a
php5ts!php_load_php_extension_cb+0x15
[d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\main\php_ini.c @ 330]
00c0fba0 100c6115 1054c7e8 100c5810 02ab1250
php5ts!zend_llist_apply+0x1c
[d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\zend\zend_llist.c @ 193]
00c0fbc0 100c0d61 02ab1250 00c0fbf0
php5ts!php_ini_register_extensions+0x25
[d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\main\php_ini.c @ 720]
00c0fdc8 004014bf 00407010
php5ts!php_module_startup+0x8e1
[d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\main\main.c @ 1992]
00c0fdd8 00401cb3 00407010 0040742c 0001 php!php_cli_startup+0xf
[d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\sapi\cli\php_cli.c @ 399]
00c0ff44 00402e5a 0002 02ab2f38 02ab1ac0 php!main+0x363
[d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\sapi\cli\php_cli.c @ 771]
00c0ff88 75f0eccb 7efde000 00c0ffd4 77c7d24d
php!__tmainCRTStartup+0x10f
[f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 586]
00c0ff94 77c7d24d 7efde000 684dc29c
kernel32!BaseThreadInitThunk+0xe
00c0ffd4 77c7d45f 00402fa2 7efde000
ntdll32!__RtlUserThreadStart+0x23
00c0ffec 00402fa2 7efde000
ntdll32!_RtlUserThreadStart+0x1b
FAULTING_SOURCE_CODE:
839: {
840: char *env;
841:
842:
#49627 [NEW]: error_log to specified file does not log time according to date.timezone
From: mp at icomme dot fr
Operating system: FreeBSD 7.2
PHP version: 5.2.11
PHP Bug Type: Unknown/Other Function
Bug description: error_log to specified file does not log time according to
date.timezone
Description:
When php.ini is configured with error_log to a specified file (not via
syslog), PHP does not log date and time of records (errors, warnings, etc.)
according to the date.timezone configured in php.ini, it's always
recorded with GMT time.
PHP (5.2.6) used to work correctly with this.
OS and PHP have correct time zone :
$ date
Tue Sep 22 19:05:32 CEST 2009
... time on OS is correctly configured : CEST = GMT+2
print date('r T');
print gmdate('r T');
... respectivly returns :
Tue, 22 Sep 2009 19:06:12 +0200 CEST
Tue, 22 Sep 2009 17:06:12 + GMT
... PHP correctly configured
Box :
FreeBSD 7.2-RELEASE (GENERIC)
Apache/2.2.13 (Unix)
PHP 5.2.11
Someone says (bug 45191) this bug has been fixed in CVS on May 2009, but 2
versions of the 5.2 branch had been released since this date, and the bug
is still present.
Reproduce code:
---
# php.ini :
; Log errors to specified file.
error_log = /var/log/php/php-error.log
; Defines the default timezone used by the date functions
date.timezone = Europe/Paris
# test.php :
nonexistantfunction();
Expected result:
[22-Sep-2009 18:57:55] PHP Fatal error: Call to undefined function
nonexistantfunction() in /usr/home/michel/public_html/plante.php on line 9
Actual result:
--
[22-Sep-2009 16:57:55] PHP Fatal error: Call to undefined function
nonexistantfunction() in /usr/home/michel/public_html/plante.php on line 9
--
Edit bug report at http://bugs.php.net/?id=49627edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49627r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49627r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49627r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49627r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49627r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49627r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49627r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49627r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49627r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49627r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49627r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49627r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49627r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49627r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49627r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49627r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49627r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49627r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49627r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49627r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49627r=mysqlcfg
#49626 [Com]: Access violation in php.exe
ID: 49626 Comment by: jbreiding at hotmail dot com Reported By: jbreiding at hotmail dot com Status: Feedback Bug Type: Reproducible crash Operating System: windows server 2008 x64 PHP Version: 5.3.0 New Comment: ok that worked, here are my extensions below: [PHP_LDAP] extension=php_ldap.dll [PHP_MYSQL] extension=php_mysql.dll [PHP_PDO] extension=php_pdo.dll [PHP_PDO_MYSQL] extension=php_pdo_mysql.dll [PHP_CURL] extension=php_curl.dll [PHP_BZ2] extension=php_bz2.dll [PHP_FDF] extension=php_fdf.dll [PHP_MCRYPT] extension=php_mcrypt.dll [PHP_MHASH] extension=php_mhash.dll [PHP_SHMOP] extension=php_shmop.dll [PHP_ZIP] extension=php_zip.dll [PHP_GD2] extension=php_gd2.dll [PHP_OPENSSL] extension=php_openssl.dll [PHP_GETTEXT] extension=php_gettext.dll Previous Comments: [2009-09-22 17:15:44] paj...@php.net Most likely yes, I can't reproduce it, no matter which SAPI I use. fastcgi, apache or CLI. Which one do you use? Can you try using CLI and then using your server without any extension loaded (no php.ini either, be sure that no php.ini are in windows\ or common directories). [2009-09-22 17:12:31] jbreiding at hotmail dot com nogo, same problem. am i possibly missing some configuration? [2009-09-22 16:56:57] paj...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-09-22 16:41:25] jbreiding at hotmail dot com adding exception analysis from windbg: FAULTING_IP: php5ts!guess_timezone+20 [d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\ext\date\php_date.c @ 843] 100f3d20 8b4204 mov eax,dword ptr [edx+4] EXCEPTION_RECORD: -- (.exr 0x) ExceptionAddress: 100f3d20 (php5ts!guess_timezone+0x0020) ExceptionCode: c005 (Access violation) ExceptionFlags: NumberParameters: 2 Parameter[0]: Parameter[1]: 180050ac Attempt to read from address 180050ac FAULTING_THREAD: 11a8 DEFAULT_BUCKET_ID: INVALID_POINTER_READ PROCESS_NAME: php.exe ERROR_CODE: (NTSTATUS) 0xc005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s. EXCEPTION_CODE: (NTSTATUS) 0xc005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s. EXCEPTION_PARAMETER1: EXCEPTION_PARAMETER2: 180050ac READ_ADDRESS: 180050ac FOLLOWUP_IP: php5ts!guess_timezone+20 [d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\ext\date\php_date.c @ 843] 100f3d20 8b4204 mov eax,dword ptr [edx+4] NTGLOBALFLAG: 70 APPLICATION_VERIFIER_FLAGS: 0 PRIMARY_PROBLEM_CLASS: INVALID_POINTER_READ BUGCHECK_STR: APPLICATION_FAULT_INVALID_POINTER_READ LAST_CONTROL_TRANSFER: from 100f3f1e to 100f3d20 STACK_TEXT: 00c0f9e0 100f3f1e 0001 02ebfe68 0020 php5ts!guess_timezone+0x20 [d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\ext\date\php_date.c @ 843] 00c0f9f0 100f4c1b 02ab1250 02ab1250 0003 php5ts!get_timezone_info+0x1e [d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\ext\date\php_date.c @ 928] 00c0fa00 100bda11 1036a294 000b 4ab8fb18 php5ts!php_format_date+0x1b [d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\ext\date\php_date.c @ 1179] 00c0fa2c 100be4e4 02c42850 02ab1250 00c0fa74 php5ts!php_log_err+0xa1 [d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\main\main.c @ 542] 00c0fa88 10002909 0020 1035b924 php5ts!php_error_cb+0x354 [d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\main\main.c @ 952] 00c0fad4 100be066 0020 1035b99c 02c42600 php5ts!zend_error+0x4d9 [d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\zend\zend.c @ 1020] 00c0fb20 100be0d3 10520bcf 0020 php5ts!php_verror+0x566 [d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\main\main.c @ 780] 00c0fb3c 101cd357 02ab1250 0020 php5ts!php_error_docref0+0x23 [d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\main\main.c @ 791] 00c0fb74 100c5825 02c4f398 0001 php5ts!php_load_extension+0x1e7 [d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\ext\standard\dl.c @ 212] 00c0fb88 100a950c 02e536c0 02ab1250 000a php5ts!php_load_php_extension_cb+0x15 [d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\main\php_ini.c @ 330] 00c0fba0 100c6115 1054c7e8 100c5810 02ab1250 php5ts!zend_llist_apply+0x1c [d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\zend\zend_llist.c @ 193] 00c0fbc0 100c0d61 02ab1250 00c0fbf0 php5ts!php_ini_register_extensions+0x25 [d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\main\php_ini.c @ 720] 00c0fdc8 004014bf 00407010 php5ts!php_module_startup+0x8e1 [d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\main\main.c @ 1992] 00c0fdd8 00401cb3 00407010
#49618 [Bgs]: spl_autoload_register destroys __autoload hook
ID: 49618
Updated by: sjo...@php.net
Reported By: jost dot boekemeier at googlemail dot com
Status: Bogus
Bug Type: SPL related
Operating System: Any
PHP Version: 5.2.11
New Comment:
If two or more of the libraries use __autoload, it won't work, and
there is nothing anybody can do about it.
If all of the libraries use spl_autoload_register, it works as it
should.
If one of the libraries uses __autoload and others use
spl_autoload_register, it is the task of the library that uses
spl_autoload_register to register __autoload as well, like this:
if (function_exists(__autoload)) spl_autoload_register(__autoload);
Previous Comments:
[2009-09-22 09:26:02] jost dot boekemeier at googlemail dot com
My code doesn't use __autoload.
My code uses spl_autoloload.
I have received a bug report because my code has destroyed an existing
library.
By issuing this bug report I have asked you to stop this, by either:
* deprecating __autoload altogether
* fix spl_autoload to honor an existing __autoload or
* let library authors check for an existing (or upcoming) __autoload so
that their
library doesn't destroy existing code
With the current behaviour I have no other choice but to not use
spl_autoload at all,
since I don't know whether the user will or will not include a library
which uses
__autoload later on.
[2009-09-22 09:11:12] sjo...@php.net
Thank you for your report.
I do not think the behavior you describe is a bug. The documentation is
clear about this:
If your code has an existing __autoload function then this function
must be explicitly registered on the __autoload stack. This is because
spl_autoload_register() will effectively replace the engine cache for
the __autoload function by either spl_autoload() or
spl_autoload_call().
Thus, calling spl_autoload_register() replaces __autoload().
[2009-09-22 05:24:02] jost dot boekemeier at googlemail dot com
Description:
The first call to spl_autoload_register destroys an existing __autoload
hook.
Please either deprecate __autoload and/or register __autoload with
spl_autoload.
Complete problem description is here:
http://sourceforge.net/mailarchive/forum.php?
thread_name=3afa16cf0909210312v3e102491n18701bcca0f5e030%40mail.gmail.com
forum_name=php-java-bridge-users
Reproduce code:
---
?php
function autoload_legacy($x) {echo legacy ; return false;}
function autoload_spl1($x) {echo spl1 ; return false;}
function autoload_spl2($x) {echo spl2 ; return false;}
function autoload_spl3($x) {echo spl3 ; return false;}
spl_autoload_register(autoload_spl1);
function __autoload($x) {return autoload_legacy($x);}
spl_autoload_register(autoload_spl2);
spl_autoload_register(autoload_spl3);
@new Foo();
?
Expected result:
spl1 spl2 spl3 legacy
Actual result:
--
spl1 spl2 spl3
--
Edit this bug report at http://bugs.php.net/?id=49618edit=1
#49618 [Bgs]: spl_autoload_register destroys __autoload hook
ID: 49618
User updated by: jost dot boekemeier at googlemail dot com
Reported By: jost dot boekemeier at googlemail dot com
Status: Bogus
Bug Type: SPL related
Operating System: Any
PHP Version: 5.2.11
New Comment:
if (function_exists(__autoload)) spl_autoload_register(__
autoload)
Doesn't work. In line 7 __autoload is not yet defined.
Note that every line in the given example comes from a separate
include()d php
library.
This is a link-time problem which only php can resolve: it must save a
legacy
__autoload handler before creating the spl_autoload stack and call the
legacy
autoload after all other registered spl_autoload hooks.
Previous Comments:
[2009-09-22 17:26:38] sjo...@php.net
If two or more of the libraries use __autoload, it won't work, and
there is nothing anybody can do about it.
If all of the libraries use spl_autoload_register, it works as it
should.
If one of the libraries uses __autoload and others use
spl_autoload_register, it is the task of the library that uses
spl_autoload_register to register __autoload as well, like this:
if (function_exists(__autoload)) spl_autoload_register(__autoload);
[2009-09-22 09:26:02] jost dot boekemeier at googlemail dot com
My code doesn't use __autoload.
My code uses spl_autoloload.
I have received a bug report because my code has destroyed an existing
library.
By issuing this bug report I have asked you to stop this, by either:
* deprecating __autoload altogether
* fix spl_autoload to honor an existing __autoload or
* let library authors check for an existing (or upcoming) __autoload so
that their
library doesn't destroy existing code
With the current behaviour I have no other choice but to not use
spl_autoload at all,
since I don't know whether the user will or will not include a library
which uses
__autoload later on.
[2009-09-22 09:11:12] sjo...@php.net
Thank you for your report.
I do not think the behavior you describe is a bug. The documentation is
clear about this:
If your code has an existing __autoload function then this function
must be explicitly registered on the __autoload stack. This is because
spl_autoload_register() will effectively replace the engine cache for
the __autoload function by either spl_autoload() or
spl_autoload_call().
Thus, calling spl_autoload_register() replaces __autoload().
[2009-09-22 05:24:02] jost dot boekemeier at googlemail dot com
Description:
The first call to spl_autoload_register destroys an existing __autoload
hook.
Please either deprecate __autoload and/or register __autoload with
spl_autoload.
Complete problem description is here:
http://sourceforge.net/mailarchive/forum.php?
thread_name=3afa16cf0909210312v3e102491n18701bcca0f5e030%40mail.gmail.com
forum_name=php-java-bridge-users
Reproduce code:
---
?php
function autoload_legacy($x) {echo legacy ; return false;}
function autoload_spl1($x) {echo spl1 ; return false;}
function autoload_spl2($x) {echo spl2 ; return false;}
function autoload_spl3($x) {echo spl3 ; return false;}
spl_autoload_register(autoload_spl1);
function __autoload($x) {return autoload_legacy($x);}
spl_autoload_register(autoload_spl2);
spl_autoload_register(autoload_spl3);
@new Foo();
?
Expected result:
spl1 spl2 spl3 legacy
Actual result:
--
spl1 spl2 spl3
--
Edit this bug report at http://bugs.php.net/?id=49618edit=1
#49629 [NEW]: Regression in 5.2 caused by #44144
From: romain dot dorgueil at symfony-project dot com
Operating system: linux 2.6.18-4-vserver-686
PHP version: 5.2.11
PHP Bug Type: *General Issues
Bug description: Regression in 5.2 caused by #44144
Description:
In #44144, it was said spl_autoload_functions() should return object
instances, not class names, when appropriate.
should and when appropriate seems a bit hazardous, to speak about
a
feature that has been working some way until 5.2.10
After a discussion with Pierre, he summed it up well as :
Pierre that's a very bad idea and break BC for a behavior that has
existed for a good dozen releases
I understand that maybe we want it to behave somehow else in future
versions, but I'm not sure minor releases of php 5.2 are the best
place for it.
I will understand very well if this ticket is closed as invalid or
wontfix (as the damage is already done, it's for sure a good idea not
to change again in .12), but I wanted to report it to show how a so
little BC change can affect some projects.
Reproduce code:
---
?php
class Foo {
public function nonstaticMethod() {}
}
$foo = new Foo;
spl_autoload_register(array($foo, 'nonstaticMethod'));
$funcs = spl_autoload_functions();
print_r((int) is_object($func[0][0]));
Expected result:
0
Actual result:
--
1
--
Edit bug report at http://bugs.php.net/?id=49629edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49629r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49629r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49629r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49629r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49629r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49629r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49629r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49629r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49629r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49629r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49629r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49629r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49629r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49629r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49629r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49629r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49629r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49629r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49629r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49629r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49629r=mysqlcfg
#44144 [Csd]: spl_autoload_functions() should return object instance when appropriate
ID: 44144
Updated by: paj...@php.net
Reported By: ezy...@php.net
Status: Closed
Bug Type: SPL related
Operating System: Irrelevant
PHP Version: 5.3CVS-2008-02-18 (CVS)
Assigned To: colder
New Comment:
Please do not do such change again in stable releases!
It is obviously a BC break and forces users to have a work around for
5.2.11 and later while keeping the old code for 5.2.10 or earlier.
I can understand that we like to match what is done in call_user_func,
but it should not be done at the price of BC in a stable branche (has
behaved like that for many releases already).
Previous Comments:
[2009-07-28 22:25:31] s...@php.net
Automatic comment from SVN on behalf of bjori
Revision: http://svn.php.net/viewvc/?view=revisionrevision=286476
Log: MFH: Fixed bug #44144 add test
[2008-02-29 21:31:38] ezy...@php.net
Thanks for the fix. Do you think, by any chance, we can sneak this into
PHP 5.2, or is that impossible?
[2008-02-29 13:48:41] col...@php.net
This bug has been fixed in CVS.
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.
[2008-02-18 02:07:06] ezy...@php.net
Description:
spl_autoload_functions() should return object instances, not class
names, when appropriate.
Reproduce code:
---
?php
class Foo {
public function nonstaticMethod() {}
}
$foo = new Foo;
spl_autoload_register(array($foo, 'nonstaticMethod'));
$funcs = spl_autoload_functions();
print_r((int) is_object($func[0][0]));
Expected result:
1
Actual result:
--
0
--
Edit this bug report at http://bugs.php.net/?id=44144edit=1
#49630 [NEW]: imap_listscan function missing
From: olivier at oxeva dot fr
Operating system: all
PHP version: 5.3SVN-2009-09-22 (SVN)
PHP Bug Type: IMAP related
Bug description: imap_listscan function missing
Description:
The PHP function imap_listscan() is missing:
Fatal error: Call to undefined function imap_listscan() in /***/test.php
on line 3
The function exists in documentation:
http://fr.php.net/imap_listscan
The function exists in sourcecode:
http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/ext/imap/php_imap.c?view=markup
(line 1862)
Reproduce code:
---
?php
$stream_id = imap_open('localhost', 'm...@me.com', 'b...@boum.com') or
die(Cannot connect to mailbox $default_mailbox: . imap_last_error());
imap_listscan($stream_id,$default_mailbox,'INBOX');
imap_close($stream_id);
Expected result:
Function is at least found :)
Actual result:
--
Fatal error: Call to undefined function imap_listscan() in
/***/imap_listscan_basic.php on line 3
--
Edit bug report at http://bugs.php.net/?id=49630edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49630r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49630r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49630r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49630r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49630r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49630r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49630r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49630r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49630r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49630r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49630r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49630r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49630r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49630r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49630r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49630r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49630r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49630r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49630r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49630r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49630r=mysqlcfg
#49626 [Com]: Access violation in php.exe
ID: 49626 Comment by: jbreiding at hotmail dot com Reported By: jbreiding at hotmail dot com Status: Feedback Bug Type: Reproducible crash Operating System: windows server 2008 x64 PHP Version: 5.3.0 New Comment: looks like this was due to missing extensions that were referenced in the ini file. thanks for the help. shouldnt this have shown itself in a more helpful error? or at least died when the extension was attempting to load? Previous Comments: [2009-09-22 17:22:53] jbreiding at hotmail dot com ok that worked, here are my extensions below: [PHP_LDAP] extension=php_ldap.dll [PHP_MYSQL] extension=php_mysql.dll [PHP_PDO] extension=php_pdo.dll [PHP_PDO_MYSQL] extension=php_pdo_mysql.dll [PHP_CURL] extension=php_curl.dll [PHP_BZ2] extension=php_bz2.dll [PHP_FDF] extension=php_fdf.dll [PHP_MCRYPT] extension=php_mcrypt.dll [PHP_MHASH] extension=php_mhash.dll [PHP_SHMOP] extension=php_shmop.dll [PHP_ZIP] extension=php_zip.dll [PHP_GD2] extension=php_gd2.dll [PHP_OPENSSL] extension=php_openssl.dll [PHP_GETTEXT] extension=php_gettext.dll [2009-09-22 17:15:44] paj...@php.net Most likely yes, I can't reproduce it, no matter which SAPI I use. fastcgi, apache or CLI. Which one do you use? Can you try using CLI and then using your server without any extension loaded (no php.ini either, be sure that no php.ini are in windows\ or common directories). [2009-09-22 17:12:31] jbreiding at hotmail dot com nogo, same problem. am i possibly missing some configuration? [2009-09-22 16:56:57] paj...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-09-22 16:41:25] jbreiding at hotmail dot com adding exception analysis from windbg: FAULTING_IP: php5ts!guess_timezone+20 [d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\ext\date\php_date.c @ 843] 100f3d20 8b4204 mov eax,dword ptr [edx+4] EXCEPTION_RECORD: -- (.exr 0x) ExceptionAddress: 100f3d20 (php5ts!guess_timezone+0x0020) ExceptionCode: c005 (Access violation) ExceptionFlags: NumberParameters: 2 Parameter[0]: Parameter[1]: 180050ac Attempt to read from address 180050ac FAULTING_THREAD: 11a8 DEFAULT_BUCKET_ID: INVALID_POINTER_READ PROCESS_NAME: php.exe ERROR_CODE: (NTSTATUS) 0xc005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s. EXCEPTION_CODE: (NTSTATUS) 0xc005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s. EXCEPTION_PARAMETER1: EXCEPTION_PARAMETER2: 180050ac READ_ADDRESS: 180050ac FOLLOWUP_IP: php5ts!guess_timezone+20 [d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\ext\date\php_date.c @ 843] 100f3d20 8b4204 mov eax,dword ptr [edx+4] NTGLOBALFLAG: 70 APPLICATION_VERIFIER_FLAGS: 0 PRIMARY_PROBLEM_CLASS: INVALID_POINTER_READ BUGCHECK_STR: APPLICATION_FAULT_INVALID_POINTER_READ LAST_CONTROL_TRANSFER: from 100f3f1e to 100f3d20 STACK_TEXT: 00c0f9e0 100f3f1e 0001 02ebfe68 0020 php5ts!guess_timezone+0x20 [d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\ext\date\php_date.c @ 843] 00c0f9f0 100f4c1b 02ab1250 02ab1250 0003 php5ts!get_timezone_info+0x1e [d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\ext\date\php_date.c @ 928] 00c0fa00 100bda11 1036a294 000b 4ab8fb18 php5ts!php_format_date+0x1b [d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\ext\date\php_date.c @ 1179] 00c0fa2c 100be4e4 02c42850 02ab1250 00c0fa74 php5ts!php_log_err+0xa1 [d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\main\main.c @ 542] 00c0fa88 10002909 0020 1035b924 php5ts!php_error_cb+0x354 [d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\main\main.c @ 952] 00c0fad4 100be066 0020 1035b99c 02c42600 php5ts!zend_error+0x4d9 [d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\zend\zend.c @ 1020] 00c0fb20 100be0d3 10520bcf 0020 php5ts!php_verror+0x566 [d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\main\main.c @ 780] 00c0fb3c 101cd357 02ab1250 0020 php5ts!php_error_docref0+0x23 [d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\main\main.c @ 791] 00c0fb74 100c5825 02c4f398 0001 php5ts!php_load_extension+0x1e7 [d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\ext\standard\dl.c @ 212] 00c0fb88 100a950c 02e536c0 02ab1250 000a php5ts!php_load_php_extension_cb+0x15 [d:\php-sdk\snap_5_3\vc9\x86\php-5.3.0\main\php_ini.c @ 330] 00c0fba0 100c6115 1054c7e8 100c5810 02ab1250 php5ts!zend_llist_apply+0x1c
#41027 [Opn]: Executing prepared statement changes type of bound parameters to string
ID: 41027 Updated by: sjo...@php.net Reported By: martin at bangaroo dot net Status: Open Bug Type: PDO related Operating System: Gentoo Linux PHP Version: 5.*, 6CVS (2009-04-27) New Comment: Thank you for your bug report. A workaround would be to use bindValue instead of bindParam. Previous Comments: [2009-04-27 20:47:18] martin at bangaroo dot net Same result with php5.3-200904271830: Bug still present. [2009-04-26 18:30:35] martin at bangaroo dot net I just checked with the snapshot php5.2-200904261630. Unfortunately the bug still exists. [2007-04-09 14:31:34] martin at bangaroo dot net Description: Executing a prepared statement changes the type of bound parameters to string (Tested only with pgsql driver). This bite me when I wanted to execute an insert statement only when the double value to be inserted actually changed, NULL being a possible value. Unfortunatly, comparing the new value with the old value with the !== operator didn't work, because the type-change made the test always evaluate to TRUE. Reproduce code: --- ?php $db = new PDO(pgsql:host=localhost dbname=test user=dummy); $db-query(CREATE TABLE test_table ( val REAL )); $qry = $db-prepare(INSERT INTO test_table VALUES (:val)); $qry-bindParam(:val,$bound_val); $bound_val = 5.2; echo Type before execute(): .gettype($bound_val).\n; $qry-execute(); echo Type after execute(): .gettype($bound_val).\n; $db-query(DROP TABLE test); ? Expected result: Type before execute(): double Type after execute(): double Actual result: -- Type before execute(): double Type after execute(): string -- Edit this bug report at http://bugs.php.net/?id=41027edit=1
#49626 [Fbk-Bgs]: Access violation in php.exe
ID: 49626 Updated by: paj...@php.net Reported By: jbreiding at hotmail dot com -Status: Feedback +Status: Bogus Bug Type: Reproducible crash Operating System: windows server 2008 x64 PHP Version: 5.3.0 New Comment: It is sometimes not possible to get the hand before bad things happen. Not a bug bogus. Previous Comments: [2009-09-22 17:56:30] jbreiding at hotmail dot com looks like this was due to missing extensions that were referenced in the ini file. thanks for the help. shouldnt this have shown itself in a more helpful error? or at least died when the extension was attempting to load? [2009-09-22 17:22:53] jbreiding at hotmail dot com ok that worked, here are my extensions below: [PHP_LDAP] extension=php_ldap.dll [PHP_MYSQL] extension=php_mysql.dll [PHP_PDO] extension=php_pdo.dll [PHP_PDO_MYSQL] extension=php_pdo_mysql.dll [PHP_CURL] extension=php_curl.dll [PHP_BZ2] extension=php_bz2.dll [PHP_FDF] extension=php_fdf.dll [PHP_MCRYPT] extension=php_mcrypt.dll [PHP_MHASH] extension=php_mhash.dll [PHP_SHMOP] extension=php_shmop.dll [PHP_ZIP] extension=php_zip.dll [PHP_GD2] extension=php_gd2.dll [PHP_OPENSSL] extension=php_openssl.dll [PHP_GETTEXT] extension=php_gettext.dll [2009-09-22 17:15:44] paj...@php.net Most likely yes, I can't reproduce it, no matter which SAPI I use. fastcgi, apache or CLI. Which one do you use? Can you try using CLI and then using your server without any extension loaded (no php.ini either, be sure that no php.ini are in windows\ or common directories). [2009-09-22 17:12:31] jbreiding at hotmail dot com nogo, same problem. am i possibly missing some configuration? [2009-09-22 16:56:57] paj...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ 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/49626 -- Edit this bug report at http://bugs.php.net/?id=49626edit=1
#49630 [Opn-Csd]: imap_listscan function missing
ID: 49630
Updated by: fel...@php.net
Reported By: olivier at oxeva dot fr
-Status: Open
+Status: Closed
Bug Type: IMAP related
Operating System: all
-PHP Version: 5.3SVN-2009-09-22 (SVN)
+PHP Version: 5.2, 5.3 and HEAD
-Assigned To:
+Assigned To: felipe
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.
Fixed in 5.2, 5.3 and HEAD.
Previous Comments:
[2009-09-22 18:18:58] s...@php.net
Automatic comment from SVN on behalf of felipe
Revision: http://svn.php.net/viewvc/?view=revisionrevision=288585
Log: - Fixed bug #49630 (imap_listscan function missing)
# Missing PHP_FE(), though nowdays it is used through of two aliases.
(imap_scan() and imap_scanmailbox())
[2009-09-22 17:44:45] olivier at oxeva dot fr
Description:
The PHP function imap_listscan() is missing:
Fatal error: Call to undefined function imap_listscan() in
/***/test.php on line 3
The function exists in documentation:
http://fr.php.net/imap_listscan
The function exists in sourcecode:
http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/ext/imap/php_imap.c?view=markup
(line 1862)
Reproduce code:
---
?php
$stream_id = imap_open('localhost', 'm...@me.com', 'b...@boum.com') or
die(Cannot connect to mailbox $default_mailbox: .
imap_last_error());
imap_listscan($stream_id,$default_mailbox,'INBOX');
imap_close($stream_id);
Expected result:
Function is at least found :)
Actual result:
--
Fatal error: Call to undefined function imap_listscan() in
/***/imap_listscan_basic.php on line 3
--
Edit this bug report at http://bugs.php.net/?id=49630edit=1
#44597 [Opn]: [PATCH] Postgres driver does not prepare booleans correctly
ID: 44597 Updated by: sjo...@php.net -Summary: Postgres driver does not prepare booleans correctly Reported By: kenaniah at gmail dot com Status: Open Bug Type: PDO related Operating System: Red Hat 4.1.1 PHP Version: 5.2.6 New Comment: Currently, every variable is assumed to be PDO_PARAM_STR. This patch changes this to PDO_PARAM_INT or PDO_PARAM_BOOL if the passed variable is a long or a bool, respectively. http://www.gissen.nl/files/bug44597.patch This may break existing scripts, which depend on false being converted to an empty string. Previous Comments: [2009-09-21 19:48:55] kenaniah at gmail dot com In response to sjoerd, this may very well be a product of bad documentation, but that does not exclude the functional use case. One could reasonably claim that proper detection of parameter types should in fact be part of the functional definition of execute(). Virtually every database interface built on top of PDO works around this boolean bug and allows support for mixed content in the parameter array to a prepared statement. IMHO, the PDO core should therefore be no different. Whether classified as a bug or a feature, I believe that this should still be addressed. [2009-09-21 19:18:21] sjo...@php.net I think this is not a bug but a limitation of execute(): it assumes the values in the array are string. If you want it interpreted differently, you should call bindParam() with a data_type parameter. I filed Bug #49614 PDOStatement::execute assumes string values in array to clarify the documentation. [2009-09-13 20:55:01] kenaniah at gmail dot com This is still reproducible on 5.3.0 paired with PG 8.x [2009-09-13 19:08:46] ant at specialops dot ath dot cx I can still reproduce this on PHP 5.3.0 and PostgreSQL 8.4.1. [2009-06-14 11:53:21] execut3 at gmail dot com The issue is still not fixed, I'm with PHP 5.2.6 on Ubuntu and postgresql 8.3. ERROR: invalid input syntax for type boolean: 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/44597 -- Edit this bug report at http://bugs.php.net/?id=44597edit=1
#49262 [Opn]: PDO MySQL doesn't take STRING params
ID: 49262 User updated by: grzegorz at heex dot pl Reported By: grzegorz at heex dot pl Status: Open Bug Type: PDO related Operating System: Win XP Sp3 PHP Version: 5.3.0 New Comment: It's 6.0.5-alpha-community Previous Comments: [2009-09-22 17:00:06] u...@php.net Thanks again, utf8 everywhere. We guessed so. I don't know if its of much relevance but one last question: what version of MySQL 6.0 are you using? .oO( MySQL 6.0 is something I don't like to see here. I wouldn't want to debug a non-GA server, if I had a choice. ) Thanks! [2009-09-22 16:35:59] grzegorz at heex dot pl Variable_name Value character_set_clientutf8 character_set_connectionutf8 character_set_database utf8 character_set_filesystembinary character_set_results utf8 character_set_serverutf8 character_set_systemutf8 character_sets_dir C:\Program Files\MySQL\MySQL Server 6.0\share\char.. [2009-09-22 13:53:00] u...@php.net Ok, great. Your character set is uft8 (uft8_general_ci is the collation). Can you paste SHOW VARIABLES LIKE '%character%' to give details about your MySQL settings? Thanks! [2009-09-20 22:44:06] grzegorz at heex dot pl Column lng_name and a whole table they have utf8_general_ci charset. [2009-09-18 08:39:34] u...@php.net Can you say anything about the character sets you are using? 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/49262 -- Edit this bug report at http://bugs.php.net/?id=49262edit=1
#49629 [Opn-Bgs]: Regression in 5.2 caused by #44144
ID: 49629
Updated by: j...@php.net
Reported By: romain dot dorgueil at symfony-project dot com
-Status: Open
+Status: Bogus
Bug Type: *General Issues
Operating System: linux 2.6.18-4-vserver-686
PHP Version: 5.2.11
New Comment:
Changing it again would be rather idiotic. It's done, live with it.
Previous Comments:
[2009-09-22 17:40:51] romain dot dorgueil at symfony-project dot com
Description:
In #44144, it was said spl_autoload_functions() should return object
instances, not class names, when appropriate.
should and when appropriate seems a bit hazardous, to speak about
a
feature that has been working some way until 5.2.10
After a discussion with Pierre, he summed it up well as :
Pierre that's a very bad idea and break BC for a behavior that has
existed for a good dozen releases
I understand that maybe we want it to behave somehow else in future
versions, but I'm not sure minor releases of php 5.2 are the best
place for it.
I will understand very well if this ticket is closed as invalid or
wontfix (as the damage is already done, it's for sure a good idea not
to change again in .12), but I wanted to report it to show how a so
little BC change can affect some projects.
Reproduce code:
---
?php
class Foo {
public function nonstaticMethod() {}
}
$foo = new Foo;
spl_autoload_register(array($foo, 'nonstaticMethod'));
$funcs = spl_autoload_functions();
print_r((int) is_object($func[0][0]));
Expected result:
0
Actual result:
--
1
--
Edit this bug report at http://bugs.php.net/?id=49629edit=1
#49625 [Bgs]: spl_autoload and case sensitivity
ID: 49625
User updated by: jo at feuersee dot de
Reported By: jo at feuersee dot de
Status: Bogus
Bug Type: SPL related
Operating System: Linux
PHP Version: 5.3.0
New Comment:
The reason here is that is spl_autoload becomes case
sensitive, it will break scripts which depend on spl_autoload being
case insensitive.
spl_autoload() was introduced in PHP 5.1.2 which is case sensitive
concerning class names. This implies that if an operation on an unknown
class is done, spl_autoload() is triggered and executed with the case
sensitive name of the class.
Thus we have 4 different possibilities:
1) The class name all lower case, the file containing the class
definition is all lower case (eg. $foo = system::bar(); system.php)
This will work independent wether spl_autoload() is lowercasing or not,
since all is lowercased.
Note that if the class defined in the file system.php is actually named
System it wouldn't have ever worked because the class system is still
not defined, which would trigger an error.
2) The class name all lower case, the file containing the class
definition is uppercased (eg. $foo = system::bar(); System.php)
This wouldn't work anymore on file systems which are case sensitive if
spl_autoload() would skip lowercasing.
Note that this would only have worked if the file system is case
insensitive and the class definition in System.php would define a class
system.
3) The class name contains upper case letters, the file containing the
class definition is lowercased (eg. $foo = System::bar(); system.php)
This is what currently isn't working at all but would work at least for
case insensitive file systems if lowercasing would be dropped.
Note that if the class defined in the file system.php is actually named
system it wouldn't have ever worked because the class System is still
not defined.
4) The class name contains upper case letters, the file containing the
class definition is uppercased (eg. $foo = System::bar(); System.php)
This is what should (and would) work, but currently doesn't.
Conclusion:
The only problem might be (2):
Class name: sample
Filename: Sample.php
Class definition in Sample.php: class sample { ... }
Note: this does work on case insensitive file systems only.
I really can't see any reason for maintaining the Worse is better
principle here, I really doubt that there is much code around relying on
the tolowercase feature/bug of spl_autoload().
As a compromise I propose the following:
1) spl_autoload() additionally tries to find a file _not_ lowercased.
2) Throw a E_DEPRECATED in case the filename had to be lowercased to
match.
Until then:
I really don't know why this lowercasing thing was introduced into
slp_autoload() to begin with, all it ever did was preventing classes to
be named with upper case letters on file systems which are case
sensitive. In other words: the only compatibility issue is that code
which currently works on platforms like Windows only would suddenly work
on UN*X like platforms too.
Pls confirm if this is the compatibility issue you are talking about.
Previous Comments:
[2009-09-22 16:22:22] sjo...@php.net
Thank you for your bug report.
Wontfix means: we agree that there is a bug, but there are reasons not
to fix it. The reason here is that is spl_autoload becomes case
sensitive, it will break scripts which depend on spl_autoload being case
insensitive.
[2009-09-22 16:01:15] jo at feuersee dot de
Description:
This is basically the same as PHP bug #48129.
Yes, I have read it won't fix
My opinion on this is won't fix is not an option because it _is_ a
bug and not fixing bugs does not work:
1) It is common practice in OO languages (including PHP) to give
classes case sensitive names. Even the classes of PHP itself are case
sensitive and usually start with capital letters (eg. DateTime,
Exception, ...). PHP related projects like PEAR, Zend Framework etc. do
the same.
2) In order to get a proper 1:1 mapping from class name to the file
containing the PHP class definition, projects like PEAR or Zend
Framework use the case sensitive class name, eg. System.php contains the
class System. Again, this is common practice in other OO languages like
C++.
3) What happens when the file system is case sensitive?
See example: the script fails because the PEAR class System will be
looked for in a file named system.php which does not exist because it is
called System.php
The workaround is using SPL_autoload_suxx instead. But look at the
code: there are several compatibility issues (include_path separator :
vs. ;), it does work but is not at all convenient.
4) What would happen if spl_autoload() wouldn't lowercase the class
name when looking for a class definition?
a) Filesystem is case sensitive
It would work!
The spl_autoload() would look for
#49615 [Bgs]: Problems with oci_pconnect()
ID: 49615 User updated by: bruno at uniconsult dot com dot br Reported By: bruno at uniconsult dot com dot br Status: Bogus Bug Type: OCI8 related Operating System: linux PHP Version: 5.2.11 New Comment: Thanks for the reply, I will update the versions and make some tests Previous Comments: [2009-09-21 22:23:04] s...@php.net Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to Open. Again, thank you for your continued support of PHP. --- Please try OCI8 1.3. This is included in PHP 5.3, and is available in PECL for older versions of PHP: http://pecl.php.net/oci8. The connection logic was substantially changed. It also detects and recovers from dead connections better. [2009-09-21 19:43:53] bruno at uniconsult dot com dot br Description: I got some problems with an application using persistent connections. When calling the oci_pconnect() function, if for any reason i got no response from the database, the PHP script keeps waiting and there is not a way to timeout it. In a unix shell script this can be solved using alarms and signals. Is there some oci8 approach to handle connections timeouts? Important, my problem is not in closing the connection in database, is to get some response when oci_pconnect() get no response and a way to handle it. I made a shell script to trace the execution stack and I noticed that the last call 'hangs': #0 0x00335370b222 in __read_nocancel () from /lib64/tls/libpthread.so.0 #1 0x002a97cc283e in snttread () #2 0x002a97cc25f9 in nttfprd () #3 0x002a97cba86e in nsbasic_brc () #4 0x002a97cbd6d1 in nsbrecv () #5 0x002a97cac4fd in nioqrc () #6 0x002a97ce7642 in ttcdrv () #7 0x002a97cb310d in nioqwa () #8 0x002a97c9976b in upirtrc () #9 0x002a963d8349 in upirtr () #10 0x002a9645e369 in upiver () #11 0x002a96ddaa80 in kpuvers () #12 0x002a96cce2cb in OCIServerVersion () #13 0x002a958ff12a in php_oci_do_connect_ex () #14 0x002a958ff580 in php_oci_do_connect () #15 0x002a9590a2e6 in zif_oci_pconnect () #16 ... -- Edit this bug report at http://bugs.php.net/?id=49615edit=1
#27051 [NoF-Asn]: Impersonation with FastCGI does not EXEC process as impersonated user
ID: 27051 Updated by: paj...@php.net Reported By: ghoffer at globalscape dot com -Status: No Feedback +Status: Assigned Bug Type: Feature/Change Request Operating System: Windows PHP Version: 5.3 Assigned To: pajoye New Comment: Stupid auto no feedback. Previous Comments: [2009-09-16 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-08 17:58:55] paj...@php.net Just a quick note about the user profile, it is not set (by design) so I won't try to access the profile data. More on the impersonated problem later. [2009-09-07 22:42:29] benadler at gmx dot net I checked using Process Monitor - convert.exe is NOT started by the correct user: User: NT AUTHORITY\NETWORK SERVICE Auth ID: :03e4 [2009-09-07 11:34:10] paj...@php.net I'm not sure the users environment is set, that's a different thing. But is it the correct user? [2009-09-07 11:17:13] benadler at gmx dot net Hope I'm not too verbose. Maybe it helps to see that calling this exec(d:/programme/imagemagick/convert.exe -density $density $baseDirectory/$bookId/document.pdf -quality 95 $baseDirectory/$bookId/$version/page_%04d.jpg, $output); print_r($output); in a script run by the webserver (as above) causes this: Array ( [0] = Error: /invalidfileaccess in --showpage-- [1] = Operand stack: [2] =--nostringval-- 1 true [3] = Execution stack: [4] =%interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1905 1 3 %oparray_pop 1904 1 3 %oparray_pop 1888 1 3 %oparray_pop --nostringval-- --nostringval-- 2 1 4 --nostringval-- %for_pos_int_continue --nostringval-- --nostringval-- 1777 1 9 %oparray_pop --nostringval-- --nostringval-- [5] = Dictionary stack: [6] =--dict:1155/1684(ro)(G)-- --dict:1/20(G)-- --dict:75/200(L)-- --dict:75/200(L)-- --dict:106/127(ro)(G)-- --dict:275/300(ro)(G)-- --dict:22/25(L)-- --dict:4/6(L)-- --dict:22/40(L)-- [7] = Current allocation mode is local [8] = Last OS error: Bad file descriptor ) 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/27051 -- Edit this bug report at http://bugs.php.net/?id=27051edit=1
#27051 [Asn-Fbk]: Impersonation with FastCGI does not EXEC process as impersonated user
ID: 27051 Updated by: paj...@php.net Reported By: ghoffer at globalscape dot com -Status: Assigned +Status: Feedback -Bug Type: Feature/Change Request +Bug Type: CGI related Operating System: Windows PHP Version: 5.3 Assigned To: pajoye New Comment: Please tell me how you setup FCGI, I did test it under FCGI with impersonate set and the cmd are actually called using the impersonated user. Can you try again using a recent snapshot to be sure that we use the same bins? Previous Comments: [2009-09-22 20:04:57] paj...@php.net Stupid auto no feedback. [2009-09-16 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-08 17:58:55] paj...@php.net Just a quick note about the user profile, it is not set (by design) so I won't try to access the profile data. More on the impersonated problem later. [2009-09-07 22:42:29] benadler at gmx dot net I checked using Process Monitor - convert.exe is NOT started by the correct user: User: NT AUTHORITY\NETWORK SERVICE Auth ID: :03e4 [2009-09-07 11:34:10] paj...@php.net I'm not sure the users environment is set, that's a different thing. But is it the correct user? 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/27051 -- Edit this bug report at http://bugs.php.net/?id=27051edit=1
#49632 [NEW]: xmlrpc_decode result crushes on value assignment
From: m dot kurzyna at crystalpoint dot pl
Operating system: Linux x86_64
PHP version: 5.3.0
PHP Bug Type: XMLRPC-EPI related
Bug description: xmlrpc_decode result crushes on value assignment
Description:
On decoding value with xmlrpc_decode() it will hang/crash PHP process when
trying to assign result value.
This will work fine:
xmlrpc_decode('...','utf-8');
While this:
$r = xmlrpc_decode('...','utf-8');
Will hang/crash.
This only happens on x86_64 systems - 32bit works fine.
Relevant part of the backtrace seems to be:
#24 0x7fffeb297271 in XML_ParseBuffer () from
/usr/lib64/libexpat.so.0
#25 0x7fffeb4c329a in xml_elem_parse_buf () from
/usr/lib64/libxmlrpc.so.0
#26 0x7fffeb4c74e9 in XMLRPC_REQUEST_FromXML () from
/usr/lib64/libxmlrpc.so.0
#27 0x7fffeb6d3523 in decode_request_worker (xml_in=0x7637ee60
\2, xml_in_len=128, encoding_in=value optimized out,
method_name_out=0x) at
/usr/src/debug/php-5.3.0/ext/xmlrpc/xmlrpc-epi-php.c:764
#28 0x7fffeb6d3630 in zif_xmlrpc_decode (ht=value optimized out,
return_value=0x86e5e0, return_value_ptr=value optimized out,
this_ptr=value optimized out, return_value_used=1, tsrm_ls=0x606ce0)
at /usr/src/debug/php-5.3.0/ext/xmlrpc/xmlrpc-epi-php.c:821
I will provide full trace if needed.
Reproduce code:
---
?php
$v = xmlrpc_decode(
'?xml version=1.0?
methodResponse
params
param
value
string1/string
/value
/param
/params
/methodResponse','utf-8');
echo OK\n;
?
Expected result:
OK
Actual result:
--
*** glibc detected *** /usr/bin/php: free(): invalid next size (fast):
0x008a7540 ***
--
Edit bug report at http://bugs.php.net/?id=49632edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49632r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49632r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49632r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49632r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49632r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49632r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49632r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49632r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49632r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49632r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49632r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49632r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49632r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49632r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49632r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49632r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49632r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49632r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49632r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49632r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49632r=mysqlcfg
#49632 [Opn-Fbk]: xmlrpc_decode result crashes on value assignment
ID: 49632
Updated by: j...@php.net
-Summary: xmlrpc_decode result crushes on value assignment
Reported By: m dot kurzyna at crystalpoint dot pl
-Status: Open
+Status: Feedback
Bug Type: XMLRPC-EPI related
Operating System: Linux x86_64
PHP Version: 5.3.0
New Comment:
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
I can not reproduce this. Also make sure you're not loading any zend
extensions..
Previous Comments:
[2009-09-22 20:23:20] m dot kurzyna at crystalpoint dot pl
Description:
On decoding value with xmlrpc_decode() it will hang/crash PHP process
when trying to assign result value.
This will work fine:
xmlrpc_decode('...','utf-8');
While this:
$r = xmlrpc_decode('...','utf-8');
Will hang/crash.
This only happens on x86_64 systems - 32bit works fine.
Relevant part of the backtrace seems to be:
#24 0x7fffeb297271 in XML_ParseBuffer () from
/usr/lib64/libexpat.so.0
#25 0x7fffeb4c329a in xml_elem_parse_buf () from
/usr/lib64/libxmlrpc.so.0
#26 0x7fffeb4c74e9 in XMLRPC_REQUEST_FromXML () from
/usr/lib64/libxmlrpc.so.0
#27 0x7fffeb6d3523 in decode_request_worker (xml_in=0x7637ee60
\2, xml_in_len=128, encoding_in=value optimized out,
method_name_out=0x) at
/usr/src/debug/php-5.3.0/ext/xmlrpc/xmlrpc-epi-php.c:764
#28 0x7fffeb6d3630 in zif_xmlrpc_decode (ht=value optimized out,
return_value=0x86e5e0, return_value_ptr=value optimized out,
this_ptr=value optimized out, return_value_used=1, tsrm_ls=0x606ce0)
at /usr/src/debug/php-5.3.0/ext/xmlrpc/xmlrpc-epi-php.c:821
I will provide full trace if needed.
Reproduce code:
---
?php
$v = xmlrpc_decode(
'?xml version=1.0?
methodResponse
params
param
value
string1/string
/value
/param
/params
/methodResponse','utf-8');
echo OK\n;
?
Expected result:
OK
Actual result:
--
*** glibc detected *** /usr/bin/php: free(): invalid next size (fast):
0x008a7540 ***
--
Edit this bug report at http://bugs.php.net/?id=49632edit=1
#49623 [Opn-Bgs]: PHP shows deprecation warning BEFORE compressed body
ID: 49623
Updated by: j...@php.net
Reported By: 3 at 14 dot by
-Status: Open
+Status: Bogus
Bug Type: Output Control
Operating System: 2.6.28-15-generic #49-Ubuntu SMP
PHP Version: 5.3.0
New Comment:
That's quite expected and unfixable.
Previous Comments:
[2009-09-22 16:18:31] sjo...@php.net
Thank you for your bug report.
That PHP shows a warning even though error reporting is disabled sounds
like bug #49362, Deprecated php.ini options warnings output even with
display_errors=off.
[2009-09-22 16:11:25] 3 at 14 dot by
typo
[2009-09-22 13:32:23] 3 at 14 dot by
Description:
I have set Error_Reporting(0) both in the script in the php.ini.
I have an PHPBB forum (3.0.6) with zlib compression turned on.
Most of the warnings are gone, but in some cases (when some data is
sent via POST), I am still getting a Notice bdate(): It is not safe
to rely on the system's timezone settings., and it is printed BEFORE
compressed page body, so that browser reports broken encoding.
After disabling zlib compression browser started to show notice and
page content. After setting date.timezone in php.ini Notice is gone.
Reproduce code:
---
Install PHPBB 3.0.6: turn zlib compression = on, make sure to unset
date.timezone in php.ini. Then try to reply to a private message.
Expected result:
No notices on the screen, no broken encoding
Actual result:
--
HTTP/1.1 200 OK
Server: nginx
Date: Tue, 22 Sep 2009 13:09:15 GMT
Content-Type: text/html; charset=UTF-8
Connection: close
Expires: 0
Last-Modified: Tue, 22 Sep 2009 13:09:15 GMT
Cache-Control: private, no-cache=set-cookie
Pragma: no-cache
Content-Encoding: gzip
Vary: Accept-Encoding
Content-Length: 3181
b[phpBB Debug] PHP Notice/b: in file
b/includes/functions_messenger.php/b on line b390/b: bdate():
It is not safe to rely on the system's timezone settings. You are
*required* to use the date.timezone setting or the
date_default_timezone_set() function. In case you used any of those
methods and you are still getting this warning, you most likely
misspelled the timezone identifier. We selected 'Europe/Moscow' for
'MSD/4.0/DST' instead/bbr /
.n.8...
V.I[[..\j[..4.)..l.@iu
.Cv_...%{.)..%i.S#.E...d9.t,..w./.3..o../H..O.u._9...N..;^[fSw..{.T:.V...i.:tF..ar..Dy[.t.yb.s...h2.h8j6.1..
2.,.-.H.C...hv.]d2 AD3...n|.:v.;[here goes the rest of
the compressed page]
--
Edit this bug report at http://bugs.php.net/?id=49623edit=1
#49627 [Opn-Asn]: error_log to specified file does not log time according to date.timezone
ID: 49627
Updated by: j...@php.net
Reported By: mp at icomme dot fr
-Status: Open
+Status: Assigned
Bug Type: Date/time related
Operating System: FreeBSD 7.2
PHP Version: 5.2.11
-Assigned To:
+Assigned To: dmitry
New Comment:
This was fixed in bug #45191 but that fix caused crashes in certain
cases (f.e. bug #48247) and was essentially reverted it seems. Now I
can
not reproduce that crash bug anymore even when I revert my change.
Dmitry, how did you make it crash again? :)
Previous Comments:
[2009-09-22 17:16:04] mp at icomme dot fr
Description:
When php.ini is configured with error_log to a specified file (not
via syslog), PHP does not log date and time of records (errors,
warnings, etc.) according to the date.timezone configured in php.ini,
it's always recorded with GMT time.
PHP (5.2.6) used to work correctly with this.
OS and PHP have correct time zone :
$ date
Tue Sep 22 19:05:32 CEST 2009
... time on OS is correctly configured : CEST = GMT+2
print date('r T');
print gmdate('r T');
... respectivly returns :
Tue, 22 Sep 2009 19:06:12 +0200 CEST
Tue, 22 Sep 2009 17:06:12 + GMT
... PHP correctly configured
Box :
FreeBSD 7.2-RELEASE (GENERIC)
Apache/2.2.13 (Unix)
PHP 5.2.11
Someone says (bug 45191) this bug has been fixed in CVS on May 2009,
but 2 versions of the 5.2 branch had been released since this date, and
the bug is still present.
Reproduce code:
---
# php.ini :
; Log errors to specified file.
error_log = /var/log/php/php-error.log
; Defines the default timezone used by the date functions
date.timezone = Europe/Paris
# test.php :
nonexistantfunction();
Expected result:
[22-Sep-2009 18:57:55] PHP Fatal error: Call to undefined function
nonexistantfunction() in /usr/home/michel/public_html/plante.php on line
9
Actual result:
--
[22-Sep-2009 16:57:55] PHP Fatal error: Call to undefined function
nonexistantfunction() in /usr/home/michel/public_html/plante.php on line
9
--
Edit this bug report at http://bugs.php.net/?id=49627edit=1
#49632 [Fbk-Opn]: xmlrpc_decode result crashes on value assignment
ID: 49632
User updated by: m dot kurzyna at crystalpoint dot pl
Reported By: m dot kurzyna at crystalpoint dot pl
-Status: Feedback
+Status: Open
Bug Type: XMLRPC-EPI related
Operating System: Linux x86_64
PHP Version: 5.3.0
New Comment:
Unfortunatly i can reproduce it every time even on bare setup:
[r...@apache-php53 bugs]# php -m
[PHP Modules]
Core
date
ereg
libxml
mysqlnd
pcre
Reflection
session
SPL
standard
xmlrpc
[Zend Modules]
[r...@apache-php53 bugs]# php xmlrpc_decode.php
*** glibc detected *** php: free(): invalid next size (fast):
0x0079fbd0 ***
And then backtrace follows, see: http://pastebin.com/f5ed2df2d for full
output.
Previous Comments:
[2009-09-22 20:32:11] j...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
I can not reproduce this. Also make sure you're not loading any zend
extensions..
[2009-09-22 20:23:20] m dot kurzyna at crystalpoint dot pl
Description:
On decoding value with xmlrpc_decode() it will hang/crash PHP process
when trying to assign result value.
This will work fine:
xmlrpc_decode('...','utf-8');
While this:
$r = xmlrpc_decode('...','utf-8');
Will hang/crash.
This only happens on x86_64 systems - 32bit works fine.
Relevant part of the backtrace seems to be:
#24 0x7fffeb297271 in XML_ParseBuffer () from
/usr/lib64/libexpat.so.0
#25 0x7fffeb4c329a in xml_elem_parse_buf () from
/usr/lib64/libxmlrpc.so.0
#26 0x7fffeb4c74e9 in XMLRPC_REQUEST_FromXML () from
/usr/lib64/libxmlrpc.so.0
#27 0x7fffeb6d3523 in decode_request_worker (xml_in=0x7637ee60
\2, xml_in_len=128, encoding_in=value optimized out,
method_name_out=0x) at
/usr/src/debug/php-5.3.0/ext/xmlrpc/xmlrpc-epi-php.c:764
#28 0x7fffeb6d3630 in zif_xmlrpc_decode (ht=value optimized out,
return_value=0x86e5e0, return_value_ptr=value optimized out,
this_ptr=value optimized out, return_value_used=1, tsrm_ls=0x606ce0)
at /usr/src/debug/php-5.3.0/ext/xmlrpc/xmlrpc-epi-php.c:821
I will provide full trace if needed.
Reproduce code:
---
?php
$v = xmlrpc_decode(
'?xml version=1.0?
methodResponse
params
param
value
string1/string
/value
/param
/params
/methodResponse','utf-8');
echo OK\n;
?
Expected result:
OK
Actual result:
--
*** glibc detected *** /usr/bin/php: free(): invalid next size (fast):
0x008a7540 ***
--
Edit this bug report at http://bugs.php.net/?id=49632edit=1
#49478 [Fbk-Opn]: shell_exec does not work
ID: 49478
User updated by: elmue at gmx dot de
Reported By: elmue at gmx dot de
-Status: Feedback
+Status: Open
Bug Type: Program Execution
Operating System: Windows
PHP Version: 6SVN-2009-09-06 (snap)
Assigned To: pajoye
New Comment:
Yes you are right.
In the build from 22.sep.2009 this bug is fixed.
Previous Comments:
[2009-09-22 14:06:54] paj...@php.net
Try with a recent snap please
[2009-09-22 14:06:37] paj...@php.net
Windows, today snaps.
[2009-09-22 13:46:42] elmue at gmx dot de
Hello
On which PHP6 version did you test it ?
Did you test on Windows ?
I used version build Sep 3 2009 21:23:55
[2009-09-22 08:41:40] paj...@php.net
I can't reproduce it with php6 neither with 5.3 or 5.2 in CLI or FCGI.
Can you try it with CLI/CGI too please?
[2009-09-22 05:18:15] ian at iglou dot com
Also broken in PHP Version 5.2.10; safe mode off.
An earlier version (no record of which) did work when used thus to get
a Windows dvd volume label:
if (preg_match('#Volume in drive [a-zA-Z]* is (.*)\n#i',
shell_exec('dir '.$drive.':'), $m)) {
$volname = ' ('.$m[1].')';
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/49478
--
Edit this bug report at http://bugs.php.net/?id=49478edit=1
#49478 [Opn-Csd]: shell_exec does not work
ID: 49478 Updated by: paj...@php.net Reported By: elmue at gmx dot de -Status: Open +Status: Closed Bug Type: Program Execution Operating System: Windows PHP Version: 6SVN-2009-09-06 (snap) Assigned To: pajoye 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: [2009-09-22 20:54:32] elmue at gmx dot de Yes you are right. In the build from 22.sep.2009 this bug is fixed. [2009-09-22 14:06:54] paj...@php.net Try with a recent snap please [2009-09-22 14:06:37] paj...@php.net Windows, today snaps. [2009-09-22 13:46:42] elmue at gmx dot de Hello On which PHP6 version did you test it ? Did you test on Windows ? I used version build Sep 3 2009 21:23:55 [2009-09-22 08:41:40] paj...@php.net I can't reproduce it with php6 neither with 5.3 or 5.2 in CLI or FCGI. Can you try it with CLI/CGI too please? 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/49478 -- Edit this bug report at http://bugs.php.net/?id=49478edit=1
#49476 [Com]: $_ENV does not work
ID: 49476 Comment by: elmue at gmx dot de Reported By: elmu at gmx dot de Status: Open Bug Type: Variables related Operating System: Windows PHP Version: 6SVN-2009-09-05 (snap) New Comment: I repeated the test on build from 22 sep 2009 and the result is the same $_ENV[OS] $_ENV[PROCESSOR_IDENTIFIER] $_ENV[COMPUTERNAME] are empty. Even a print_r($_ENV) shows: Array ( ) This cannot be caused by input encoding because these variables have no special characters in them. On PHP5 the same array has plenty content! Previous Comments: [2009-09-06 20:31:59] paj...@php.net ENV works just fine here. But there are changes about input encoding that have not been test at all. And all in all, the current status of php6 is not tested at all, unstable and needs heavy work to get to something usable (usable != stable). [2009-09-06 19:48:16] elmu at gmx dot de Note: It seems that the current PHP 6 has not yet been tested on Windows. All the bugs I found are related to filesystem or operation system. [2009-09-05 23:57:06] elmu at gmx dot de Sorry I wanted to say $_SERVER[SERVER_SIGNATURE] works on both. [2009-09-05 23:52:42] elmu at gmx dot de Description: $_ENV[OS] $_ENV[PROCESSOR_IDENTIFIER] $_ENV[COMPUTERNAME] are empty on PHP 6 VC6 while the same code works fine on PHP 5, while $_ENV[SERVER_SIGNATURE] works on both PHP 5 and PHP 6. On the other hand the missing values appear correctly in phpinfo() Strange. -- Edit this bug report at http://bugs.php.net/?id=49476edit=1
#49017 [Opn-Bgs]: PDO::FETCH_ORI_REL not working
ID: 49017 Updated by: sjo...@php.net Reported By: farkasmate_ at freemail dot hu -Status: Open +Status: Bogus Bug Type: PDO related Operating System: win XP sp2 PHP Version: 5.3.0 New Comment: Thank you for your bug report. Unfortunately, MySQL does not support scrollable cursors. See also: Bug #39310 PDO Scrolling cursors not available for Sqlite and don't work for Mysql Bug #34625 Scrollable cursor doesn't work with MySQL Previous Comments: [2009-07-22 14:25:39] farkasmate_ at freemail dot hu Description: pdo mysql error. PDO::FETCH_ORI_REL not working sql result about 1000 rows. I need to catch 555. row item but i get always first row (0.) of result. Reproduce code: --- $this-db_conn = new PDO(mysql:host=$db;dbname=mysql;EnableScrollableCursors=1,$db_username,$db_password);//connect mysql $sql = select * from tablename; $this-db_conn-setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_SILENT); //$stmt = $this-db_conn-query($sql) or die(ERROR: . implode(:, $this-db_conn-errorInfo())); $stmt = $this-db_conn-prepare($sql, array( PDO::ATTR_CURSOR = PDO::CURSOR_SCROLL )); $stmt-execute(); $search_row = 555; $row = $stmt-fetch(PDO::FETCH_NUM , PDO::FETCH_ORI_REL, $search_row ); var_dump($row); Expected result: catch 555. row Actual result: -- catch first row -- Edit this bug report at http://bugs.php.net/?id=49017edit=1
#44639 [Opn]: PDO quotes integers in prepared statement
ID: 44639
Updated by: sjo...@php.net
Reported By: jgauld at blueyonder dot co dot uk
Status: Open
Bug Type: PDO related
Operating System: WinXP
PHP Version: 5.2.10
New Comment:
The third parameter to bindValue defaults to PDO::PARAM_STR. This is
different than the original bug reporter said, so it must be changed in
the meantime. Because the datatype is PDO::PARAM_STR, the int is cast to
a string and quoted.
It would make sense to use the PHP type to determine the most logical
PDO::PARAM_* type. See also bug #44597, which is essentially the same
problem but with booleans and execute() instead of bindValue().
Previous Comments:
[2009-08-17 17:38:15] j...@php.net
But you didn't bother updating the version field. Done now..
[2009-07-21 00:30:49] whistl0r+php at googlemail dot com
Hi,
this bug is still present in the current PHP version.
Tested with PHP 5.2.10 stable and snapshot on Windows.
MySQL client api: 5.1.35
[2008-10-21 11:59:03] jgauld at blueyonder dot co dot uk
Tried windows snapshot as suggested (5.2.7RC2-dev), but no joy. Result
is same, ie:
select * from my_table where id'13'
If it helps, phpinfo() reports:
PDO Driver for MySQL, client library version5.0.51a
[2008-07-03 15:17:35] u...@php.net
This is not a driver issue. Its the PDO SQL driver messing up SQL
statements.
[2008-06-12 13:42:35] dobamail at gmail dot com
Hi.
PDO::MySQL
The code:
$stmt = $db-prepare('
SELECT id, hu_name, ord
FROMproducts
ORDER BY ord DESC, hu_name
LIMIT :offset, :limit
');
$stmt-bindValue(':offset', ($offset*$limit));
$stmt-bindValue(':limit', $limit);
$stmt-execute();
It is work on:
- PHP Version 5.2.0-8+etch11;
- PDO Driver for MySQL, client library version 5.0.32
- MySQL version: 5.0.32-Debian_7etch5-log
Not work on:
- PHP Version 5.2.3-1ubuntu6.3
- PDO Driver for MySQL, client library version 5.0.45
- 5.0.45-Debian_1ubuntu3.3
I hope this help you.
Best regards.
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/44639
--
Edit this bug report at http://bugs.php.net/?id=44639edit=1
#49632 [Opn-Csd]: xmlrpc_decode result crashes on value assignment
ID: 49632
User updated by: m dot kurzyna at crystalpoint dot pl
Reported By: m dot kurzyna at crystalpoint dot pl
-Status: Open
+Status: Closed
Bug Type: XMLRPC-EPI related
Operating System: Linux x86_64
PHP Version: 5.3.0
New Comment:
I've just built current snap (2009.09.22 20:30) and it seems to work
fine so it would seem that it's fixed in SVN.
Thanks.
Previous Comments:
[2009-09-22 20:50:46] m dot kurzyna at crystalpoint dot pl
Unfortunatly i can reproduce it every time even on bare setup:
[r...@apache-php53 bugs]# php -m
[PHP Modules]
Core
date
ereg
libxml
mysqlnd
pcre
Reflection
session
SPL
standard
xmlrpc
[Zend Modules]
[r...@apache-php53 bugs]# php xmlrpc_decode.php
*** glibc detected *** php: free(): invalid next size (fast):
0x0079fbd0 ***
And then backtrace follows, see: http://pastebin.com/f5ed2df2d for full
output.
[2009-09-22 20:32:11] j...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
I can not reproduce this. Also make sure you're not loading any zend
extensions..
[2009-09-22 20:23:20] m dot kurzyna at crystalpoint dot pl
Description:
On decoding value with xmlrpc_decode() it will hang/crash PHP process
when trying to assign result value.
This will work fine:
xmlrpc_decode('...','utf-8');
While this:
$r = xmlrpc_decode('...','utf-8');
Will hang/crash.
This only happens on x86_64 systems - 32bit works fine.
Relevant part of the backtrace seems to be:
#24 0x7fffeb297271 in XML_ParseBuffer () from
/usr/lib64/libexpat.so.0
#25 0x7fffeb4c329a in xml_elem_parse_buf () from
/usr/lib64/libxmlrpc.so.0
#26 0x7fffeb4c74e9 in XMLRPC_REQUEST_FromXML () from
/usr/lib64/libxmlrpc.so.0
#27 0x7fffeb6d3523 in decode_request_worker (xml_in=0x7637ee60
\2, xml_in_len=128, encoding_in=value optimized out,
method_name_out=0x) at
/usr/src/debug/php-5.3.0/ext/xmlrpc/xmlrpc-epi-php.c:764
#28 0x7fffeb6d3630 in zif_xmlrpc_decode (ht=value optimized out,
return_value=0x86e5e0, return_value_ptr=value optimized out,
this_ptr=value optimized out, return_value_used=1, tsrm_ls=0x606ce0)
at /usr/src/debug/php-5.3.0/ext/xmlrpc/xmlrpc-epi-php.c:821
I will provide full trace if needed.
Reproduce code:
---
?php
$v = xmlrpc_decode(
'?xml version=1.0?
methodResponse
params
param
value
string1/string
/value
/param
/params
/methodResponse','utf-8');
echo OK\n;
?
Expected result:
OK
Actual result:
--
*** glibc detected *** /usr/bin/php: free(): invalid next size (fast):
0x008a7540 ***
--
Edit this bug report at http://bugs.php.net/?id=49632edit=1
#49476 [Com]: $_ENV does not work
ID: 49476 Comment by: elmue at gmx dot de Reported By: elmu at gmx dot de Status: Open Bug Type: Variables related Operating System: Windows PHP Version: 6SVN-2009-09-05 (snap) New Comment: Hello In version 22 sep 2009 it is even worse: print_r($_FILES); throws: Failed to decode _FILES array The last time I tested on PHP6 this did work. Now its broken. Previous Comments: [2009-09-22 21:03:52] elmue at gmx dot de I repeated the test on build from 22 sep 2009 and the result is the same $_ENV[OS] $_ENV[PROCESSOR_IDENTIFIER] $_ENV[COMPUTERNAME] are empty. Even a print_r($_ENV) shows: Array ( ) This cannot be caused by input encoding because these variables have no special characters in them. On PHP5 the same array has plenty content! [2009-09-06 20:31:59] paj...@php.net ENV works just fine here. But there are changes about input encoding that have not been test at all. And all in all, the current status of php6 is not tested at all, unstable and needs heavy work to get to something usable (usable != stable). [2009-09-06 19:48:16] elmu at gmx dot de Note: It seems that the current PHP 6 has not yet been tested on Windows. All the bugs I found are related to filesystem or operation system. [2009-09-05 23:57:06] elmu at gmx dot de Sorry I wanted to say $_SERVER[SERVER_SIGNATURE] works on both. [2009-09-05 23:52:42] elmu at gmx dot de Description: $_ENV[OS] $_ENV[PROCESSOR_IDENTIFIER] $_ENV[COMPUTERNAME] are empty on PHP 6 VC6 while the same code works fine on PHP 5, while $_ENV[SERVER_SIGNATURE] works on both PHP 5 and PHP 6. On the other hand the missing values appear correctly in phpinfo() Strange. -- Edit this bug report at http://bugs.php.net/?id=49476edit=1
#49633 [NEW]: $_FILES cannot be accessed
From: elmue at gmx dot de Operating system: Windows PHP version: 6SVN-2009-09-22 (snap) PHP Bug Type: Variables related Bug description: $_FILES cannot be accessed Description: In version 22 sep 2009: print_r($_FILES); throws: Failed to decode _FILES array and Could not convert binary string to Unicode string (converter UTF-8 failed on bytes (0xF3) at offset 60) But there is no character F3 in the filename! -- Edit bug report at http://bugs.php.net/?id=49633edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49633r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49633r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49633r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49633r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49633r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49633r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49633r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49633r=needscript Try newer version: http://bugs.php.net/fix.php?id=49633r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49633r=support Expected behavior: http://bugs.php.net/fix.php?id=49633r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49633r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49633r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49633r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49633r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49633r=dst IIS Stability: http://bugs.php.net/fix.php?id=49633r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49633r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49633r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49633r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49633r=mysqlcfg
#49623 [Bgs]: PHP shows deprecation warning BEFORE compressed body
ID: 49623
User updated by: 3 at 14 dot by
Reported By: 3 at 14 dot by
Status: Bogus
Bug Type: Output Control
Operating System: 2.6.28-15-generic #49-Ubuntu SMP
PHP Version: 5.3.0
New Comment:
Is it possible at least to show a warning in the compressed part, not
before so that browsers would behave much nicer?
It is really confusing, and if one have no idea how to sniff HTTP
traffic, it might eat huge amount of time to figure out the cause.
Previous Comments:
[2009-09-22 20:34:31] j...@php.net
That's quite expected and unfixable.
[2009-09-22 16:18:31] sjo...@php.net
Thank you for your bug report.
That PHP shows a warning even though error reporting is disabled sounds
like bug #49362, Deprecated php.ini options warnings output even with
display_errors=off.
[2009-09-22 16:11:25] 3 at 14 dot by
typo
[2009-09-22 13:32:23] 3 at 14 dot by
Description:
I have set Error_Reporting(0) both in the script in the php.ini.
I have an PHPBB forum (3.0.6) with zlib compression turned on.
Most of the warnings are gone, but in some cases (when some data is
sent via POST), I am still getting a Notice bdate(): It is not safe
to rely on the system's timezone settings., and it is printed BEFORE
compressed page body, so that browser reports broken encoding.
After disabling zlib compression browser started to show notice and
page content. After setting date.timezone in php.ini Notice is gone.
Reproduce code:
---
Install PHPBB 3.0.6: turn zlib compression = on, make sure to unset
date.timezone in php.ini. Then try to reply to a private message.
Expected result:
No notices on the screen, no broken encoding
Actual result:
--
HTTP/1.1 200 OK
Server: nginx
Date: Tue, 22 Sep 2009 13:09:15 GMT
Content-Type: text/html; charset=UTF-8
Connection: close
Expires: 0
Last-Modified: Tue, 22 Sep 2009 13:09:15 GMT
Cache-Control: private, no-cache=set-cookie
Pragma: no-cache
Content-Encoding: gzip
Vary: Accept-Encoding
Content-Length: 3181
b[phpBB Debug] PHP Notice/b: in file
b/includes/functions_messenger.php/b on line b390/b: bdate():
It is not safe to rely on the system's timezone settings. You are
*required* to use the date.timezone setting or the
date_default_timezone_set() function. In case you used any of those
methods and you are still getting this warning, you most likely
misspelled the timezone identifier. We selected 'Europe/Moscow' for
'MSD/4.0/DST' instead/bbr /
.n.8...
V.I[[..\j[..4.)..l.@iu
.Cv_...%{.)..%i.S#.E...d9.t,..w./.3..o../H..O.u._9...N..;^[fSw..{.T:.V...i.:tF..ar..Dy[.t.yb.s...h2.h8j6.1..
2.,.-.H.C...hv.]d2 AD3...n|.:v.;[here goes the rest of
the compressed page]
--
Edit this bug report at http://bugs.php.net/?id=49623edit=1
#49634 [NEW]: Segfault throwing an exception in a XSL registered function
From: aldo at armiento dot com
Operating system: Linux Debian, Mac OSX
PHP version: 5.3.0
PHP Bug Type: Reproducible crash
Bug description: Segfault throwing an exception in a XSL registered function
Description:
Segfault throwing an exception in an XSL registered function when try to
access node from an external document.
libxml2: 2.7.4
libxslt: 1.1.25
Reproduce code:
---
External document doc.xml:
root/
Script:
?php
$sXml = XML
?xml version=1.0 encoding=UTF-8 ?
root
test
/root
XML;
$sXsl = XSL
xsl:stylesheet version=1.0
xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
xmlns:ext=http://php.net/xsl;
xsl:extension-element-prefixes=ext
exclude-result-prefixes=ext
xsl:output encoding=UTF-8 indent=yes method=xml /
xsl:template match=/
xsl:value-of select=ext:function('testFunction',
document('doc.xml')/root)/
/xsl:template
/xsl:stylesheet
XSL;
function testFunction($a)
{
throw new Exception('Test exception.');
}
$domXml = DOMDocument::loadXML($sXml);
$domXsl = DOMDocument::loadXML($sXsl);
for ($i = 0; $i 10; $i++)
{
$xsltProcessor = new XSLTProcessor();
$xsltProcessor-registerPHPFunctions(array('testFunction'));
$xsltProcessor-importStyleSheet($domXsl);
try {
@$xsltProcessor-transformToDoc($domXml);
} catch (Exception $e) {
echo Exception!\n;
}
}
Expected result:
Exception!
Exception!
Exception!
Exception!
Exception!
Exception!
Exception!
Exception!
Exception!
Exception!
Actual result:
--
(gdb) r
Starting program: /home/armiento/env/spider/bin/php test_segfault.php
[Thread debugging using libthread_db enabled]
[New Thread 140442269927120 (LWP 3340)]
Exception!
Exception!
*** glibc detected *** free(): invalid pointer: 0x0137d0d0 ***
Program received signal SIGABRT, Aborted.
[Switching to Thread 140442269927120 (LWP 3340)]
0x7fbb423cb07b in raise () from /lib/libc.so.6
(gdb) bt
#0 0x7fbb423cb07b in raise () from /lib/libc.so.6
#1 0x7fbb423cc84e in abort () from /lib/libc.so.6
#2 0x7fbb424015f9 in __fsetlocking () from /lib/libc.so.6
#3 0x7fbb42408163 in mallopt () from /lib/libc.so.6
#4 0x7fbb424081ee in free () from /lib/libc.so.6
#5 0x0044f3ab in php_libxml_node_decrement_resource
(object=0x7fbb439a0710)
at /home/armiento/src/php-5.3.0/ext/libxml/libxml.c:1058
#6 0x004caed5 in dom_objects_free_storage
(object=0x7fbb439a0710) at /home/armiento/src/php-
5.3.0/ext/dom/php_dom.c:1017
#7 0x006bf026 in zend_objects_store_del_ref_by_handle_ex
(handle=3, handlers=value optimized out)
at /home/armiento/src/php-5.3.0/Zend/zend_objects_API.c:220
#8 0x006bf062 in zend_objects_store_del_ref
(zobject=0x7fbb4399e4f0)
at /home/armiento/src/php-5.3.0/Zend/zend_objects_API.c:172
#9 0x00692cc5 in _zval_ptr_dtor (zval_ptr=0x7fbb439a0e40) at
/home/armiento/src/php-5.3.0/Zend/zend_variables.h:35
#10 0x006aab88 in zend_hash_destroy (ht=0x7fbb439a0d80) at
/home/armiento/src/php-5.3.0/Zend/zend_hash.c:526
#11 0x0069ec36 in _zval_dtor_func (zvalue=0x7fbb439a0d50) at
/home/armiento/src/php-5.3.0/Zend/zend_variables.c:43
#12 0x00692cc5 in _zval_ptr_dtor (zval_ptr=0x7fbb439a0e98) at
/home/armiento/src/php-5.3.0/Zend/zend_variables.h:35
#13 0x006aab88 in zend_hash_destroy (ht=0x7fbb439a0ca8) at
/home/armiento/src/php-5.3.0/Zend/zend_hash.c:526
#14 0x0069ec36 in _zval_dtor_func (zvalue=0x7fbb439a0c78) at
/home/armiento/src/php-5.3.0/Zend/zend_variables.c:43
#15 0x00692cc5 in _zval_ptr_dtor (zval_ptr=0x7fbb439a0ef0) at
/home/armiento/src/php-5.3.0/Zend/zend_variables.h:35
#16 0x006aab88 in zend_hash_destroy (ht=0x7fbb439a0ba0) at
/home/armiento/src/php-5.3.0/Zend/zend_hash.c:526
#17 0x0069ec36 in _zval_dtor_func (zvalue=0x7fbb439a0b70) at
/home/armiento/src/php-5.3.0/Zend/zend_variables.c:43
#18 0x00692cc5 in _zval_ptr_dtor (zval_ptr=0x7fbb439a0f50) at
/home/armiento/src/php-5.3.0/Zend/zend_variables.h:35
#19 0x006aab88 in zend_hash_destroy (ht=0x7fbb439a0ac8) at
/home/armiento/src/php-5.3.0/Zend/zend_hash.c:526
#20 0x0069ec36 in _zval_dtor_func (zvalue=0x7fbb439a00f0) at
/home/armiento/src/php-5.3.0/Zend/zend_variables.c:43
#21 0x00692cc5 in _zval_ptr_dtor (zval_ptr=0x7fbb439a0a08) at
/home/armiento/src/php-5.3.0/Zend/zend_variables.h:35
#22 0x006aab88 in zend_hash_destroy (ht=0x7fbb439a0930) at
/home/armiento/src/php-5.3.0/Zend/zend_hash.c:526
#23 0x006bb989 in zend_object_std_dtor (object=0x7fbb439a0780)
at /home/armiento/src/php-5.3.0/Zend/zend_objects.c:45
#24 0x006bb9a9 in zend_objects_free_object_storage
(object=0xd0c) at /home/armiento/src/php-5.3.0/Zend/zend_objects.c:114
#25 0x006bf026 in
#49608 [Ver-Asn]: Using CachingIterator on DirectoryIterator instance segfaults
ID: 49608 Updated by: paj...@php.net Reported By: david at grudl dot com -Status: Verified +Status: Assigned Bug Type: SPL related Operating System: * PHP Version: 5.3SVN-2009-09-20 (snap) -Assigned To: +Assigned To: colder Previous Comments: [2009-09-20 14:59:56] paj...@php.net Pretty sure it is not a windows only bug either. [2009-09-20 14:59:09] paj...@php.net Backtrace: php5_debug.dll!zval_delref_p(_zval_struct * pz=0x) Line 385 + 0x3 bytes C php5_debug.dll!_zval_ptr_dtor(_zval_struct * * zval_ptr=0x00c1ebe4, char * __zend_filename=0x10563320, unsigned int __zend_lineno=1407) Line 429 + 0xb bytesC php5_debug.dll!spl_filesystem_dir_it_dtor(_zend_object_iterator * iter=0x02784d10) Line 1407 + 0x17 bytesC php5_debug.dll!spl_dual_it_free_storage(void * _object=0x02785080) Line 1920 + 0x16 bytes C php5_debug.dll!zend_objects_store_del_ref_by_handle_ex(unsigned int handle=2, const _zend_object_handlers * handlers=0x105a6e00) Line 220 + 0x10 bytes C php5_debug.dll!zend_objects_store_del_ref(_zval_struct * zobject=0x02783ad8) Line 172 + 0x10 bytes C php5_debug.dll!_zval_dtor_func(_zval_struct * zvalue=0x02783ad8, char * __zend_filename=0x104dea40, unsigned int __zend_lineno=435) Line 52 + 0x11 bytes C php5_debug.dll!_zval_dtor(_zval_struct * zvalue=0x02783ad8, char * __zend_filename=0x104dea40, unsigned int __zend_lineno=435) Line 35 + 0x11 bytes C php5_debug.dll!_zval_ptr_dtor(_zval_struct * * zval_ptr=0x027852a4, char * __zend_filename=0x104e3584, unsigned int __zend_lineno=175) Line 435 + 0x19 bytesC php5_debug.dll!_zval_ptr_dtor_wrapper(_zval_struct * * zval_ptr=0x027852a4) Line 175 + 0x17 bytes C php5_debug.dll!zend_hash_apply_deleter(_hashtable * ht=0x105c0b78, bucket * p=0x02785298) Line 611 + 0x11 bytes C php5_debug.dll!zend_hash_reverse_apply(_hashtable * ht=0x105c0b78, int (void *)* apply_func=0x10283570) Line 760 + 0xd bytes C php5_debug.dll!shutdown_destructors() Line 222 + 0xf bytes C php5_debug.dll!zend_call_destructors() Line 875C php5_debug.dll!php_request_shutdown(void * dummy=0x) Line 1547C php.exe!main(int argc=3, char * * argv=0x00ce1bf0) Line 1371 + 0xa bytes C php.exe!__tmainCRTStartup() Line 586 + 0x19 bytes C php.exe!mainCRTStartup() Line 403 C [2009-09-20 14:33:39] david at grudl dot com Description: This code crashes PHP 5.3.0 - 5.3.2-dev (VC9, TS) Reproduce code: --- $dir = new DirectoryIterator(__DIR__); $iterator = new CachingIterator($dir); foreach ($dir as $val); -- Edit this bug report at http://bugs.php.net/?id=49608edit=1
#49634 [Opn]: Segfault throwing an exception in a XSL registered function
ID: 49634
Updated by: fel...@php.net
Reported By: aldo at armiento dot com
Status: Open
Bug Type: Reproducible crash
Operating System: Linux Debian, Mac OSX
PHP Version: 5.3.0
New Comment:
I can't reproduce it on Debian 32bit.
libxslt 1.1.24-2 ; libxml2 2.6.32
Previous Comments:
[2009-09-22 22:41:49] aldo at armiento dot com
Description:
Segfault throwing an exception in an XSL registered function when try
to
access node from an external document.
libxml2: 2.7.4
libxslt: 1.1.25
Reproduce code:
---
External document doc.xml:
root/
Script:
?php
$sXml = XML
?xml version=1.0 encoding=UTF-8 ?
root
test
/root
XML;
$sXsl = XSL
xsl:stylesheet version=1.0
xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
xmlns:ext=http://php.net/xsl;
xsl:extension-element-prefixes=ext
exclude-result-prefixes=ext
xsl:output encoding=UTF-8 indent=yes method=xml /
xsl:template match=/
xsl:value-of select=ext:function('testFunction',
document('doc.xml')/root)/
/xsl:template
/xsl:stylesheet
XSL;
function testFunction($a)
{
throw new Exception('Test exception.');
}
$domXml = DOMDocument::loadXML($sXml);
$domXsl = DOMDocument::loadXML($sXsl);
for ($i = 0; $i 10; $i++)
{
$xsltProcessor = new XSLTProcessor();
$xsltProcessor-registerPHPFunctions(array('testFunction'));
$xsltProcessor-importStyleSheet($domXsl);
try {
@$xsltProcessor-transformToDoc($domXml);
} catch (Exception $e) {
echo Exception!\n;
}
}
Expected result:
Exception!
Exception!
Exception!
Exception!
Exception!
Exception!
Exception!
Exception!
Exception!
Exception!
Actual result:
--
(gdb) r
Starting program: /home/armiento/env/spider/bin/php test_segfault.php
[Thread debugging using libthread_db enabled]
[New Thread 140442269927120 (LWP 3340)]
Exception!
Exception!
*** glibc detected *** free(): invalid pointer: 0x0137d0d0 ***
Program received signal SIGABRT, Aborted.
[Switching to Thread 140442269927120 (LWP 3340)]
0x7fbb423cb07b in raise () from /lib/libc.so.6
(gdb) bt
#0 0x7fbb423cb07b in raise () from /lib/libc.so.6
#1 0x7fbb423cc84e in abort () from /lib/libc.so.6
#2 0x7fbb424015f9 in __fsetlocking () from /lib/libc.so.6
#3 0x7fbb42408163 in mallopt () from /lib/libc.so.6
#4 0x7fbb424081ee in free () from /lib/libc.so.6
#5 0x0044f3ab in php_libxml_node_decrement_resource
(object=0x7fbb439a0710)
at /home/armiento/src/php-5.3.0/ext/libxml/libxml.c:1058
#6 0x004caed5 in dom_objects_free_storage
(object=0x7fbb439a0710) at /home/armiento/src/php-
5.3.0/ext/dom/php_dom.c:1017
#7 0x006bf026 in zend_objects_store_del_ref_by_handle_ex
(handle=3, handlers=value optimized out)
at /home/armiento/src/php-5.3.0/Zend/zend_objects_API.c:220
#8 0x006bf062 in zend_objects_store_del_ref
(zobject=0x7fbb4399e4f0)
at /home/armiento/src/php-5.3.0/Zend/zend_objects_API.c:172
#9 0x00692cc5 in _zval_ptr_dtor (zval_ptr=0x7fbb439a0e40) at
/home/armiento/src/php-5.3.0/Zend/zend_variables.h:35
#10 0x006aab88 in zend_hash_destroy (ht=0x7fbb439a0d80) at
/home/armiento/src/php-5.3.0/Zend/zend_hash.c:526
#11 0x0069ec36 in _zval_dtor_func (zvalue=0x7fbb439a0d50) at
/home/armiento/src/php-5.3.0/Zend/zend_variables.c:43
#12 0x00692cc5 in _zval_ptr_dtor (zval_ptr=0x7fbb439a0e98) at
/home/armiento/src/php-5.3.0/Zend/zend_variables.h:35
#13 0x006aab88 in zend_hash_destroy (ht=0x7fbb439a0ca8) at
/home/armiento/src/php-5.3.0/Zend/zend_hash.c:526
#14 0x0069ec36 in _zval_dtor_func (zvalue=0x7fbb439a0c78) at
/home/armiento/src/php-5.3.0/Zend/zend_variables.c:43
#15 0x00692cc5 in _zval_ptr_dtor (zval_ptr=0x7fbb439a0ef0) at
/home/armiento/src/php-5.3.0/Zend/zend_variables.h:35
#16 0x006aab88 in zend_hash_destroy (ht=0x7fbb439a0ba0) at
/home/armiento/src/php-5.3.0/Zend/zend_hash.c:526
#17 0x0069ec36 in _zval_dtor_func (zvalue=0x7fbb439a0b70) at
/home/armiento/src/php-5.3.0/Zend/zend_variables.c:43
#18 0x00692cc5 in _zval_ptr_dtor (zval_ptr=0x7fbb439a0f50) at
/home/armiento/src/php-5.3.0/Zend/zend_variables.h:35
#19 0x006aab88 in zend_hash_destroy (ht=0x7fbb439a0ac8) at
/home/armiento/src/php-5.3.0/Zend/zend_hash.c:526
#20 0x0069ec36 in _zval_dtor_func (zvalue=0x7fbb439a00f0) at
/home/armiento/src/php-5.3.0/Zend/zend_variables.c:43
#21 0x00692cc5 in _zval_ptr_dtor (zval_ptr=0x7fbb439a0a08) at
/home/armiento/src/php-5.3.0/Zend/zend_variables.h:35
#22 0x006aab88 in zend_hash_destroy (ht=0x7fbb439a0930) at
/home/armiento/src/php-5.3.0/Zend/zend_hash.c:526
#23 0x006bb989 in zend_object_std_dtor
#49636 [NEW]: PHP_INT_SIZE inconsistent with pack(i
From: hsu at jean-david dot com Operating system: linux PHP version: 5.2.11 PHP Bug Type: Variables related Bug description: PHP_INT_SIZE inconsistent with pack(i Description: PHP pack documentation: i signed integer (machine dependent size and byte order) PHP integer documentation: Integer size can be determined using the constant PHP_INT_SIZE On some systems, I believe that the word integer will refer to objects of different sizes, such that pack(i, _) could point to an object of size X bytes and PHP_INT_SIZE return value Y which is inconsistent. /main/main.c l.1796: REGISTER_MAIN_LONG_CONSTANT(PHP_INT_SIZE, sizeof(long), CONST_PERSISTENT | CONST_CS); /ext/standard/pack.c l.402-403: php_pack(argv[currentarg++], sizeof(int), int_map, output[outputpos]); outputpos += sizeof(int); Reproduce code: --- file_put_contents(test.bin,pack(I, 2)); var_dump(PHP_INT_SIZE === filesize(test.bin)); Expected result: bool(true) Actual result: -- bool(false) -- Edit bug report at http://bugs.php.net/?id=49636edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49636r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49636r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49636r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49636r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49636r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49636r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49636r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49636r=needscript Try newer version: http://bugs.php.net/fix.php?id=49636r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49636r=support Expected behavior: http://bugs.php.net/fix.php?id=49636r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49636r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49636r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49636r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49636r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49636r=dst IIS Stability: http://bugs.php.net/fix.php?id=49636r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49636r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49636r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49636r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49636r=mysqlcfg
#49531 [Opn-Csd]: CURLOPT_INFILESIZE sometimes causes warning CURLPROTO_FILE cannot be set
ID: 49531
Updated by: fel...@php.net
Reported By: gilad at parann dot net
-Status: Open
+Status: Closed
Bug Type: cURL related
Operating System: any (was seen on Win32 XP)
-PHP Version: 5.2.10
+PHP Version: 5.2, 5.3 and HEAD
-Assigned To:
+Assigned To: felipe
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.
Fixed in 5.2, 5.3 and HEAD. Thanks for reporting!
Previous Comments:
[2009-09-23 02:08:19] s...@php.net
Automatic comment from SVN on behalf of felipe
Revision: http://svn.php.net/viewvc/?view=revisionrevision=288598
Log: - Fixed bug #49531 (CURLOPT_INFILESIZE sometimes causes warning
CURLPROTO_FILE cannot be set ...)
[2009-09-17 07:41:06] bonecollector at hot dot ee
Seems, that other options cause also this warning:
?
$chk_time=date('2009-08-07 10:10:10');
$resURL = curl_init();
curl_setopt($resURL, CURLOPT_URL, 'http://google.com');
curl_setopt($resURL, CURLOPT_TIMECONDITION,
CURL_TIMECOND_IFMODSINCE);
curl_setopt($resURL, CURLOPT_TIMEVALUE, $chk_time);
curl_setopt($resURL, CURLOPT_RETURNTRANSFER, TRUE);
curl_setopt($resURL, CURLOPT_HEADER, TRUE);
$pageData=curl_exec($resURL);
echo Got result:br;
echo $pageData;
?
and you will get same warning on line 7 (curl_setopt($resURL,
CURLOPT_TIMEVALUE, $chk_time);)
Searching at google, it seems that many-many pages have been broken
[2009-09-12 17:01:07] gilad at parann dot net
Further detail:
This was with PHP 5.2.10 and libcurl 7.19.4 in Apache 2.2.11 on Win32
(XP)
[2009-09-11 12:40:12] gilad at parann dot net
Description:
Set up PHP 5.2.10 with a basedir.
Calling
curl_setopt ($ch, CURLOPT_INFILESIZE, $len) ;
will sometimes cause PHP to generate a warning
CURLPROTO_FILE cannot be activated when in safe_mode or an open_basedir
is set
depending on the exact value of $len !!!
Looking at the source code of _php_curl_setopt (from
...ext/curl/interface.c) I think I see why. The code starts with a big
switch statement and NO break...
So the CURLOPT_INFILESIZE option gets processed by the IF statement
that checks if (Z_LVAL_PP(zvalue) CURLPROTO_FILE) !!
Sometimes the $len value will happen to have the same bits set as
CURLPROTO_FILE and boom - you get the error.
Anyway if you avoid setting INFILESIZE things do work - only sometimes
that is not so convenient...
Reproduce code:
---
from _php_curl_setopt in ...ext/curl/interface.c:
switch (option) {
case CURLOPT_INFILESIZE:
/* many many more options with NO break! */
case CURLOPT_REDIR_PROTOCOLS:
case CURLOPT_PROTOCOLS:
convert_to_long_ex(zvalue);
if (((PG(open_basedir) *PG(open_basedir)) ||
PG(safe_mode))
(Z_LVAL_PP(zvalue) CURLPROTO_FILE)) {
php_error_docref(NULL TSRMLS_CC,
E_WARNING, CURLPROTO_FILE cannot
be activated when in safe_mode or an open_basedir is set);
RETVAL_FALSE;
return 1;
}
error = curl_easy_setopt(ch-cp, option,
Z_LVAL_PP(zvalue));
break;
Expected result:
I expect the call to curl_setopt with CURLOPT_INFILESIZE to work
Actual result:
--
A warning is generated
CURLPROTO_FILE cannot be activated when in safe_mode or an open_basedir
is set
--
Edit this bug report at http://bugs.php.net/?id=49531edit=1
#49616 [Opn-Csd]: Impossible to increase SOMAXCONN
ID: 49616 User updated by: ben at realitychecknetwork dot com Reported By: ben at realitychecknetwork dot com -Status: Open +Status: Closed Bug Type: Feature/Change Request Operating System: Linux 2.6.18 PHP Version: 5.2.11 New Comment: In CentOS5.3 its actually : /usr/include/linux/socket.h Thanks, that did the trick. Replace: /* Maximum queue length specifiable by listen. */ #define SOMAXCONN 128 With: /* Maximum queue length specifiable by listen. */ #define SOMAXCONN 2048 Then recompile PHP Previous Comments: [2009-09-22 09:38:30] sjo...@php.net PHP uses the SOMAXCONN from sys/socket.h at compile time. [2009-09-21 20:22:24] ben at realitychecknetwork dot com Description: Impossible to increase SOMAXCONN value by updating system OS variable. PHP must be compiled with --enable-sockets for this bug to be produced. OS setting updated with: # sysctl -w net.core.somaxconn=2048 net.core.somaxconn = 2048 PHP will always return 128 for SOMAXCONN and will not respect the OS setting. Additionally, it will ignore a define statement in PHP code and return 128 as well. Reproduce code: --- define(SOMAXCONN, 2048); echo SOMAXCONN; Expected result: Should return 2048 Actual result: -- Returns 128 -- Edit this bug report at http://bugs.php.net/?id=49616edit=1
#49344 [Com]: pdo_mssql fails to connect,throws PDOException SQLSTATE[] (null) (severity 0)
ID: 49344
Comment by: Rockyjl at gmail dot com
Reported By: rockyjl at gmai dot com
Status: No Feedback
Bug Type: PDO related
Operating System: win2003 X64
PHP Version: 5.2.11RC1
Assigned To: felipe
New Comment:
My Modification:
static int pdo_dblib_handle_factory(pdo_dbh_t *dbh, zval
*driver_options TSRMLS_DC)
{
pdo_dblib_db_handle *H;
int i, ret = 0;
char *location = L=;
struct pdo_data_src_parser vars[] = {
{ charset,NULL, 0 },
{ appname,PHP PDO_DBLIB_FLAVOUR, 0 },
{ host, 127.0.0.1, 0 },
{ dbname, NULL, 0 },
{ secure, NULL, 0 }, /* DBSETLSECURE */
/* TODO: DBSETLVERSION ? */
};
php_pdo_parse_data_source(dbh-data_source, dbh-data_source_len,
vars, 5);
H = pecalloc(1, sizeof(*H), dbh-is_persistent);
H-login = dblogin();
H-err.sqlstate = dbh-error_code;
if (!H-login) {
strcat(location, login);
goto cleanup;
}
if (dbh-username) {
DBSETLUSER(H-login, dbh-username);
}
if (dbh-password) {
DBSETLPWD(H-login, dbh-password);
}
#if !PHP_DBLIB_IS_MSSQL
if (vars[0].optval) {
DBSETLCHARSET(H-login, vars[0].optval);
}
#endif
DBSETLAPP(H-login, vars[1].optval);
#if PHP_DBLIB_IS_MSSQL
dbprocerrhandle(H-login, (EHANDLEFUNC) error_handler);
dbprocmsghandle(H-login, (MHANDLEFUNC) msg_handler);
#endif
H-link = dbopen(H-login, vars[2].optval);
if (H-link == NULL) {
strcat(location, link);
goto cleanup;
}
/* dblib do not return more than this length from text/image */
DBSETOPT(H-link, DBTEXTLIMIT, 2147483647);
/* limit text/image from network */
DBSETOPT(H-link, DBTEXTSIZE, 2147483647);
if (vars[3].optval FAIL == dbuse(H-link, vars[3].optval)) {
strcat(location, optval);
goto cleanup;
}
ret = 1;
dbh-max_escaped_char_length = 2;
dbh-alloc_own_columns = 1;
cleanup:
for (i = 0; i sizeof(vars)/sizeof(vars[0]); i++) {
if (vars[i].freeme) {
efree(vars[i].optval);
}
}
dbh-methods = dblib_methods;
dbh-driver_data = H;
if (!ret) {
zend_throw_exception_ex(php_pdo_get_exception(), 0 TSRMLS_CC,
SQLSTATE[%s] %s (severity %d) %s, //I want to
findout the bug
location !
DBLIB_G(err).sqlstate,
DBLIB_G(err).dberrstr,
DBLIB_G(err).severity,
location);
}
return ret;
}
The PDO MSSQL work is correct, the bug never happen and never throws
any PDOException after Complie php_pdo_mssql.dll ...
I think my modification STOP all PDOException throw ...
Anyone can tell me what is the problem ?
Previous Comments:
[2009-09-17 01:00:02] 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-10 15:38:07] Rockyjl at gmail dot com
apache 2.2.13 + PHP 5.2 (5.2.11RC3-dev) VC6 x86 Thread Safe
(2009-Sep-10 12:00:00)
often happen error:
[2009-09-10 23:30:10]
127.0.0.1
ApacheBench/2.3
SQLSTATE[] (null) (severity 0)
This patch cannot work ???!!!
[2009-09-10 06:07:50] Rockyjl at gmail dot com
PHP 5.3 (5.3.2-dev) VC6 x86 Thread Safe (2009-Sep-10 06:00:00)
http://windows.php.net/downloads/snaps/php-5.3-win32-VC6-x86-latest.zip
the bug happen too
[2009-09-10 01:20:42] s...@php.net
Automatic comment from SVN on behalf of felipe
Revision: http://svn.php.net/viewvc/?view=revisionrevision=288215
Log: - Possible fix for bug #49344 on Windows (pdo_mssql fails to
connect,throws PDOException SQLSTATE[] (null) (severity 0))
[2009-09-09 09:43:20] Rockyjl at gmail dot com
Pajoye, Thank you so much! This is very important to me !
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/49344
--
Edit this
#39058 [Com]: Memory Leak
ID: 39058
Comment by: gi_mike2002 at yahoo dot com
Reported By: mpcribeiro at yahoo dot com
Status: No Feedback
Bug Type: Sybase-ct (ctlib) related
Operating System: Solaris 10
PHP Version: 5.1.6
New Comment:
No movement on this since 2006?!
tsk, tsk...
Previous Comments:
[2008-06-24 14:55:08] jjsainzc at gmail dot com
I'm use freetds and php5.1.6
I have the same problem:
Source (part):
$connect_sybase_id=sybase_connect(Database,login,pass);
if ($connect_sybase_id)
echo Conectado\n;
else
echo No conectado\n;
if (sybase_select_db(Database))
echo Seleccionada la base\n;
else
echo No pude seleccionar la base\n;
$query=SELECT field FROM DBA.tabla WHERE codigo=1;
$result = false;
$result = sybase_query($query);
if ($result) {
$r=sybase_fetch_row($result);
echo Resultado\n;
print_r($r);
}
else echo No pude hacer el query\n;
sybase_close($connect_sybase_id);
Result:
Fatal error: Allowed memory size of 209715200 bytes exhausted (tried to
allocate 56 bytes) in /home/support/prueba.php on line 30
[2008-06-13 09:46:49] daniel dot buschke at nextiraone dot de
Noticed that mpcribeiro is using sybase bindings. I use freetds! So it
is not a problem of the bindings, is it?
[2008-06-13 09:44:21] daniel dot buschke at nextiraone dot de
# php -v
PHP 5.2.6RC4-pl0-gentoo (cli) (built: Jun 13 2008 11:18:19)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies
Still the same problem. Please reopen 'cause bug seems not fixed.
Let me know how I can provide further informations - if needed.
[2008-03-03 07:33:51] kristjan at laborint dot com
Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to
allocate 256 bytes)
PHP:
PHP Version 5.2.5
System:
Linux z37 2.6.9-67.0.4.ELsmp #1 SMP Sun Feb 3 07:06:14 EST 2008 x86_64
Server API:
CGI/FastCGI
Sybase:
Client API Version $Id: dblib.c,v 1.244.2.1 2006/01/31 08:45:20
freddy77 Exp $
[2007-05-13 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.
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/39058
--
Edit this bug report at http://bugs.php.net/?id=39058edit=1
