#47065 [NEW]: function session_unset() reset local variables
From: opurahman at gmail dot com Operating system: Linux PHP version: 5.2.8 PHP Bug Type: Session related Bug description: function session_unset() reset local variables Description: function session_unset() reset local variables. I was trying to reset session variables after storing two values from session. It reset my local variables. Lets take a look into the codes bellow. Reproduce code: --- session_start(); $message = sprintf('%s', $_SESSION['message']); echo('Here Message: # ' . $message . ''); session_unset(); echo('Here Message: # ' . $message . ''); // in this line, the variable $message has been unset. Expected result: It should display the value of $message -- Edit bug report at http://bugs.php.net/?id=47065&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47065&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47065&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47065&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47065&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47065&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47065&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47065&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47065&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47065&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47065&r=support Expected behavior: http://bugs.php.net/fix.php?id=47065&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47065&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47065&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47065&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47065&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47065&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47065&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47065&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47065&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47065&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47065&r=mysqlcfg
#46960 [Asn->Csd]: Actual location (location was relayed)
ID: 46960 Updated by: dmi...@php.net Reported By: rutekp at freelance-worker dot net -Status: Assigned +Status: Closed Bug Type: Reproducible crash Operating System: Centos 5 x64 PHP Version: 5.2.8 Assigned To: dmitry New Comment: 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. The bug is already fixed in PHP-5.3 with Garbage Collector which collects cyclic references. In PHP-5.2 this bug will never fixed. You can get the same memory leaks with smaller script: In case your script creates cyclic structures, in 5.2 it's better to break cycles before exit manually. Previous Comments: [2008-12-28 08:37:47] rutekp at freelance-worker dot net Description: When I try to excedue code which is below without: $array["foo"] = null; $array["blah"] = null; have errors like Actual location (location was relayed) Freeing 0x05298E00 Reproduce code: --- --TEST-- Test session_encode() function : variation --SKIPIF-- --FILE-- --EXPECTF-- *** Testing session_encode() : variation *** bool(true) string(64) "data|a:5:{i:0;i:1;i:1;i:2;i:2;i:3;s:3:"foo";R:1;s:4:"blah";R:1;}" bool(true) Done Actual result: -- [Thu Oct 30 20:56:43 2008] Script: 'ext/session/tests/session_encode_variation5.phpt' /root/src/php-5.2.6/Zend/zend_vm_execute.h(3565) : Freeing 0x05293DD8 (24 bytes), script=ext/session/tests/session_encode_variation5.phpt Last leak repeated 2 times [Thu Oct 30 20:56:43 2008] Script: 'ext/session/tests/session_encode_variation5.phpt' /root/src/php-5.2.6/Zend/zend_vm_execute.h(3610) : Freeing 0x05298CC8 (72 bytes), script=ext/session/tests/session_encode_variation5.phpt /root/src/php-5.2.6/Zend/zend_API.c(827) : Actual location (location was relayed) Last leak repeated 1 time [Thu Oct 30 20:56:43 2008] Script: 'ext/session/tests/session_encode_variation5.phpt' /root/src/php-5.2.6/Zend/zend_vm_execute.h(3596) : Freeing 0x05298E00 (71 bytes), script=ext/session/tests/session_encode_variation5.phpt /root/src/php-5.2.6/Zend/zend_hash.c(388) : Actual location (location was relayed) Last leak repeated 2 times [Thu Oct 30 20:56:43 2008] Script: 'ext/session/tests/session_encode_variation5.phpt' /root/src/php-5.2.6/Zend/zend_execute.c(834) : Freeing 0x05299050 (24 bytes), script=ext/session/tests/session_encode_variation5.phpt [Thu Oct 30 20:56:43 2008] Script: 'ext/session/tests/session_encode_variation5.phpt' /root/src/php-5.2.6/Zend/zend_hash.c(247) : Freeing 0x052990C0 (75 bytes), script=ext/session/tests/session_encode_variation5.phpt Last leak repeated 1 time === Total 11 memory leaks detected === -- Edit this bug report at http://bugs.php.net/?id=46960&edit=1
#46850 [Asn->Bgs]: compile time depends on runtime constants ZEND_COMPILE_NO_CONSTANT_SUBSTITUTION
ID: 46850 Updated by: dmi...@php.net Reported By: moo dot tinys at gmail dot com -Status: Assigned +Status: Bogus Bug Type: Scripting Engine problem Operating System: * PHP Version: 5.3CVS-2008-12-12 (CVS) Assigned To: dmitry New Comment: NULL, TRUE and FALSE may never be redefined in namespaces. So it's safe to always substitute them at compile time. Previous Comments: [2009-01-09 19:07:22] s...@php.net I'm not sure why you need to clean up EG(zend_constants). Together with runtime constants it also contains such constants as null, which has special "privilege" of being resolved at compile-time, since they are always the same and have special meaning. [2008-12-12 14:57:17] moo dot tinys at gmail dot com Description: let's focus our eyes on zend_compile.c function zend_do_receive_arg void zend_do_receive_arg(zend_uchar op, const znode *var, const znode *offset, const znode *initialization, znode *class_type, const znode *varname, zend_uchar pass_by_reference TSRMLS_DC) { ... if (op == ZEND_RECV_INIT) { if (Z_TYPE(initialization->u.constant) == IS_NULL || (Z_TYPE(initialization->u.constant) == IS_CONSTANT && !strcasecmp(Z_STRVAL(initialization->u.constant), "NULL"))) { cur_arg_info->allow_null = 1; } else { zend_error(E_COMPILE_ERROR, "Default value for parameters with a class type hint can only be NULL"); } } == (the following gdb input/output is still using macro for your reading, expand the macro if you want to execute) test case 1 precondition: CG(compiler_options) |= ZEND_COMPILE_NO_CONSTANT_SUBSTITUTION; before zend_compile_file break at function zend_do_receive_arg and (gdb) print Z_TYPE(initialization->u.constant) == IS_NULL 1 (true) which means php still subst "null" to "IS_NULL" test case 2 precondtion: let's assume ZEND_COMPILE_NO_CONSTANT_SUBSTITUTION is working for zend_do_receive_arg, simply empty hash table: EG(zend_constants) = &an_empty_hash_table; before zend_compile_file break at function zend_do_receive_arg and (gdb) print Z_TYPE(initialization->u.constant) == IS_NULL 0 (false) (gdb) print Z_TYPE(initialization->u.constant) == IS_CONSTANT 0 (false) so what is that? (gdb) print Z_TYPE(initialization->u.constant) 24 (gdb) print (Z_TYPE(initialization->u.constant) & IS_CONSTANT_TYPE_MASK) == IS_CONSTANT 1 (true) ok, we get the first bug (gdb) p !strcasecmp(Z_STRVAL(initialization->u.constant), "NULL")) 0 (false) why? (gdb) p Z_STRVAL(initialization->u.constant) "My\\NS\\null" this is the reason. looks likestrcasecmp is not enough here at compile time. or you could just handle abc(array $a = null) as a special case? Reproduce code: --- test.php i don't think it easy to make a reproduce code, because in case 1: ZEND_COMPILE_NO_CONSTANT_SUBSTITUTION is disabled until you change it in extension or patch php for testing and in case 2: even if you enable ZEND_COMPILE_NO_CONSTANT_SUBSTITUTION, php is still free to access EG(zend_constants), EG(zend_constants) has to be empty to see the bug. see "actual result" there's a simple patch to reproduce it. (not fix) Index: zend_language_scanner.l === RCS file: /repository/ZendEngine2/zend_language_scanner.l,v retrieving revision 1.131.2.11.2.13.2.32 diff -u -r1.131.2.11.2.13.2.32 zend_language_scanner.l --- zend_language_scanner.l 4 Nov 2008 15:58:51 - 1.131.2.11.2.13.2.32 +++ zend_language_scanner.l 12 Dec 2008 14:54:47 - @@ -311,6 +311,8 @@ ZEND_API zend_op_array *compile_file(zend_file_handle *file_handle, int type TSRMLS_DC) { + HashTable empty_hash, *old_hash; + zend_lex_state original_lex_state; zend_op_array *op_array = (zend_op_array *) emalloc(sizeof(zend_op_array)); zend_op_array *original_active_op_array = CG(active_op_array); @@ -320,6 +322,12 @@ znode retval_znode; zend_bool original_in_compilation = CG(in_compilation); + CG(compiler_options) |= ZEND_COMPILE_NO_CONSTANT_SUBSTITUTION; + zend_hash_init(&empty_hash, 1, NULL, NULL, 0); + old_hash = EG(zend_constants); + EG(zend_constants) = &empty_hash; + fprintf(stderr, "asdfasdf\n\n"); + retval_znode.op_type = IS_CONST; retval_znode.u.constant.type = IS_LONG; retval_znode.u.constant.value.lval = 1; @@ -364,6 +372,10 @@ if (compilation_successful) { zend_restore_lexical_state(&original_lex_state TSRMLS_CC); } + + zend_hash_destroy(&empty_hash); + EG(zend_constants) = old_hash; + return retval; } Expected result: in case 1: when ZEND_COMPILE_NO_CONSTANT_SUBSTITUTION is enabled, "null" (code) should not be resolved to "null" (val
#47066 [NEW]: Entity reference parsing broken since libxml 2.5.x
From: tstarling at wikimedia dot org Operating system: Linux PHP version: 5.2.8 PHP Bug Type: XML related Bug description: Entity reference parsing broken since libxml 2.5.x Description: The xml extension (xml_parser_create() etc) has totally broken entity reference parsing when compiled with a modern libxml2 library. This appears to be due to some clueless code inserted in compat.c 1.37 (November 2004) http://cvs.php.net/viewvc.cgi/php-src/ext/xml/compat.c?r1=1.36&r2=1.37&pathrev=PHP_5_2 parser->parser->wellFormed = 0; parser->wellFormed is set to 1 by libxml's xmlInitParserCtxt(), and then to 0 by all the error cases that make the document not well-formed. Setting wellFormed=0, before parsing even begins, means that all input is unconditionally considered to be not well formed. This probably causes all sorts of bugs, but the present one is an interaction with libxml2 r1177: http://svn.gnome.org/viewvc/libxml2/trunk/parser.c?r1=1176&r2=1177&; At line 5174 on the right, entities such as "<" encountered while wellFormed==0 are ignored. Simply removing the quoted line from compat.c fixes the bug, without breaking any unit tests. Reported to Wikimedia at https://bugzilla.wikimedia.org/show_bug.cgi?id=16554 Reproduce code: --- Compile libxml2 from source, version 2.5 or later, and link it to PHP with --with-libxml-dir. a Expected result: a < b Actual result: -- a b -- Edit bug report at http://bugs.php.net/?id=47066&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47066&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47066&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47066&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47066&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47066&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47066&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47066&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47066&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47066&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47066&r=support Expected behavior: http://bugs.php.net/fix.php?id=47066&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47066&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47066&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47066&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47066&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47066&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47066&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47066&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47066&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47066&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47066&r=mysqlcfg
#46792 [Asn->Fbk]: SoapFault detail property missing
ID: 46792 Updated by: dmi...@php.net Reported By: daniel dot oconnor at gmail dot com -Status: Assigned +Status: Feedback Bug Type: SOAP related Operating System: Windows PHP Version: 5.2.7 Assigned To: dmitry New Comment: I don't think we should create empty "detail" property (and then encode it and send back to client) if it's not important. Very rare script looks into fault details. In case your script really needs it, it can always check it with isset() or empty(). Previous Comments: [2008-12-31 17:39:13] fel...@php.net Hi Dmitry, any objection? http://felipe.ath.cx/diff/bug46792.diff [2008-12-08 00:06:24] daniel dot oconnor at gmail dot com Description: If you don't supply a detail param in the constructor of SoapFault, the property doesn't exist. See also bug #39357 Reproduce code: --- string(0) "" ["string:private"]=> string(0) "" ["code:protected"]=> int(0) ["file:protected"]=> string(17) "C:\soap_fault.php" ["line:protected"]=> int(2) ["trace:private"]=> array(0) { } ["faultstring"]=> string(0) "" ["detail"]=> string(8) "Details!" } object(SoapFault)#2 (7) { ["message:protected"]=> string(0) "" ["string:private"]=> string(0) "" ["code:protected"]=> int(0) ["file:protected"]=> string(17) "C:\soap_fault.php" ["line:protected"]=> int(6) ["trace:private"]=> array(0) { } ["faultstring"]=> string(0) "" } -- Edit this bug report at http://bugs.php.net/?id=46792&edit=1
#47057 [Asn->Bgs]: Inconsitent namespace resolving when using dynamic class instanciation
ID: 47057 Updated by: dmi...@php.net Reported By: tobias dot john at fondsnet dot de -Status: Assigned +Status: Bogus Bug Type: Scripting Engine problem Operating System: Mac OS X 10.5 PHP Version: 5.3CVS-2009-01-09 (CVS) Assigned To: dmitry New Comment: Namespaces is a compile time feature. In run-time you should always use full qualified names. You can use a special constant __NAMESPACE__ to do it. $classname2 = __NAMESPACE__ . '\foo\bar\Baz'; Previous Comments: [2009-01-09 17:39:14] tobias dot john at fondsnet dot de Description: When using a variable to instantiate a class, the behavior in namespace resolving is inconsistent to the behavior when using a static class name. Reproduce code: --- namespace foo\bar; class Baz { public $value; public function __construct($v) { $this->value = $v; } public function echoValue() { echo 'Value: ' . $this->value, PHP_EOL; } } $classname1 = '\foo\bar\Baz'; $classname2 = 'foo\bar\Baz'; $a = new $classname1('A'); $a->echoValue(); $b = new $classname2('B'); $b->echoValue(); $c = new \foo\bar\Baz('C'); $c->echoValue(); $d = new foo\bar\Baz('D'); $d->echoValue(); Expected result: Value: A Fatal error: Class 'foo\bar\foo\bar\Baz' not found in /Users/tj/Documents/workspace/yeti/lib/yeti/NamespaceTest.php on line 20 Actual result: -- Value: A Value: B Value: C Fatal error: Class 'foo\bar\foo\bar\Baz' not found in /Users/tj/Documents/workspace/yeti/lib/yeti/NamespaceTest.php on line 24 -- Edit this bug report at http://bugs.php.net/?id=47057&edit=1
#47067 [NEW]: NULL is set or unset value?
From: farkow at gmail dot com Operating system: Windows/WAMP Server PHP version: 5.2.8 PHP Bug Type: Unknown/Other Function Bug description: NULL is set or unset value? Description: I realized it when i try someting about my web-based game, when you set an integer NULL, it is same with 0 and ''. Reproduce code: --- '; if($x == '') echo 'UPPS 2'; if($x === '') echo 'UPPS 3'; ?> Expected result: //output Actual result: -- //output UPPS 1 UPPS 2 -- Edit bug report at http://bugs.php.net/?id=47067&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47067&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47067&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47067&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47067&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47067&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47067&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47067&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47067&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47067&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47067&r=support Expected behavior: http://bugs.php.net/fix.php?id=47067&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47067&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47067&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47067&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47067&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47067&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47067&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47067&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47067&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47067&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47067&r=mysqlcfg
#46792 [Fbk->Opn]: SoapFault detail property missing
ID: 46792 User updated by: daniel dot oconnor at gmail dot com Reported By: daniel dot oconnor at gmail dot com -Status: Feedback +Status: Open Bug Type: SOAP related Operating System: Windows PHP Version: 5.2.7 Assigned To: dmitry New Comment: Not having the property defined was surprising, and unexpected - I would not expect code which reads SoapFault::$detail to ever generate an E_NOTICE. Previous Comments: [2009-01-11 09:40:03] dmi...@php.net I don't think we should create empty "detail" property (and then encode it and send back to client) if it's not important. Very rare script looks into fault details. In case your script really needs it, it can always check it with isset() or empty(). [2008-12-31 17:39:13] fel...@php.net Hi Dmitry, any objection? http://felipe.ath.cx/diff/bug46792.diff [2008-12-08 00:06:24] daniel dot oconnor at gmail dot com Description: If you don't supply a detail param in the constructor of SoapFault, the property doesn't exist. See also bug #39357 Reproduce code: --- string(0) "" ["string:private"]=> string(0) "" ["code:protected"]=> int(0) ["file:protected"]=> string(17) "C:\soap_fault.php" ["line:protected"]=> int(2) ["trace:private"]=> array(0) { } ["faultstring"]=> string(0) "" ["detail"]=> string(8) "Details!" } object(SoapFault)#2 (7) { ["message:protected"]=> string(0) "" ["string:private"]=> string(0) "" ["code:protected"]=> int(0) ["file:protected"]=> string(17) "C:\soap_fault.php" ["line:protected"]=> int(6) ["trace:private"]=> array(0) { } ["faultstring"]=> string(0) "" } -- Edit this bug report at http://bugs.php.net/?id=46792&edit=1
#47067 [Opn]: NULL is set or unset value?
ID: 47067 User updated by: farkow at gmail dot com Reported By: farkow at gmail dot com Status: Open Bug Type: Unknown/Other Function Operating System: Windows/WAMP Server PHP Version: 5.2.8 New Comment: In description, i used a wrong word, sorry for my English. It is not 'integer', i mean 'variable'. Previous Comments: [2009-01-11 10:44:36] farkow at gmail dot com Description: I realized it when i try someting about my web-based game, when you set an integer NULL, it is same with 0 and ''. Reproduce code: --- '; if($x == '') echo 'UPPS 2'; if($x === '') echo 'UPPS 3'; ?> Expected result: //output Actual result: -- //output UPPS 1 UPPS 2 -- Edit this bug report at http://bugs.php.net/?id=47067&edit=1
#47042 [Opn->Csd]: php cgi sapi is incorrectly removing the SCRIPT_FILENAME for non apache
ID: 47042 Updated by: d...@php.net Reported By: sriram dot natarajan at sun dot com -Status: Open +Status: Closed Bug Type: CGI related Operating System: linux , solaris PHP Version: 5.2.8 New Comment: 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. Previous Comments: [2009-01-08 22:19:12] sriram dot natarajan at sun dot com previous patch had whitespaces instead of tabs causing the patch to appear distorted. posting a same patch with this issue addressed --- sapi/cgi/cgi_main.c.ORIGThu Jan 8 14:18:25 2009 +++ sapi/cgi/cgi_main.c Thu Jan 8 14:18:31 2009 @@ -960,7 +960,9 @@ TRANSLATE_SLASHES(env_document_root); } - if (env_path_translated != NULL && env_redirect_url != NULL) { + if (env_path_translated != NULL && env_redirect_url != NULL && + orig_script_filename != NULL && script_path_translated != NULL && + strcmp(orig_script_filename, script_path_translated) != 0) { /* pretty much apache specific. If we have a redirect_url then our script_filename and script_name point to the [2009-01-08 20:06:25] sriram dot natarajan at sun dot com here is the suggested patch to address this issue --- sapi/cgi/cgi_main.c.ORIGWed Jan 7 07:10:14 2009 +++ sapi/cgi/cgi_main.c Wed Jan 7 19:37:21 2009 @@ -960,16 +960,18 @@ TRANSLATE_SLASHES(env_document_root); } - if (env_path_translated != NULL && env_redirect_url != NULL) { - /* - pretty much apache specific. If we have a redirect_url - then our script_filename and script_name point to the - php executable - */ - script_path_translated = env_path_translated; - /* we correct SCRIPT_NAME now in case we don't have PATH_INFO */ - env_script_name = env_redirect_url; - } +if (env_path_translated != NULL && env_redirect_url != NULL && +orig_script_filename != NULL && script_path_translated != NULL && +strcmp(orig_script_filename, script_path_translated) != 0) { +/* + pretty much apache specific. If we have a redirect_url + then our script_filename and script_name point to the + php executable +*/ +script_path_translated = env_path_translated; +/* we correct SCRIPT_NAME now in case we don't have PATH_INFO */ +env_script_name = env_redirect_url; +} [2009-01-08 20:04:39] sriram dot natarajan at sun dot com Description: currently, php cgi sapi code checks for redirect url and env_path_translated to determine if the request is coming from apache web server and accordingly modifies the CGI environment variables so that server can continue processing. however, this check is insufficient considering that any web server exporting SCRIPT_FILENAME and REDIRECT_URL with some value will be hit by the apache specific processing. Reproduce code: --- if (env_path_translated != NULL && env_redirect_url != NULL) { /* pretty much apache specific. If we have a redirect_url then our script_filename and script_name point to the php executable */ script_path_translated = env_path_translated; /* we correct SCRIPT_NAME now in case we don't have PATH_INFO */ env_script_name = env_redirect_url; } Expected result: server should continue processing Actual result: -- no input file is returned -- Edit this bug report at http://bugs.php.net/?id=47042&edit=1
#47066 [Opn->Bgs]: Entity reference parsing broken since libxml 2.5.x
ID: 47066 Updated by: rricha...@php.net Reported By: tstarling at wikimedia dot org -Status: Open +Status: Bogus Bug Type: XML related Operating System: Linux PHP Version: 5.2.8 New Comment: Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Thank you for your interest in PHP. Dupe of bug #45996 Previous Comments: [2009-01-11 09:37:19] tstarling at wikimedia dot org Description: The xml extension (xml_parser_create() etc) has totally broken entity reference parsing when compiled with a modern libxml2 library. This appears to be due to some clueless code inserted in compat.c 1.37 (November 2004) http://cvs.php.net/viewvc.cgi/php-src/ext/xml/compat.c?r1=1.36&r2=1.37&pathrev=PHP_5_2 parser->parser->wellFormed = 0; parser->wellFormed is set to 1 by libxml's xmlInitParserCtxt(), and then to 0 by all the error cases that make the document not well-formed. Setting wellFormed=0, before parsing even begins, means that all input is unconditionally considered to be not well formed. This probably causes all sorts of bugs, but the present one is an interaction with libxml2 r1177: http://svn.gnome.org/viewvc/libxml2/trunk/parser.c?r1=1176&r2=1177&; At line 5174 on the right, entities such as "<" encountered while wellFormed==0 are ignored. Simply removing the quoted line from compat.c fixes the bug, without breaking any unit tests. Reported to Wikimedia at https://bugzilla.wikimedia.org/show_bug.cgi?id=16554 Reproduce code: --- Compile libxml2 from source, version 2.5 or later, and link it to PHP with --with-libxml-dir. a Expected result: a < b Actual result: -- a b -- Edit this bug report at http://bugs.php.net/?id=47066&edit=1
#45996 [Asn->Csd]: libxml2 2.7.1 causes breakage with character data in xml_parse()
ID: 45996 Updated by: rricha...@php.net Reported By: phpbugs at colin dot guthr dot ie -Status: Assigned +Status: Closed Bug Type: XML related Operating System: Mandriva Linux PHP Version: 5.2.6 Assigned To: rrichards New Comment: 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. This fix also requires the soon to be released libxml2-2.7.3 or higher when using 2.7.x. Previous Comments: [2009-01-03 04:03:53] david+phpbugs at midrange dot com Ok, I'm going to try and rebuild the Fedora 8 source RPM to avoid the libxml2 bug ... but I'm not all that familiar with how PHP is built ... and could use a pointer or two on what to change on the configure command line. Any suggestions? [2009-01-02 23:03:29] geoffers+phpbugs at gmail dot com What is the recommended advice for PHP software that relies upon the XML extension? It'd be easier to say that libxml2.7.02.7.2 wasn't supported if it weren't for the fact that I've had at least one user come who had LIBXML_VERSION equal to 20632 with this issue we can't just add a LIBXML_VERSION based workaround, not just because the constant doesn't exist on 4.3.0, but also because it is seemingly isn't reliable. [2009-01-01 20:09:07] phpbugs at colin dot guthr dot ie If the Fedora packages do not work then this is a RedHat packaging problem and you should complain to them/open a bug etc. etc. Like I say, in Mandriva we made sure we provided packages that worked because they were compiled with expat. [2009-01-01 19:31:49] alex at peoples dot ru Thanks for advice, but I'm not guru in the Linux, as I haven't cpanel on my server. I tried use 'yum remove' libxml2 and add new, but off course this is stupid and doesn't work. I liked Linux, as the easiest and powerful system, but now, I'm stock. I haven't any idea how I can remove libxml2 and build new system with old one. One idea - change system on Fedora 9, because FC 10 have the same bug with fucking libxml2. Sorry, I was at Data Center 8 hours and I had problem with servers with new system. I don't like updates now... they have bugs every where, and I'm tiered resolve this bugs. Sorry, Have a Happy New Year. I'll never ever will update my systems less when half year. [2008-12-31 15:22:17] scott...@php.net Guys please READ the report, this is a bug in libxml NOT a bug in PHP. 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/45996 -- Edit this bug report at http://bugs.php.net/?id=45996&edit=1
#47067 [Opn->Bgs]: NULL is set or unset value?
ID: 47067 Updated by: col...@php.net Reported By: farkow at gmail dot com -Status: Open +Status: Bogus Bug Type: Unknown/Other Function Operating System: Windows/WAMP Server PHP Version: 5.2.8 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. That's expected, please check out: http://php.net/types.comparisons Previous Comments: [2009-01-11 10:57:53] farkow at gmail dot com In description, i used a wrong word, sorry for my English. It is not 'integer', i mean 'variable'. [2009-01-11 10:44:36] farkow at gmail dot com Description: I realized it when i try someting about my web-based game, when you set an integer NULL, it is same with 0 and ''. Reproduce code: --- '; if($x == '') echo 'UPPS 2'; if($x === '') echo 'UPPS 3'; ?> Expected result: //output Actual result: -- //output UPPS 1 UPPS 2 -- Edit this bug report at http://bugs.php.net/?id=47067&edit=1
#46997 [Com]: Column Name Based Result Fetching Causes Access Violation
ID: 46997 Comment by: allan at malwis dot dk Reported By: dangerousdave86 at hotmail dot com Status: Feedback Bug Type: MySQLi related Operating System: Windows Server 2008 Std ISAPI PHP Version: 5.2.8 New Comment: I have the error when trying to fetch more then one column. Environment: OS: WIN XP PRO 5.1.2600 SP3 PHP: 5.2.8 MySql: 5.1.30-community Webserver: IIS 5.1 Only SQL statement and echo line is different in the 3 examples. _ //This works: select_db(""); $query = 'SELECT name FROM items'; $result = $con->query($query); $row = $result->fetch_array(MYSQLI_ASSOC); echo $row["name"]; $con->close(); ?> _ //This works: select_db(""); $query = 'SELECT itemid FROM items'; $result = $con->query($query); $row = $result->fetch_array(MYSQLI_ASSOC); echo $row["itemid"]; $con->close(); ?> _ //This fails: select_db(""); $query = 'SELECT itemid, name FROM items'; $result = $con->query($query); $row = $result->fetch_array(MYSQLI_ASSOC); //This line gives PHP has encountered an Access Violation at 00FA2BEB echo $row["itemid"]; $con->close(); ?> _ Previous Comments: [2009-01-05 11:54:15] j...@php.net Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. [2009-01-03 13:58:33] dangerousdave86 at hotmail dot com Description: Error: PHP has encountered an Access Violation at 00322BEB When calling mysqli_fetch_assoc or mysqli_fetch_object on mysqli result. Also occurs using OO method. Error does not occur when using mysqli_fetch_row. Result is correct and indexed numerically in array. Reproduce code: --- Any database query using mysql that fetches rows using mysql_fetch_object, _fetch_assoc, _fetch_array. Or OO equivilents. Expected result: an array representing a row from the database Actual result: -- Access Violation -- Edit this bug report at http://bugs.php.net/?id=46997&edit=1
#47068 [NEW]: Parse error if global namespace resolution is used
From: ninzya at inbox dot lv Operating system: Windows XP PHP version: 5.3.0alpha3 PHP Bug Type: Scripting Engine problem Bug description: Parse error if global namespace resolution is used Description: See details below Reproduce code: --- index.php: 1: Expected result: Passed Actual result: -- Parse error: parse error in D:\WebServer\PHP-5.3a3\index.php on line 9 -- Edit bug report at http://bugs.php.net/?id=47068&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47068&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47068&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47068&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47068&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47068&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47068&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47068&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47068&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47068&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47068&r=support Expected behavior: http://bugs.php.net/fix.php?id=47068&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47068&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47068&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47068&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47068&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47068&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47068&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47068&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47068&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47068&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47068&r=mysqlcfg
#47068 [Opn]: Parse error if global namespace resolution is used
ID: 47068 User updated by: ninzya at inbox dot lv Reported By: ninzya at inbox dot lv Status: Open Bug Type: Scripting Engine problem Operating System: Windows XP PHP Version: 5.3.0alpha3 New Comment: This used to work in PHP 5.3.0alpha2 Previous Comments: [2009-01-11 15:20:54] ninzya at inbox dot lv Description: See details below Reproduce code: --- index.php: 1: Expected result: Passed Actual result: -- Parse error: parse error in D:\WebServer\PHP-5.3a3\index.php on line 9 -- Edit this bug report at http://bugs.php.net/?id=47068&edit=1
#47069 [NEW]: Expecting T_VARIABLE in catch block
From: ninzya at inbox dot lv Operating system: Windows XP PHP version: 5.3.0alpha3 PHP Bug Type: Scripting Engine problem Bug description: Expecting T_VARIABLE in catch block Description: See details below. This used to work with PHP 5.3.0alpha2 Reproduce code: --- index.php: 1: Expected result: No parse errors Actual result: -- Parse error: parse error, expecting `T_VARIABLE' in D:\WebServer\PHP-5.3a3\index.php on line 5 -- Edit bug report at http://bugs.php.net/?id=47069&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47069&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47069&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47069&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47069&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47069&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47069&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47069&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47069&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47069&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47069&r=support Expected behavior: http://bugs.php.net/fix.php?id=47069&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47069&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47069&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47069&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47069&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47069&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47069&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47069&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47069&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47069&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47069&r=mysqlcfg
#47068 [Opn->Bgs]: Parse error if global namespace resolution is used
ID: 47068 Updated by: fel...@php.net Reported By: ninzya at inbox dot lv -Status: Open +Status: Bogus Bug Type: Scripting Engine problem Operating System: Windows XP PHP Version: 5.3.0alpha3 New Comment: Hi, the namespace separator was changed to \. http://docs.php.net/manual/en/language.namespaces.basics.php Previous Comments: [2009-01-11 15:21:49] ninzya at inbox dot lv This used to work in PHP 5.3.0alpha2 [2009-01-11 15:20:54] ninzya at inbox dot lv Description: See details below Reproduce code: --- index.php: 1: Expected result: Passed Actual result: -- Parse error: parse error in D:\WebServer\PHP-5.3a3\index.php on line 9 -- Edit this bug report at http://bugs.php.net/?id=47068&edit=1
#47069 [Opn->Bgs]: Expecting T_VARIABLE in catch block
ID: 47069 Updated by: fel...@php.net Reported By: ninzya at inbox dot lv -Status: Open +Status: Bogus Bug Type: Scripting Engine problem Operating System: Windows XP PHP Version: 5.3.0alpha3 New Comment: The same to bug #47068. Thanks. Previous Comments: [2009-01-11 15:25:06] ninzya at inbox dot lv Description: See details below. This used to work with PHP 5.3.0alpha2 Reproduce code: --- index.php: 1: Expected result: No parse errors Actual result: -- Parse error: parse error, expecting `T_VARIABLE' in D:\WebServer\PHP-5.3a3\index.php on line 5 -- Edit this bug report at http://bugs.php.net/?id=47069&edit=1
#47068 [Bgs]: Parse error if global namespace resolution is used
ID: 47068 User updated by: ninzya at inbox dot lv Reported By: ninzya at inbox dot lv Status: Bogus Bug Type: Scripting Engine problem Operating System: Windows XP PHP Version: 5.3.0alpha3 New Comment: A BACKSLASH? FAIL. That's very very BAD idea. The code has become NOT readable, it looks like HDD DISK DUMP, FILE LIST, CRAP. It would be good if you change your mind about NS separator before releasing 5.3.0 and leave "::" as ns sep., or at least pick dot (".") or something, NOT BACKSLASH. I suggest you less chatting with your collegues and more chat with people when deciding about things like namespace separators. I have read your wiki, where devs suggest ":)", "^^", "**", "%%" as separators - that's not serious. What's wrong with "::"? Why it was necessary to change it to something like backslash? Backslash is the last thing u should implement in this case. I'm completely not comfortable with use of backslash as separator, and 100% of other people i guess too. Previous Comments: [2009-01-11 16:20:27] fel...@php.net Hi, the namespace separator was changed to \. http://docs.php.net/manual/en/language.namespaces.basics.php [2009-01-11 15:21:49] ninzya at inbox dot lv This used to work in PHP 5.3.0alpha2 [2009-01-11 15:20:54] ninzya at inbox dot lv Description: See details below Reproduce code: --- index.php: 1: Expected result: Passed Actual result: -- Parse error: parse error in D:\WebServer\PHP-5.3a3\index.php on line 9 -- Edit this bug report at http://bugs.php.net/?id=47068&edit=1
#47002 [Com]: Fields truncated
ID: 47002 Comment by: typoon at gmail dot com Reported By: victorjavierss at live dot com dot mx Status: Open Bug Type: dBase related Operating System: Windows PHP Version: 5.2CVS-2009-01-04 (snap) New Comment: I was unable to find a free version of dBase so I can't really create the file here to simulate the issue. Could you please post a link to a .dbf file with more than 1024 fields for me please? Put like 3 or 4 records as examples on it, just so I can do all tests. Thanks! Henrique Previous Comments: [2009-01-04 22:17:20] victorjavierss at live dot com dot mx Description: I'm executing the code belong, and it supose to retrieve me 1625 fields, but it doesn't, it give me 1024 fields, also i tried with other dbf's bigger than 1024 and the problem stills there Reproduce code: --- Expected result: 1625 Actual result: -- 1024 -- Edit this bug report at http://bugs.php.net/?id=47002&edit=1
#47002 [Opn]: Fields truncated
ID: 47002 User updated by: victorjavierss at live dot com dot mx Reported By: victorjavierss at live dot com dot mx Status: Open Bug Type: dBase related Operating System: Windows PHP Version: 5.2CVS-2009-01-04 (snap) New Comment: Here is one of the DBF's that i'm using: http://cid-d95738776c6cf0d0.skydrive.live.com/self.aspx/.Public/USAERF07.DBF as I said it retrieves me 1024 fild instead of 1625 Previous Comments: [2009-01-11 18:50:14] typoon at gmail dot com I was unable to find a free version of dBase so I can't really create the file here to simulate the issue. Could you please post a link to a .dbf file with more than 1024 fields for me please? Put like 3 or 4 records as examples on it, just so I can do all tests. Thanks! Henrique [2009-01-04 22:17:20] victorjavierss at live dot com dot mx Description: I'm executing the code belong, and it supose to retrieve me 1625 fields, but it doesn't, it give me 1024 fields, also i tried with other dbf's bigger than 1024 and the problem stills there Reproduce code: --- Expected result: 1625 Actual result: -- 1024 -- Edit this bug report at http://bugs.php.net/?id=47002&edit=1
#30924 [Com]: move_uploaded_file() misbehaves
ID: 30924 Comment by: a1bert at atlas dot cz Reported By: himself at zhwau dot net Status: No Feedback Bug Type: Filesystem function related Operating System: Windows XP PHP Version: 5.0.2 New Comment: I am experiencing simillar issue: move_uploaded_file() launches warning about: "move_uploaded_file() [function.move-uploaded-file]: open_basedir restriction in effect. File(/var/tmp/php/phpDvi4ra) is not within the allowed path(s):" but returns success and file is successfully moved (even when replacing existing file) PHP Version 5.2.0-8+etch13 Previous Comments: [2006-12-01 04:28:58] alex at mintpixels dot com oops - hit tab then space, so it submitted before I was done: if (move_uploaded_file($_FILES['worksheet_new']['tmp_name'],$location)) { echo "Success"; } else { echo "Failure"; } This prints the warning message, then "Success" when executed. [2006-12-01 04:27:36] alex at mintpixels dot com I have created a simple test case: posts to "; if (move_uploaded_file($_FILES['worksheet_new']['tmp_name'],$location)) { } [2006-12-01 04:17:49] alex at mintpixels dot com I can also confirm that this is a problem in 5.2.0. I am using move_uploaded_file to move a file from /tmp/ to /worksheets/3.jpg On the initial upload, I get no openbase_dir message, and the file writes successfully and the function returns true (as I expected). On the second upload to the file (where the file exists already), I get an openbase_dir error message in the error log and the file does not write successfully, but the function still returns a true value anyway (not as expected). I have also witnessed a case where I get no openbase_dir message and the new file writes successfully. I verified this by checking the file size had changed between requests (as I had uploaded a different file), which it had. But I am now unable to reproduce that problem. In all cases however the function is returning true. I am using PHP 5.2.0 on Apache 2.0.59 on Linux 2.6.9-42.0.2.ELsmp i686 athlon i386 GNU/Linux. The permissions of the directory/file are clearly correct because the first upload is writing correctly. I have also verified the permissions independently by doing $h=fopen("$docroot/worksheets/3.jpg"); fwrite($h,"test"); fclose($h); The file is created and contains the line as expected. In line with the guidelines, I have downloaded the latest build from CVS, and the following behaviour has changed. I now get an open_basedir warning message on the initial upload in the log, but the file is written anyway, and the function still returns true. the same behaviour persists with the second upload. [2005-02-19 01:00:21] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2005-02-11 23:20:52] tony2...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.0-win32-latest.zip The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/30924 -- Edit this bug report at http://bugs.php.net/?id=30924&edit=1
#47033 [Opn->Bgs]: converting binary<->string without charset translating
ID: 47033 Updated by: johan...@php.net Reported By: lunter at interia dot pl -Status: Open +Status: Bogus Bug Type: Unicode Engine related Operating System: all PHP Version: 6CVS-2009-01-08 (snap) New Comment: We have unicode_encode() / unicode_decode(). Previous Comments: [2009-01-08 07:42:45] lunter at interia dot pl Description: converting binary<->string without charset translating Two functions for converting binary<->string without translating charset needed. It is very usefull because binary data can consists utf-8 substring, you need to convert to string type. Also when you have to see binary representation of utf-8 string, or operating on it as binaries. Example 1: You have (binary)$b. It consists two bytes: 11001110 10110010 Its length in binary representation is two. It is also valid one-length UTF-8 char(946) (greek small letter beta) How to conver it ($b) into one-char UTF-8 string?? When we try $u=(string)$b, it gives two-char UTF-8 string. Example 2: You have (string)$u UTF-8 one-char string. It consists chr(946) (greek small letter beta) Now You have to see two bytes binary representation of this (11001110 10110010). There is no way to convert it without charset translation... Reproduce code: --- ; Unicode settings ; unicode.semantics = off unicode.runtime_encoding = iso-8859-1 unicode.script_encoding = utf-8 unicode.output_encoding = utf-8 unicode.from_error_mode = U_INVALID_SUBSTITUTE unicode.from_error_subst_char = 3f Expected result: way to converting binary<->string without charset translating Actual result: -- no way to converting binary<->string without charset translating -- Edit this bug report at http://bugs.php.net/?id=47033&edit=1
#47034 [Opn->Bgs]: Prepared-Statement fails when MySQL-Server under load
ID: 47034 Updated by: johan...@php.net Reported By: raphithom at gmx dot ch -Status: Open +Status: Bogus Bug Type: MySQLi related Operating System: FreeBSD 6.3-RELEASE-p5 PHP Version: 5.2.8 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php This error is coming from the server which has to handle it's resources. The reason PDO works is that PDO uses an emulation for prepared statements by default, falling back to simple queries. Previous Comments: [2009-01-08 09:20:51] raphithom at gmx dot ch I forgot to mention, that the mysqldumps are running on other databases, not on the one where I'm executing the prepared statement. [2009-01-08 08:57:44] raphithom at gmx dot ch Description: Hello As backup-procedure we use 4 concurrent mysql-dump processes. When these processes are running, MySQLi-Prepared-Statements can't be executed and the following error appears: Errno: 1615 Message: Prepared statement needs to be re-prepared In my opinion it doesn't seem to be a mysql-problem because prepared-statements with PDO and "normal" mysql_query() or mysqli->query() work as expected. The error doesn't occur if no mysqldumps are running. Reproduce code: --- http://tmp.raphis.ch/mysqli_problem.phps Expected result: All queries should return the same texts. Actual result: -- mysqli-select, mysql_select and PDO work as expected. mysqli-prepared statements exits with: Errno: 1615 Message: Prepared statement needs to be re-prepared -- Edit this bug report at http://bugs.php.net/?id=47034&edit=1
#47065 [Opn->Bgs]: function session_unset() reset local variables
ID: 47065 Updated by: johan...@php.net Reported By: opurahman at gmail dot com -Status: Open +Status: Bogus Bug Type: Session related Operating System: Linux PHP Version: 5.2.8 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Note: If $_SESSION (or $HTTP_SESSION_VARS for PHP 4.0.6 or less) is used, use unset() to unregister a session variable, i.e. unset ($_SESSION['varname']);. session_unset() is to be ued when using register_globals() which is not advised. Previous Comments: [2009-01-11 08:37:22] opurahman at gmail dot com Description: function session_unset() reset local variables. I was trying to reset session variables after storing two values from session. It reset my local variables. Lets take a look into the codes bellow. Reproduce code: --- session_start(); $message = sprintf('%s', $_SESSION['message']); echo('Here Message: # ' . $message . ''); session_unset(); echo('Here Message: # ' . $message . ''); // in this line, the variable $message has been unset. Expected result: It should display the value of $message -- Edit this bug report at http://bugs.php.net/?id=47065&edit=1
#36853 [Com]: Worker process crashes after application pool recycle
ID: 36853 Comment by: sdavey at datalink dot com dot au Reported By: kleef84 at hotmail dot com Status: No Feedback Bug Type: IIS related Operating System: Windows Server 2003 SP1 PHP Version: 5CVS-2006-03-24 (CVS) New Comment: There have been a few bugs reported for this issue over a few years, and the most current and active one seems to be Bug #38111. I suggest everyone head over there and votes for it. It is also open and awaiting a backtrace. The problem appears that the crash is not directly the result of PHP code being executed, but rather the result of IIS cleaning up worker proccesses with PHP ISAPI running in them and DEP preventing some code execution at that time. This makes generating a backtrace difficult, and thus the bug has been around for a number of years. To help people with this issue, a number of workarounds have been discovered over the years: - Add w3wp.exe to DEP exclusion list - Turn off process recycling in IIS - Use FastCGI rather than ISAPI Previous Comments: [2007-05-24 17:44:21] linhardt at aol dot com I have this problem too, but it has nothing to do with PHP as I'm running ASP.NET. My environment is: MS Windows 2003 Server + SP2 IIS 6.0.3790.3959 .NET 2.0.50727 I get both: Faulting application w3wp.exe, version 6.0.3790.1830, faulting module unknown, version 0.0.0.0, fault address 0x01bba980. and Data Execution Prevention Microsoft Windows To help protect your computer, Windows has closed this program. Name: IIS Worker Process Publisher: program publisher [2006-10-18 01:32:46] kamikazie at comcast dot net I've noticed this error, too, but only after a PHP page has been loaded. Same basic setup as most, Server 2003, IIS 6, PHP 5.1.4, painstakingly followed the setup instructions. Now a webpage that loads only HTML does not give this error. When I load a page that calls PHP, it throws this error about 5 to 10 minutes after the first page is loaded. [2006-07-12 14:25:19] ferrante at aracnet dot com Windows 2003 Server, IIS6, .NET 1.1 & .NET 2.0, php5.2-win32-200607120630 from the snapshots. (Fully Microsoft patched Windows 2003 server machine). Even with all PHP dynamic extensions turned off, crash occurs during IISreset or w3svc service restart. Event as it appears in event log: Event Type: Error Event Source: Application Error Event Category: (100) Event ID: 1000 Date: 07/12/2006 Time: 06:26:45 User: N/A Computer: COMPUTER-NAME Description: Faulting application w3wp.exe, version 6.0.3790.1830, faulting module unknown, version 0.0.0.0, fault address 0x01bba980. For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp. Data: : 41 70 70 6c 69 63 61 74 Applicat 0008: 69 6f 6e 20 46 61 69 6c ion Fail 0010: 75 72 65 20 20 77 33 77 ure w3w 0018: 70 2e 65 78 65 20 36 2e p.exe 6. 0020: 30 2e 33 37 39 30 2e 31 0.3790.1 0028: 38 33 30 20 69 6e 20 75 830 in u 0030: 6e 6b 6e 6f 77 6e 20 30 nknown 0 0038: 2e 30 2e 30 2e 30 20 61 .0.0.0 a 0040: 74 20 6f 66 66 73 65 74 t offset 0048: 20 30 31 62 62 61 39 3801bba98 0050: 300 Visual Studio 2005 Debugger gives this for the stack trace: *1 01bba980() 2 msvcrt.dll!__endthread() 3 kernel32.dll!_basethreadst...@8() WinDBG gives this: +0x26a980 msvcrt!endthread+0xab kernel32!GetModuleFileNameA+0xeb the Debug Diagnostic Tool gives this Function Arg 1 Arg 2 Arg 3 Source +26a980 01782ee8 msvcrt!endthread+ab 02108c80 kernel32!GetModuleFileNameA+eb 77bcb35a 02108c80 [2006-07-12 09:54:10] ferrante at aracnet dot com These are related issues that seem to be describing the same problem: Bug #33373 IIS worker Process continually restarts Bug #37575 Faulting application w3wp.exe Bug #35263 Crash during IIS Restart Adding the w3wp.exe process to the DEP exception list will also mask the problem. [2006-05-28 17:42:23] sschefer at scheferonline dot net Deeper investigation of the problem indicates that the reason you are now getting this is because of .NET 2.0. In verison 1.0 and 1.1 it did not throw this exception because it was set to ignore it. If you don't have any security issues, you could probably just ignore them and be O.K. That would not be my choice. The solution is to recompile the DLL's (all of them) with Visual Studio 8. This will then correctly place them within the scope of the IIS authorized extension list. Workaround, back
#38111 [Com]: PHP crashes IIS worker process and application pool
ID: 38111 Comment by: scott at datalink dot com dot au Reported By: svendavidh at hotmail dot com Status: No Feedback Bug Type: IIS related Operating System: Windows Server 2003 Std. Ed. R2 PHP Version: 5.2.8 Assigned To: pajoye New Comment: To help people with this issue, I've scanned all the PHP bugs relating to this issue and collated a list of workarounds: - Add w3wp.exe to DEP exclusion list - Turn off process recycling - Use FastCGI rather than ISAPI To the PHP team - you guys are great and I love your work. I know you haven't gotten the backtrace, but please don't mark this bug as bogus. The community is trying to get what you need and have been very patient with this issue, but it appears to be difficult to get because of the way it crashes. Previous Comments: [2009-01-09 22:17:18] damon at clarkweb dot com Same problems with PHP 5.2.8 on Vista SP1. Following SIKLE's steps reproduces the bug every time. This has been open far too long for an easily reproducable bug. Please address! [2009-01-04 10:46:52] sikle at stx dot net Oh here's a 100% repro: 1. Load a php program. For example, I just go to http://localhost/phpmyadmin, I then logon to my database, and then I just close the browser. 2. Now go into IIS, on the left side double click on the computer name and then you'll see "Application Pools", now click on it. 3. Now click on "DefaultAppPool" and then on the right side of the screen you'll see "Recycle..." click on it. Now after you clicked on "Recycle...", within about 4 seconds you'll see the crash: "IIS Worker Process has stopped working". Whoever fixes this bug will be my personal hero. [2009-01-04 10:31:17] sikle at stx dot net Dear programmers, Please fix this bug :~( (with a cherry on top?) I'm on PHP 5.2.8 and it happens all the time (on average 5-6 times a day) and it's very annoying. Like the others have mentioned I assume this is a memory bug that is triggered when IIS recycles its application pool. [2008-12-27 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". [2008-12-22 02:41:45] todd at lanlocked dot net Just following up: I believe it is 1740 seconds, not minutes I am running IIS 7 on Server 2008 Std 64 bit PHP is running outside of the default app pool, although in trying to resolve the issue I set it up with the default app pool and it did the same thing Could someone let me know how to backtrace the correct process (I assume I have to backtrace an IIS worker process) and we can get it sorted? 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/38111 -- Edit this bug report at http://bugs.php.net/?id=38111&edit=1
#38111 [NoF]: PHP crashes IIS worker process and application pool
ID: 38111 Updated by: paj...@php.net Reported By: svendavidh at hotmail dot com Status: No Feedback Bug Type: IIS related Operating System: Windows Server 2003 Std. Ed. R2 PHP Version: 5.2.8 Assigned To: pajoye New Comment: "- Use FastCGI rather than ISAPI" that's definitively the way to go :) Previous Comments: [2009-01-11 23:44:21] scott at datalink dot com dot au To help people with this issue, I've scanned all the PHP bugs relating to this issue and collated a list of workarounds: - Add w3wp.exe to DEP exclusion list - Turn off process recycling - Use FastCGI rather than ISAPI To the PHP team - you guys are great and I love your work. I know you haven't gotten the backtrace, but please don't mark this bug as bogus. The community is trying to get what you need and have been very patient with this issue, but it appears to be difficult to get because of the way it crashes. [2009-01-09 22:17:18] damon at clarkweb dot com Same problems with PHP 5.2.8 on Vista SP1. Following SIKLE's steps reproduces the bug every time. This has been open far too long for an easily reproducable bug. Please address! [2009-01-04 10:46:52] sikle at stx dot net Oh here's a 100% repro: 1. Load a php program. For example, I just go to http://localhost/phpmyadmin, I then logon to my database, and then I just close the browser. 2. Now go into IIS, on the left side double click on the computer name and then you'll see "Application Pools", now click on it. 3. Now click on "DefaultAppPool" and then on the right side of the screen you'll see "Recycle..." click on it. Now after you clicked on "Recycle...", within about 4 seconds you'll see the crash: "IIS Worker Process has stopped working". Whoever fixes this bug will be my personal hero. [2009-01-04 10:31:17] sikle at stx dot net Dear programmers, Please fix this bug :~( (with a cherry on top?) I'm on PHP 5.2.8 and it happens all the time (on average 5-6 times a day) and it's very annoying. Like the others have mentioned I assume this is a memory bug that is triggered when IIS recycles its application pool. [2008-12-27 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/38111 -- Edit this bug report at http://bugs.php.net/?id=38111&edit=1
#47070 [NEW]: php_stream_locate_url_wrapper fails without authority section
From: darrel dot opry at gmail dot com Operating system: Ubuntu 8.10 PHP version: 5.2.8 PHP Bug Type: Streams related Bug description: php_stream_locate_url_wrapper fails without authority section Description: php_stream_locate_url_wrapper fails without authority section. If a URL is not in the Common Internet Scheme Syntax (scheme://<:@>host<:port>/url-path) the scheme is not be located properly. So URLs of scheme:relative/path and scheme:/absolute/path will not be handled by the registered user defined stream wrapper. see http://www.ietf.org/rfc/rfc1738.txt for URL specific syntax. see section 3 of http://labs.apache.org/webarch/uri/rfc/rfc3986.html#intro for URI syntax. Reproduce code: --- public:path/file.txt [1] => r+ [2] => 4 [3] => ) Array ( [0] => public:/path/file.txt [1] => r+ [2] => 4 [3] => ) Array ( [0] => public://path/file.txt [1] => r+ [2] => 4 [3] => ) Actual result: -- Warning: fopen(public:path/file.txt): failed to open stream: No such file or directory in /home/dopry/public_html/drupal-media/sites/default/modules/media/resource/test.php on line 13 Warning: fopen(public:/path/file.txt): failed to open stream: No such file or directory in /home/dopry/public_html/drupal-media/sites/default/modules/media/resource/test.php on line 14 Array ( [0] => public://path/file.txt [1] => r+ [2] => 4 [3] => ) -- Edit bug report at http://bugs.php.net/?id=47070&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47070&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47070&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47070&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47070&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47070&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47070&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47070&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47070&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47070&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47070&r=support Expected behavior: http://bugs.php.net/fix.php?id=47070&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47070&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47070&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47070&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47070&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47070&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47070&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47070&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47070&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47070&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47070&r=mysqlcfg
#42060 [Com]: [PATCH] Add pagedResults support and more (PAT18 and PAT19 updated for 5.2.3)
ID: 42060 Comment by: Tyron dot Delean at unisa dot edu dot au Reported By: iarenuno at eteo dot mondragon dot edu Status: Assigned Bug Type: LDAP related Operating System: * PHP Version: 5CVS, 6CVS (2008-11-01) Assigned To: pajoye New Comment: I really really really really need Paging support for PHP LDAP calls. This is a super super super high priority for me to get an App working. Could somebody please tell me when the support for Paged Results from LDAP calls will be available, and what version of PHP will support it. I have checked the latest source versions for PHP 5.3 & PHP 6.0 snapshots and can't see it in there. I hope I am missing something. Extremely concerned. Tyron Previous Comments: [2009-01-03 20:48:50] nelg at linuxsolutions dot co dot nz Hi, I am really keen to see this patch applied, as without it, the is some things that cannot easily be done in LDAP with PHP. Any progress? last comment seems to indicate it was going to be committed soon, but I don't see it in the php source tree yet. [2008-11-16 23:22:00] iarenuno at eteo dot mondragon dot edu pajoye, thanks a lot for your work to get this patch into core. This was a much needed feature in big LDAP installations. Saludos. Iñaki. [2008-11-16 14:57:56] paj...@php.net Alexey has ported the patch to 5.3, it will committed in the next days. [2008-11-16 14:24:12] aklmnop at gmail dot com It would be great to have this essential paging functionality, and it's about time to update PHP's ldap. LDAP isn't going anywhere, and this has been waiting for long enough. Just because a myopic maintainer doesn't use LDAP doesn't mean it's not extremely widespread, urgent and important. Thanks. [2008-07-17 13:00:37] ando at sys-net dot it I didn't get any notification about this message, so I overlooked it; I was pointed here by a user (like many others) interested in the functionalities provided by the patch. In the meanwhile, I noticed that the code, after more than 2 years of inactivity, is now incompatible with the patch. Fixing it will require an amount of time that is incompatible with my current schedule. Feel free to fix it yourself. Cheers, p. 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/42060 -- Edit this bug report at http://bugs.php.net/?id=42060&edit=1
#47071 [NEW]: Charset problem
From: freelas at gmail dot com Operating system: all PHP version: 5.2.8 PHP Bug Type: SimpleXML related Bug description: Charset problem Description: In response for a bug 40433. Specially for chr...@php.net Sorry, but I'm thinking you're stupid. You can't see the problem that this wrong behaviour it's causing and you're replying this as a man tha has crap on brain and not have a minimum respect. UTF-8 isn't the unique charset in the world and PHP language can loose some programmers and enterprises who likes this language cause you do a stupid response for a stupid bug instead of rethinking it. If the libxml2 doesn't support at least the charsets most used in the world and you change to this lib you aren't thinking who this causes to us and to you. And it isn't documented on SimpleXML manual. I use this class in a big project. I'm using iso-8859-1 and I was affected for this BUG (yes. for me and for a lot of programmers a wrong behaviour is a bug even it was thinked before relese it). But I look at the problem later and I needed to do a stupid conversion always decreasing the system performance. Learn to speak correctly with your clients before reply a bug. Programmers make enterprise decisions for what language use to code a system, programmers buy PHP books, help your code, submit bugs, buy certifications, zend features and others thinks. Then, respect us. -- Edit bug report at http://bugs.php.net/?id=47071&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47071&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47071&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47071&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47071&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47071&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47071&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47071&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47071&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47071&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47071&r=support Expected behavior: http://bugs.php.net/fix.php?id=47071&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47071&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47071&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47071&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47071&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47071&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47071&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47071&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47071&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47071&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47071&r=mysqlcfg
#47065 [Bgs]: function session_unset() reset local variables
ID: 47065 User updated by: opurahman at gmail dot com Reported By: opurahman at gmail dot com Status: Bogus Bug Type: Session related Operating System: Linux PHP Version: 5.2.8 New Comment: OK then delete this topic please. Previous Comments: [2009-01-11 22:31:21] johan...@php.net Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Note: If $_SESSION (or $HTTP_SESSION_VARS for PHP 4.0.6 or less) is used, use unset() to unregister a session variable, i.e. unset ($_SESSION[\'varname\']);. session_unset() is to be ued when using register_globals() which is not advised. [2009-01-11 08:37:22] opurahman at gmail dot com Description: function session_unset() reset local variables. I was trying to reset session variables after storing two values from session. It reset my local variables. Lets take a look into the codes bellow. Reproduce code: --- session_start(); $message = sprintf('%s', $_SESSION['message']); echo('Here Message: # ' . $message . ''); session_unset(); echo('Here Message: # ' . $message . ''); // in this line, the variable $message has been unset. Expected result: It should display the value of $message -- Edit this bug report at http://bugs.php.net/?id=47065&edit=1
#47071 [Opn->Csd]: Charset problem
ID: 47071 User updated by: freelas at gmail dot com Reported By: freelas at gmail dot com -Status: Open +Status: Closed Bug Type: SimpleXML related Operating System: all PHP Version: 5.2.8 New Comment: ? Previous Comments: [2009-01-12 06:09:08] freelas at gmail dot com Description: In response for a bug 40433. Specially for chr...@php.net Sorry, but I'm thinking you're stupid. You can't see the problem that this wrong behaviour it's causing and you're replying this as a man tha has crap on brain and not have a minimum respect. UTF-8 isn't the unique charset in the world and PHP language can loose some programmers and enterprises who likes this language cause you do a stupid response for a stupid bug instead of rethinking it. If the libxml2 doesn't support at least the charsets most used in the world and you change to this lib you aren't thinking who this causes to us and to you. And it isn't documented on SimpleXML manual. I use this class in a big project. I'm using iso-8859-1 and I was affected for this BUG (yes. for me and for a lot of programmers a wrong behaviour is a bug even it was thinked before relese it). But I look at the problem later and I needed to do a stupid conversion always decreasing the system performance. Learn to speak correctly with your clients before reply a bug. Programmers make enterprise decisions for what language use to code a system, programmers buy PHP books, help your code, submit bugs, buy certifications, zend features and others thinks. Then, respect us. -- Edit this bug report at http://bugs.php.net/?id=47071&edit=1