#40478 [Opn]: skype dll problem Skype4COM.dll
ID: 40478 User updated by: virals at meditab dot in Reported By: virals at meditab dot in Status: Open Bug Type: COM related Operating System: windows xp PHP Version: 5.2.1 New Comment: Tony..r u busy with some other work i m waiting for the answer. Previous Comments: [2007-02-15 04:57:44] virals at meditab dot in ok. Actually i was giving the descriptio Skype4Com.dll : Skype4COM represents the Skype API as objects, with: methods properties events collections caching Skype4COM provides an ActiveX interface to the Skype API. Develop for Skype in a familiar programming environment, such as Visual Studio or Delphi, using preferred scripting languages such as VBScript, PHP, or Javascript. Requirements: Skype 3.0 must be installed Windows 2000 or Windows XP And this .dll provide so many methods and classes bt i am not able to call any of it. Whichever function of api i am calling it is giving me the same error. So there must be something missing from PHP side. hey how i can send you the .chm help file of Skype4Com? [2007-02-14 14:34:25] [EMAIL PROTECTED] I'm sorry, I don't understand your last comment. [2007-02-14 14:25:15] virals at meditab dot in as i guess it is php problem only because this file is supported for Visual Studio or Delphi, using preferred scripting languages such as VBScript, PHP, or Javascript. .vbs .php .js .cs And there are plenty of function available and if i used any of it, it is giving the same error. [2007-02-14 12:01:23] [EMAIL PROTECTED] >Thanks for your quick reply but the same code and dll is >working with javascript It doesn't mean you should be able to connect from PHP, since it's completely different thing (and web-servers usually run with different privileges etc.). The error message and the exception look quite safe to me and I'm still not sure it's PHP problem. [2007-02-14 11:12:42] virals at meditab dot in Thanks for your quick reply but the same code and dll is working with javascript. but i don't know y it is not working with PHP. Cant we find whether it is PHP or skype problem. Is i missed something at php configuration. I dont want to use javascript because it is only working with IE for other browser they are working. 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/40478 -- Edit this bug report at http://bugs.php.net/?id=40478&edit=1
#40421 [Com]: Install error 2343
ID: 40421 Comment by: klearity at lycos dot ca Reported By: wade_link at hotmail dot com Status: Assigned Bug Type: Unknown/Other Function Operating System: XP Pro PHP Version: 5.2.1 Assigned To: jmertic New Comment: I have the same problem. I downloaded the fix version but I still get the error. I do not know where to find the error log so I can email it to the address given. Where do I find this? Previous Comments: [2007-02-16 16:04:04] wade_link at hotmail dot com Still got the same error at the same point of writing INI files. [2007-02-15 19:41:53] [EMAIL PROTECTED] Please try the latest build. If you are still having problems, email the error.log file produced from the following to [EMAIL PROTECTED] >From the command line in the directory where you downloaded the installer: msiexec /i php-5.2.1-win32-installer.msi /l*v error.log [2007-02-10 00:09:58] wade_link at hotmail dot com It worked sort of. It got most of the way through the intall then errored. It had the same error message. It gets through a lot, but the error message shows up when it says it is writing INI files. [2007-02-09 23:37:58] [EMAIL PROTECTED] Please try: http://downloads.php.net/edink/php-5.2.1-win32-installer-fix.msi [2007-02-09 23:24:34] [EMAIL PROTECTED] So 5.2.1 _probably_ works fine, but you can't test it because you cannot uninstall the previous version. Consult your OS support on how to force the uninstall? 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/40421 -- Edit this bug report at http://bugs.php.net/?id=40421&edit=1
#29846 [Com]: Function to close the output stream
ID: 29846 Comment by: duerra at yahoo dot com Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Feature/Change Request Operating System: Irrelevant PHP Version: 5.0.1 New Comment: I am definitely looking for the pre PHP 4.1 functionality of the register_shutdown_function() to be reintroduced, even if in a different form. One possibility would be to include a standard function to the effect of close_remote_connection(); which would then allow the script to continue executing, while flushing any remaining data to the user's browser and closing the connection. This functionality has any number of useful purposes, where (potentially time consuming) processing may need to be continued, but where it is not relevant to any data being output to the end user. They should not need to wait around for the processing to finish, and other workarounds and hacks to accomplishing this are inconvenient or not always very practical. Please, please reintroduce some functionality to allow for this type of purpose! Previous Comments: [2004-08-27 11:24:27] [EMAIL PROTECTED] There is a patch for similar function by Joseph Tate at http://marc.theaimsgroup.com/?l=php-dev&m=104092438811407&w=2 [2004-08-27 00:06:04] [EMAIL PROTECTED] See also bug #15209 [2004-08-26 11:51:31] [EMAIL PROTECTED] Description: Introduce function to force PHP to close the output stream so slower non user related functions can be executed. -- Edit this bug report at http://bugs.php.net/?id=29846&edit=1
#40513 [Opn->Bgs]: Notice: Unknown: List index out of bounds (0) (errflg=2) in Unknown on line 0
ID: 40513
Updated by: [EMAIL PROTECTED]
Reported By: wil at codeciti dot com
-Status: Open
+Status: Bogus
Bug Type: IMAP related
-Operating System: WinXP Pro
+Operating System: WinXP
PHP Version: 5.2.1
New Comment:
The error messages you see are coming from c-client library.
Unfortunately we can't fix and/or change it, since it's a third party
library.
Previous Comments:
[2007-02-16 23:27:18] wil at codeciti dot com
Changed it to winxp pro
[2007-02-16 20:32:13] wil at codeciti dot com
Description:
When I try to move mail from one directory to another I get that notice
and on the mail server log it tells me that the command is invalid and
ignores it.
Notice: Notice: Unknown: List index out of bounds (0) (errflg=2) in
Unknown on line 0
Reproduce code:
---
'1', 1 => '2', 2 => '3');
$messageset = implode(',',$arr);
imap_mail_move($Link, $messageset, 'Trash');
imap_close($Link);
?>
Expected result:
Should move the mail from the current folder to the trash.
Actual result:
--
Nothing gets moved it just echos that notice statement.
--
Edit this bug report at http://bugs.php.net/?id=40513&edit=1
#40513 [Opn]: Notice: Unknown: List index out of bounds (0) (errflg=2) in Unknown on line 0
ID: 40513
User updated by: wil at codeciti dot com
Reported By: wil at codeciti dot com
Status: Open
Bug Type: IMAP related
-Operating System: WinXP
+Operating System: WinXP Pro
PHP Version: 5.2.1
New Comment:
Changed it to winxp pro
Previous Comments:
[2007-02-16 20:32:13] wil at codeciti dot com
Description:
When I try to move mail from one directory to another I get that notice
and on the mail server log it tells me that the command is invalid and
ignores it.
Notice: Notice: Unknown: List index out of bounds (0) (errflg=2) in
Unknown on line 0
Reproduce code:
---
'1', 1 => '2', 2 => '3');
$messageset = implode(',',$arr);
imap_mail_move($Link, $messageset, 'Trash');
imap_close($Link);
?>
Expected result:
Should move the mail from the current folder to the trash.
Actual result:
--
Nothing gets moved it just echos that notice statement.
--
Edit this bug report at http://bugs.php.net/?id=40513&edit=1
#40504 [Opn->Bgs]: PDO syntax hinders Informix functionality.
ID: 40504 Updated by: [EMAIL PROTECTED] Reported By: iani at us dot ibm dot com -Status: Open +Status: Bogus Bug Type: PDO related Operating System: ALL PHP Version: 5.2.1 New Comment: One report is enough, thank you. No need to report it twice. Previous Comments: [2007-02-16 06:40:17] iani at us dot ibm dot com Description: Please see pecl bug - http://pecl.php.net/bugs/bug.php?id=7033 Reproduce code: --- http://pecl.php.net/bugs/bug.php?id=7033 -- Edit this bug report at http://bugs.php.net/?id=40504&edit=1
#40509 [Opn->Asn]: key() function changed behaviour if global array is used within function
ID: 40509
Updated by: [EMAIL PROTECTED]
Reported By: alex dot killing at gmx dot de
-Status: Open
+Status: Assigned
Bug Type: Arrays related
Operating System: MaxOsX/RedHat
PHP Version: 5.2.1
-Assigned To:
+Assigned To: dmitry
Previous Comments:
[2007-02-16 15:24:36] alex dot killing at gmx dot de
Description:
If a global array is assigned to a local variable as in the example,
and the local variable is iterated afterwards, the key() function
changed the behaviour in the global scope with PHP 5.2.1.
Reproduce code:
---
-".key($arr["v"])."-"; // prints "" since 5.2.1 ("0" on all
prior versions)
?>
Expected result:
-0-
-0-
Actual result:
--
-0-
--
--
Edit this bug report at http://bugs.php.net/?id=40509&edit=1
#40508 [Opn->Asn]: Namespace xpath doesn't work for nested elements
ID: 40508
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Assigned
Bug Type: SimpleXML related
Operating System: Windows
PHP Version: 5.2.1
-Assigned To:
+Assigned To: helly
Previous Comments:
[2007-02-16 13:21:46] [EMAIL PROTECTED]
Description:
Registering XPath namespace works only for XPath queries from root
element.
Reproduce code:
---
$text = 'http://example.org";>test';
$xml = simplexml_load_string($text);
// register in root
$xml->registerXPathNamespace("x", "http://example.org";);
print_r($xml->b->xpath("x:c"));
// register in nested element
$xml->b->registerXPathNamespace("x", "http://example.org";);
print_r($xml->b->xpath("x:c"));
Expected result:
At least once:
Array
(
[0] => SimpleXMLElement Object
(
[0] => test
)
)
Actual result:
--
Warning: SimpleXMLElement::xpath(): Undefined namespace prefix
Warning: SimpleXMLElement::xpath(): Undefined namespace prefix
--
Edit this bug report at http://bugs.php.net/?id=40508&edit=1
#40507 [Opn->Sus]: php install probem
ID: 40507 Updated by: [EMAIL PROTECTED] Reported By: armin at xos dot net -Status: Open +Status: Suspended Bug Type: Unknown/Other Function Operating System: solaris 2.9 64 bit PHP Version: 5.2.1 Previous Comments: [2007-02-16 20:38:30] armin at xos dot net well the gcc people told me so - sorry. -fno-strict-aliasing seems to be enough to not segfault. this workaround id not magical. please read the gcc bug report above. i tried the ltrim patch. it's the same with or without. thanks for trying to reproduce it. [2007-02-16 13:00:28] [EMAIL PROTECTED] >i used the suggested compile flags and no segmentation >fault anymore, which shows it's a php bug It doesn't sound too convincing. And the fact that the problem is reproducible ONLY on Sparc and ONLY using GCC 4.x makes me wonder what made you think so. >please add "-fno-strict-aliasing and/or -fwrapv" to the >c-flags for solaris 2.9 64bit I would prefer to find the roots of the problem instead of applying some magical workaround. >however: how to fix the Phar archive problem? Let me see if I can reproduce it with working GCC. [2007-02-16 12:22:06] armin at xos dot net Description: related to: http://bugs.php.net/bug.php?id=39418 i had the same problem and submitted a bug report with gcc. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30819 i used the suggested compile flags and no segmentation fault anymore, which shows it's a php bug - probably since i get following during make install: /usr/local/src/apache_etc/php-5.2.1_error/sapi/cli/php -n -dshort_open_tag=0 -dsafe_mode=0 -dopen_basedir= -derror_reporting=E_ALL -dmemory_limit=-1 -ddetect_unicode=0 pear/install-pear-nozlib.phar -d "/usr/local/lib/php" -b "/usr/local/bin" Warning: unpack(): Type V: not enough input, need 4, have 0 in /usr/local/src/apache_etc/php-5.2.1_error/pear/install-pear-nozlib.phar on line 339 Notice: Uninitialized string offset: 0 in /usr/local/src/apache_etc/php-5.2.1_error/pear/install-pear-nozlib.phar on line 342 Notice: Uninitialized string offset: 1 in /usr/local/src/apache_etc/php-5.2.1_error/pear/install-pear-nozlib.phar on line 342 Notice: Uninitialized string offset: 2 in /usr/local/src/apache_etc/php-5.2.1_error/pear/install-pear-nozlib.phar on line 342 Notice: Uninitialized string offset: 0 in /usr/local/src/apache_etc/php-5.2.1_error/pear/install-pear-nozlib.phar on line 343 Fatal error: Phar is API version 0.0.0, but PHP_Archive is API version 0.8.0 in /usr/local/src/apache_etc/php-5.2.1_error/pear/install-pear-nozlib.phar on line 353 please add "-fno-strict-aliasing and/or -fwrapv" to the c-flags for solaris 2.9 64bit however: how to fix the Phar archive problem? -- Edit this bug report at http://bugs.php.net/?id=40507&edit=1
#40507 [Fbk->Opn]: php install probem
ID: 40507 User updated by: armin at xos dot net Reported By: armin at xos dot net -Status: Feedback +Status: Open Bug Type: Unknown/Other Function Operating System: solaris 2.9 64 bit PHP Version: 5.2.1 New Comment: well the gcc people told me so - sorry. -fno-strict-aliasing seems to be enough to not segfault. this workaround id not magical. please read the gcc bug report above. i tried the ltrim patch. it's the same with or without. thanks for trying to reproduce it. Previous Comments: [2007-02-16 13:00:28] [EMAIL PROTECTED] >i used the suggested compile flags and no segmentation >fault anymore, which shows it's a php bug It doesn't sound too convincing. And the fact that the problem is reproducible ONLY on Sparc and ONLY using GCC 4.x makes me wonder what made you think so. >please add "-fno-strict-aliasing and/or -fwrapv" to the >c-flags for solaris 2.9 64bit I would prefer to find the roots of the problem instead of applying some magical workaround. >however: how to fix the Phar archive problem? Let me see if I can reproduce it with working GCC. [2007-02-16 12:22:06] armin at xos dot net Description: related to: http://bugs.php.net/bug.php?id=39418 i had the same problem and submitted a bug report with gcc. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30819 i used the suggested compile flags and no segmentation fault anymore, which shows it's a php bug - probably since i get following during make install: /usr/local/src/apache_etc/php-5.2.1_error/sapi/cli/php -n -dshort_open_tag=0 -dsafe_mode=0 -dopen_basedir= -derror_reporting=E_ALL -dmemory_limit=-1 -ddetect_unicode=0 pear/install-pear-nozlib.phar -d "/usr/local/lib/php" -b "/usr/local/bin" Warning: unpack(): Type V: not enough input, need 4, have 0 in /usr/local/src/apache_etc/php-5.2.1_error/pear/install-pear-nozlib.phar on line 339 Notice: Uninitialized string offset: 0 in /usr/local/src/apache_etc/php-5.2.1_error/pear/install-pear-nozlib.phar on line 342 Notice: Uninitialized string offset: 1 in /usr/local/src/apache_etc/php-5.2.1_error/pear/install-pear-nozlib.phar on line 342 Notice: Uninitialized string offset: 2 in /usr/local/src/apache_etc/php-5.2.1_error/pear/install-pear-nozlib.phar on line 342 Notice: Uninitialized string offset: 0 in /usr/local/src/apache_etc/php-5.2.1_error/pear/install-pear-nozlib.phar on line 343 Fatal error: Phar is API version 0.0.0, but PHP_Archive is API version 0.8.0 in /usr/local/src/apache_etc/php-5.2.1_error/pear/install-pear-nozlib.phar on line 353 please add "-fno-strict-aliasing and/or -fwrapv" to the c-flags for solaris 2.9 64bit however: how to fix the Phar archive problem? -- Edit this bug report at http://bugs.php.net/?id=40507&edit=1
#40512 [Opn->Bgs]: debug_backtrace() bug ?
ID: 40512 Updated by: [EMAIL PROTECTED] Reported By: potramihai at yahoo dot com -Status: Open +Status: Bogus Bug Type: Class/Object related Operating System: Linux PHP Version: 5.2.1 New Comment: Do not file bugs when you have Zend extensions (zend_extension=) loaded. Examples are Zend Optimizer, Zend Debugger, Turck MM Cache, APC, Xdebug and ionCube loader. These extensions often modify engine behavior which is not related to PHP itself. Previous Comments: [2007-02-16 20:18:17] potramihai at yahoo dot com Description: Hello, I have recently encountered a serious problem with the debug_backtrace() function which is specified to be in the php core. I've run the same script on my machine which is on windows and it returns the "object" item correctly. However, on my hosting company I've tried it and doesn't return such an item at all. They have PHP 5.1.1 as CGI and PHP 5.2.1 as Apache Module. When this first happened they moved my account from the CGI to the Apache Module, but the same thing happens. I've searched on google and throughout the whole documentation in order to understand why the debug_backtrace() won't return any "object" field on their server. I didn't find any specific php configuration to stop this function from returning the "object" field. I've tried even a simple code with one class C1 calling a function on class C2 which print_r(debug_backtrace()). You can see the result at http://www.getsocial.co.uk/test/t1.php and the PHP info at http://www.getsocial.co.uk/test/phpinfo.php and the code used to reproduce at http://www.getsocial.co.uk/test/code.php This works on my PHP 5.2.1 Windows Box. I am looking forward to any suggestions or details regarding this issue. The hosting company has already agreed to offer any information that might help detect the source of this, in what regards the configurations. Sincerely, Mihai Potra Reproduce code: --- http://www.getsocial.co.uk/test/code.php Expected result: Get an "object" field on running debug_backtrace(); Actual result: -- http://www.getsocial.co.uk/test/t1.php -- Edit this bug report at http://bugs.php.net/?id=40512&edit=1
#40513 [NEW]: Notice: Unknown: List index out of bounds (0) (errflg=2) in Unknown on line 0
From: wil at codeciti dot com
Operating system: WinXP
PHP version: 5.2.1
PHP Bug Type: IMAP related
Bug description: Notice: Unknown: List index out of bounds (0) (errflg=2) in
Unknown on line 0
Description:
When I try to move mail from one directory to another I get that notice
and on the mail server log it tells me that the command is invalid and
ignores it.
Notice: Notice: Unknown: List index out of bounds (0) (errflg=2) in
Unknown on line 0
Reproduce code:
---
'1', 1 => '2', 2 => '3');
$messageset = implode(',',$arr);
imap_mail_move($Link, $messageset, 'Trash');
imap_close($Link);
?>
Expected result:
Should move the mail from the current folder to the trash.
Actual result:
--
Nothing gets moved it just echos that notice statement.
--
Edit bug report at http://bugs.php.net/?id=40513&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=40513&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=40513&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=40513&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=40513&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=40513&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=40513&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=40513&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=40513&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=40513&r=support
Expected behavior:http://bugs.php.net/fix.php?id=40513&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=40513&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=40513&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=40513&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40513&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=40513&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=40513&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=40513&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=40513&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=40513&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=40513&r=mysqlcfg
#16263 [Com]: session.start() create new empty session file and not resume existing session
ID: 16263 Comment by: general at itpsg dot com Reported By: kur at natur dot cuni dot cz Status: No Feedback Bug Type: Session related Operating System: ANY PHP Version: 4.3.0-dev New Comment: I am having the same problem. I have tried all the suggestions here. One system is fedora core 4 the other is fedora core 5. Updating the packages does not help. Setting charset does not help. Adding 0; to the save_path does not help. The save path has the appropriate permissions. The session file is created but always empty. Using session_write_close has no effect. We developed the application, fully tested, went to deploy and now this is blowing everything up...ouch! Previous Comments: [2007-02-07 09:35:10] morten at vianett dot no Same problem using v5.2.0 I get empty sess_ files in /tmp I have had this problem many times before. It seems that it works if its installed on a sunny day.. [2007-01-18 19:20:45] par at tor dot se Try to change this: session.save_path = "0;c:\program files\php\tmp" don't forget to use the 0; before the path. [2006-12-24 13:18:44] barts at time dot net dot my PHP 5.1.4 Windows NT SERVER 5.1 build 2600 Possible workarounds installed as mentioned in the thread. I also noticed that the session cookie is not updated when another pages is loaded that contains session_start(); This causes the session always to expire after its lifetime, where I expect the session to expire after the last session_start + lifetime. [2006-12-02 05:00:24] michaellai2006 at yahoo dot com Same thing for 5.1.16 I tried other people's suggestion, did not work for me neither. Please give a workaround. [2006-12-02 04:51:44] failmore at yahoo dot com Similar problem happend to me. The following is my configuration: Apache 2.2.3, PHP 5.1.16 I tried three different browsers, IE, FireFox, Maxthon same error happens. I host the website on my local machine, Win XP Home, therefore, I try to access the site using http://localhost/testsite add default_charset = "iso-8859-1"; in php.ini, did not work set setting cookie_domain=localhost did not work set session.use_trans_sid on did not work. 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/16263 -- Edit this bug report at http://bugs.php.net/?id=16263&edit=1
#40511 [Opn->Bgs]: __destruct() does not destroy vars $var
ID: 40511
Updated by: [EMAIL PROTECTED]
Reported By: afuzaylov at mlgpro dot com
-Status: Open
+Status: Bogus
Bug Type: Class/Object related
Operating System: linux
PHP Version: 5.2.1
New Comment:
unset()
Previous Comments:
[2007-02-16 20:14:49] afuzaylov at mlgpro dot com
Then how do I destroy the class completely? I need it destroyed to
continue with the next statement...
[2007-02-16 20:12:03] [EMAIL PROTECTED]
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
Nope, it shouldn't.
[2007-02-16 20:06:57] afuzaylov at mlgpro dot com
Description:
I have a class that has __destruct() in there.
When I call the $process->__destruct(), shouldn't it destroy the whole
class, all the functions and variables associated with it and all the
com objects?
Reproduce code:
---
class CProcess {
var $fsize;
function __construct($fsize) {
$this->$fsize = $fsize;
}
function __destruct() {
}
}
$process = new CProcess(15);
$process->__destruct();
Expected result:
All the vars should be destroyed.
Actual result:
--
The vars stay in memory
--
Edit this bug report at http://bugs.php.net/?id=40511&edit=1
#40512 [NEW]: debug_backtrace() bug ?
From: potramihai at yahoo dot com Operating system: Linux PHP version: 5.2.1 PHP Bug Type: Class/Object related Bug description: debug_backtrace() bug ? Description: Hello, I have recently encountered a serious problem with the debug_backtrace() function which is specified to be in the php core. I've run the same script on my machine which is on windows and it returns the "object" item correctly. However, on my hosting company I've tried it and doesn't return such an item at all. They have PHP 5.1.1 as CGI and PHP 5.2.1 as Apache Module. When this first happened they moved my account from the CGI to the Apache Module, but the same thing happens. I've searched on google and throughout the whole documentation in order to understand why the debug_backtrace() won't return any "object" field on their server. I didn't find any specific php configuration to stop this function from returning the "object" field. I've tried even a simple code with one class C1 calling a function on class C2 which print_r(debug_backtrace()). You can see the result at http://www.getsocial.co.uk/test/t1.php and the PHP info at http://www.getsocial.co.uk/test/phpinfo.php and the code used to reproduce at http://www.getsocial.co.uk/test/code.php This works on my PHP 5.2.1 Windows Box. I am looking forward to any suggestions or details regarding this issue. The hosting company has already agreed to offer any information that might help detect the source of this, in what regards the configurations. Sincerely, Mihai Potra Reproduce code: --- http://www.getsocial.co.uk/test/code.php Expected result: Get an "object" field on running debug_backtrace(); Actual result: -- http://www.getsocial.co.uk/test/t1.php -- Edit bug report at http://bugs.php.net/?id=40512&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40512&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40512&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40512&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40512&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40512&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40512&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40512&r=needscript Try newer version:http://bugs.php.net/fix.php?id=40512&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40512&r=support Expected behavior:http://bugs.php.net/fix.php?id=40512&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40512&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40512&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40512&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40512&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40512&r=dst IIS Stability:http://bugs.php.net/fix.php?id=40512&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40512&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40512&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40512&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40512&r=mysqlcfg
#40511 [Bgs->Opn]: __destruct() does not destroy vars $var
ID: 40511
User updated by: afuzaylov at mlgpro dot com
Reported By: afuzaylov at mlgpro dot com
-Status: Bogus
+Status: Open
Bug Type: Class/Object related
Operating System: linux
PHP Version: 5.2.1
New Comment:
Then how do I destroy the class completely? I need it destroyed to
continue with the next statement...
Previous Comments:
[2007-02-16 20:12:03] [EMAIL PROTECTED]
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
Nope, it shouldn't.
[2007-02-16 20:06:57] afuzaylov at mlgpro dot com
Description:
I have a class that has __destruct() in there.
When I call the $process->__destruct(), shouldn't it destroy the whole
class, all the functions and variables associated with it and all the
com objects?
Reproduce code:
---
class CProcess {
var $fsize;
function __construct($fsize) {
$this->$fsize = $fsize;
}
function __destruct() {
}
}
$process = new CProcess(15);
$process->__destruct();
Expected result:
All the vars should be destroyed.
Actual result:
--
The vars stay in memory
--
Edit this bug report at http://bugs.php.net/?id=40511&edit=1
#40511 [Opn->Bgs]: __destruct() does not destroy vars $var
ID: 40511
Updated by: [EMAIL PROTECTED]
Reported By: afuzaylov at mlgpro dot com
-Status: Open
+Status: Bogus
Bug Type: Class/Object related
Operating System: linux
PHP Version: 5.2.1
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
Nope, it shouldn't.
Previous Comments:
[2007-02-16 20:06:57] afuzaylov at mlgpro dot com
Description:
I have a class that has __destruct() in there.
When I call the $process->__destruct(), shouldn't it destroy the whole
class, all the functions and variables associated with it and all the
com objects?
Reproduce code:
---
class CProcess {
var $fsize;
function __construct($fsize) {
$this->$fsize = $fsize;
}
function __destruct() {
}
}
$process = new CProcess(15);
$process->__destruct();
Expected result:
All the vars should be destroyed.
Actual result:
--
The vars stay in memory
--
Edit this bug report at http://bugs.php.net/?id=40511&edit=1
#40511 [NEW]: __destruct() does not destroy vars $var
From: afuzaylov at mlgpro dot com
Operating system: linux
PHP version: 5.2.1
PHP Bug Type: Class/Object related
Bug description: __destruct() does not destroy vars $var
Description:
I have a class that has __destruct() in there.
When I call the $process->__destruct(), shouldn't it destroy the whole
class, all the functions and variables associated with it and all the com
objects?
Reproduce code:
---
class CProcess {
var $fsize;
function __construct($fsize) {
$this->$fsize = $fsize;
}
function __destruct() {
}
}
$process = new CProcess(15);
$process->__destruct();
Expected result:
All the vars should be destroyed.
Actual result:
--
The vars stay in memory
--
Edit bug report at http://bugs.php.net/?id=40511&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=40511&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=40511&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=40511&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=40511&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=40511&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=40511&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=40511&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=40511&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=40511&r=support
Expected behavior:http://bugs.php.net/fix.php?id=40511&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=40511&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=40511&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=40511&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40511&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=40511&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=40511&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=40511&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=40511&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=40511&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=40511&r=mysqlcfg
#40510 [NEW]: Add multicast support in sockets.c
From: lew dot payne at gmail dot com Operating system: FreeBSD 6.2-REL PHP version: 5.2.1 PHP Bug Type: Feature/Change Request Bug description: Add multicast support in sockets.c Description: To date, PHP does not offer multicast support, mainly due to some constants and structures missing in sockets.c. I'd like to propose that the following patch be incorporated into the code, to fully support multicast: http://diary.rozsnyo.com/2006/06/16/php5-ext-sockets-multicast.patch A full explanation of the patch can be found here: http://diary.rozsnyo.com/2006/06/16/multicast-support-in-php.pdf Reproduce code: --- http://diary.rozsnyo.com/2006/06/16/php5-ext-sockets-multicast.patch\ Expected result: Multicast constants and the necessary structures to support them exist and are now recognized by the socket_set_option and socket_get_option language constructs. Actual result: -- - none needed - -- Edit bug report at http://bugs.php.net/?id=40510&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40510&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40510&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40510&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40510&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40510&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40510&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40510&r=needscript Try newer version:http://bugs.php.net/fix.php?id=40510&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40510&r=support Expected behavior:http://bugs.php.net/fix.php?id=40510&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40510&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40510&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40510&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40510&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40510&r=dst IIS Stability:http://bugs.php.net/fix.php?id=40510&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40510&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40510&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40510&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40510&r=mysqlcfg
#40421 [Asn]: Install error 2343
ID: 40421 User updated by: wade_link at hotmail dot com Reported By: wade_link at hotmail dot com Status: Assigned Bug Type: Unknown/Other Function Operating System: XP Pro PHP Version: 5.2.1 Assigned To: jmertic New Comment: Still got the same error at the same point of writing INI files. Previous Comments: [2007-02-15 19:41:53] [EMAIL PROTECTED] Please try the latest build. If you are still having problems, email the error.log file produced from the following to [EMAIL PROTECTED] >From the command line in the directory where you downloaded the installer: msiexec /i php-5.2.1-win32-installer.msi /l*v error.log [2007-02-10 00:09:58] wade_link at hotmail dot com It worked sort of. It got most of the way through the intall then errored. It had the same error message. It gets through a lot, but the error message shows up when it says it is writing INI files. [2007-02-09 23:37:58] [EMAIL PROTECTED] Please try: http://downloads.php.net/edink/php-5.2.1-win32-installer-fix.msi [2007-02-09 23:24:34] [EMAIL PROTECTED] So 5.2.1 _probably_ works fine, but you can't test it because you cannot uninstall the previous version. Consult your OS support on how to force the uninstall? [2007-02-09 23:20:06] wade_link at hotmail dot com Well, not exactly. I just downloaded php-5.2.1-win32-installer and tried that, but it give me the message that there is a previous version installed and it must be un-installed before the new version can be installed. Back to square one. 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/40421 -- Edit this bug report at http://bugs.php.net/?id=40421&edit=1
#40466 [Bgs]: zend_mm_heap corruption
ID: 40466 User updated by: stojmir at on dot net dot mk Reported By: stojmir at on dot net dot mk Status: Bogus Bug Type: Reproducible crash Operating System: Linux 2.6.9 PHP Version: 5.2.1 New Comment: Guys, im not really convinced that this is an eaccelerator issue. Ok, turning it off did help, but today i tried APC and i'm experiencing the same problem. Previous Comments: [2007-02-15 16:07:21] [EMAIL PROTECTED] I'm afraid you need to report it to eAccelerator developers, since it's obviously something related to eAccelerator, not PHP itself. [2007-02-15 15:59:43] stojmir at on dot net dot mk I tried the latest CVS snapshot with no success. Removing the eAccelerator however, helped, but my CPU usage now has trippled. What do you suggest? Where is this supposed to continue? [2007-02-13 18:20:54] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip .. And try the snapshot. [2007-02-13 18:18:48] [EMAIL PROTECTED] You can start with disabling eaccelerator and any other zend extensions you may have loaded. [2007-02-13 18:07:17] stojmir at on dot net dot mk I really have no idea on how to narrow down the code that could reproduce the crash. It could be anything from the thousands of lines of code in Drupal. Any hints? What else can i do in order to help you guys identify and resolve this? 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/40466 -- Edit this bug report at http://bugs.php.net/?id=40466&edit=1
#40509 [NEW]: key() function changed behaviour if global array is used within function
From: alex dot killing at gmx dot de
Operating system: MaxOsX/RedHat
PHP version: 5.2.1
PHP Bug Type: Arrays related
Bug description: key() function changed behaviour if global array is used
within function
Description:
If a global array is assigned to a local variable as in the example, and
the local variable is iterated afterwards, the key() function changed the
behaviour in the global scope with PHP 5.2.1.
Reproduce code:
---
-".key($arr["v"])."-"; // prints "" since 5.2.1 ("0" on all
prior versions)
?>
Expected result:
-0-
-0-
Actual result:
--
-0-
--
--
Edit bug report at http://bugs.php.net/?id=40509&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=40509&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=40509&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=40509&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=40509&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=40509&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=40509&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=40509&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=40509&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=40509&r=support
Expected behavior:http://bugs.php.net/fix.php?id=40509&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=40509&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=40509&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=40509&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40509&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=40509&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=40509&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=40509&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=40509&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=40509&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=40509&r=mysqlcfg
#40508 [NEW]: Namespace xpath doesn't work for nested elements
From: [EMAIL PROTECTED]
Operating system: Windows
PHP version: 5.2.1
PHP Bug Type: SimpleXML related
Bug description: Namespace xpath doesn't work for nested elements
Description:
Registering XPath namespace works only for XPath queries from root
element.
Reproduce code:
---
$text = 'http://example.org";>test';
$xml = simplexml_load_string($text);
// register in root
$xml->registerXPathNamespace("x", "http://example.org";);
print_r($xml->b->xpath("x:c"));
// register in nested element
$xml->b->registerXPathNamespace("x", "http://example.org";);
print_r($xml->b->xpath("x:c"));
Expected result:
At least once:
Array
(
[0] => SimpleXMLElement Object
(
[0] => test
)
)
Actual result:
--
Warning: SimpleXMLElement::xpath(): Undefined namespace prefix
Warning: SimpleXMLElement::xpath(): Undefined namespace prefix
--
Edit bug report at http://bugs.php.net/?id=40508&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=40508&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=40508&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=40508&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=40508&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=40508&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=40508&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=40508&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=40508&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=40508&r=support
Expected behavior:http://bugs.php.net/fix.php?id=40508&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=40508&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=40508&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=40508&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40508&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=40508&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=40508&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=40508&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=40508&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=40508&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=40508&r=mysqlcfg
#16877 [Com]: socket_read() only gets one character (no matter what length set)
ID: 16877
Comment by: adrxc at hotmail dot com
Reported By: webmaster at red-sub-tech dot ws
Status: No Feedback
Bug Type: Sockets related
Operating System: Windows 2000 Profesional
PHP Version: 4.2.0
New Comment:
I had spent many hours leading with that same socket_read() bugs, in
Windows 2000 SP4. A way to "by-pass" the bugs is getting bytes in a
loop, and omitting 'type' at socket_read() call. See the following
simple telnet server:
set_time_limit (0);
ob_implicit_flush ();
$host = "127.0.0.1";
$port = 4100;
$socket = socket_create(AF_INET, SOCK_STREAM, 0) or die("Could not
create socket\n");
socket_set_option($socket, SOL_SOCKET, SO_REUSEADDR, 1);
$ret = socket_bind($socket, $host, $port) or die("Could not bind to
socket\n");
$ret = socket_listen($socket, 3) or die("Could not set up socket
listener\n");
$client = socket_accept($socket) or die("Could not accept incoming
connection\n");
$welcome = "\n\rWelcome!";
socket_write($client, $welcome, strlen ($welcome)) or die("Could not
send connect string\n");
while(1) {
/* Ask for next input */
$output = "\n\n\rWaiting for request ('quit' to end)... ";
socket_write($client, $output, strlen($output)) or die("Could not
write output\n");
/* Get user message. Warning: socket_read does NOT works here if third
parameter is given */
$input = '';
while(ord($i = socket_read($client, 1024)) != 13) {
$input .= $i;
socket_write($client, $i, 1) or die("Could not write output\n");
}
/* End session? */
if($input=="quit") {
break;
}
/* Out message back */
$output = "\n\n\rYou say '$input'";
socket_write($client, $output, strlen($output)) or die("Could not
write output\n");
}
socket_close($client);
socket_close($socket);
Previous Comments:
[2007-02-03 15:31:20] info at tentoday dot com
This problem is still available. Currently testing on Windows XP
professional SP2. Is there any workaround available? Currently the
sockets are just not usable on Windows XP. I haven't tested on Windows
2003 but expect the same. Version used is: PHP 5.2.0.
Thanks for information!
[2005-07-09 22:40:32] firebuddy007 at ameritech dot net
ive got one system with xp home, and one with xp pro, and socket_read
only reads one character on BOTH systems
its rather frustrating
[2002-07-15 09:37:47] administrator at zinious dot com
Looks like a bug in the code.
I'm using Windows 2000 Server (same OS family) and am reading multiple
bytes of text at one read.
[2002-06-05 01:00:07] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a month, 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".
[2002-05-04 19:06:00] [EMAIL PROTECTED]
Please try with CVS HEAD and report back. But do *not* rely on the
manuals sample script, they're outdated.
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/16877
--
Edit this bug report at http://bugs.php.net/?id=16877&edit=1
#40507 [Opn->Fbk]: php install probem
ID: 40507 Updated by: [EMAIL PROTECTED] Reported By: armin at xos dot net -Status: Open +Status: Feedback Bug Type: Unknown/Other Function Operating System: solaris 2.9 64 bit PHP Version: 5.2.1 New Comment: >i used the suggested compile flags and no segmentation >fault anymore, which shows it's a php bug It doesn't sound too convincing. And the fact that the problem is reproducible ONLY on Sparc and ONLY using GCC 4.x makes me wonder what made you think so. >please add "-fno-strict-aliasing and/or -fwrapv" to the >c-flags for solaris 2.9 64bit I would prefer to find the roots of the problem instead of applying some magical workaround. >however: how to fix the Phar archive problem? Let me see if I can reproduce it with working GCC. Previous Comments: [2007-02-16 12:22:06] armin at xos dot net Description: related to: http://bugs.php.net/bug.php?id=39418 i had the same problem and submitted a bug report with gcc. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30819 i used the suggested compile flags and no segmentation fault anymore, which shows it's a php bug - probably since i get following during make install: /usr/local/src/apache_etc/php-5.2.1_error/sapi/cli/php -n -dshort_open_tag=0 -dsafe_mode=0 -dopen_basedir= -derror_reporting=E_ALL -dmemory_limit=-1 -ddetect_unicode=0 pear/install-pear-nozlib.phar -d "/usr/local/lib/php" -b "/usr/local/bin" Warning: unpack(): Type V: not enough input, need 4, have 0 in /usr/local/src/apache_etc/php-5.2.1_error/pear/install-pear-nozlib.phar on line 339 Notice: Uninitialized string offset: 0 in /usr/local/src/apache_etc/php-5.2.1_error/pear/install-pear-nozlib.phar on line 342 Notice: Uninitialized string offset: 1 in /usr/local/src/apache_etc/php-5.2.1_error/pear/install-pear-nozlib.phar on line 342 Notice: Uninitialized string offset: 2 in /usr/local/src/apache_etc/php-5.2.1_error/pear/install-pear-nozlib.phar on line 342 Notice: Uninitialized string offset: 0 in /usr/local/src/apache_etc/php-5.2.1_error/pear/install-pear-nozlib.phar on line 343 Fatal error: Phar is API version 0.0.0, but PHP_Archive is API version 0.8.0 in /usr/local/src/apache_etc/php-5.2.1_error/pear/install-pear-nozlib.phar on line 353 please add "-fno-strict-aliasing and/or -fwrapv" to the c-flags for solaris 2.9 64bit however: how to fix the Phar archive problem? -- Edit this bug report at http://bugs.php.net/?id=40507&edit=1
#40507 [NEW]: php install probem
From: armin at xos dot net Operating system: solaris 2.9 64 bit PHP version: 5.2.1 PHP Bug Type: Unknown/Other Function Bug description: php install probem Description: related to: http://bugs.php.net/bug.php?id=39418 i had the same problem and submitted a bug report with gcc. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30819 i used the suggested compile flags and no segmentation fault anymore, which shows it's a php bug - probably since i get following during make install: /usr/local/src/apache_etc/php-5.2.1_error/sapi/cli/php -n -dshort_open_tag=0 -dsafe_mode=0 -dopen_basedir= -derror_reporting=E_ALL -dmemory_limit=-1 -ddetect_unicode=0 pear/install-pear-nozlib.phar -d "/usr/local/lib/php" -b "/usr/local/bin" Warning: unpack(): Type V: not enough input, need 4, have 0 in /usr/local/src/apache_etc/php-5.2.1_error/pear/install-pear-nozlib.phar on line 339 Notice: Uninitialized string offset: 0 in /usr/local/src/apache_etc/php-5.2.1_error/pear/install-pear-nozlib.phar on line 342 Notice: Uninitialized string offset: 1 in /usr/local/src/apache_etc/php-5.2.1_error/pear/install-pear-nozlib.phar on line 342 Notice: Uninitialized string offset: 2 in /usr/local/src/apache_etc/php-5.2.1_error/pear/install-pear-nozlib.phar on line 342 Notice: Uninitialized string offset: 0 in /usr/local/src/apache_etc/php-5.2.1_error/pear/install-pear-nozlib.phar on line 343 Fatal error: Phar is API version 0.0.0, but PHP_Archive is API version 0.8.0 in /usr/local/src/apache_etc/php-5.2.1_error/pear/install-pear-nozlib.phar on line 353 please add "-fno-strict-aliasing and/or -fwrapv" to the c-flags for solaris 2.9 64bit however: how to fix the Phar archive problem? -- Edit bug report at http://bugs.php.net/?id=40507&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40507&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40507&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40507&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40507&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40507&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40507&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40507&r=needscript Try newer version:http://bugs.php.net/fix.php?id=40507&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40507&r=support Expected behavior:http://bugs.php.net/fix.php?id=40507&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40507&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40507&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40507&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40507&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40507&r=dst IIS Stability:http://bugs.php.net/fix.php?id=40507&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40507&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40507&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40507&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40507&r=mysqlcfg
#40286 [Asn->Csd]: PHP fastcgi with PHP_FCGI_CHILDREN don't kill children when parent is killed
ID: 40286
Updated by: [EMAIL PROTECTED]
Reported By: gabriel at oxeva dot fr
-Status: Assigned
+Status: Closed
Bug Type: CGI related
Operating System: Linux 2.6
PHP Version: 4.4.4
Assigned To: dmitry
New Comment:
I hope the bug is fixed in CVS HEAD, PHP_5_2 (not in 5.2.1) and PHP_4_4
(not in 4.4.5).
The patch for PHP_5_2 folows:
Index: sapi/cgi/cgi_main.c
===
RCS file: /repository/php-src/sapi/cgi/cgi_main.c,v
retrieving revision 1.267.2.15.2.22
diff -u -p -d -r1.267.2.15.2.22 cgi_main.c
--- sapi/cgi/cgi_main.c 15 Feb 2007 12:33:16 - 1.267.2.15.2.22
+++ sapi/cgi/cgi_main.c 16 Feb 2007 11:16:39 -
@@ -355,18 +355,14 @@ static int sapi_cgi_send_headers(sapi_he
static int sapi_cgi_read_post(char *buffer, uint count_bytes
TSRMLS_DC)
{
- uint read_bytes=0, tmp_read_bytes;
-#if PHP_FASTCGI
- char *pos = buffer;
-#endif
+ int read_bytes=0, tmp_read_bytes;
count_bytes = MIN(count_bytes, (uint) SG(request_info).content_length
- SG(read_post_bytes));
while (read_bytes < count_bytes) {
#if PHP_FASTCGI
if (fcgi_is_fastcgi()) {
fcgi_request *request = (fcgi_request*)
SG(server_context);
- tmp_read_bytes = fcgi_read(request, pos, count_bytes -
read_bytes);
- pos += tmp_read_bytes;
+ tmp_read_bytes = fcgi_read(request, buffer + read_bytes,
count_bytes - read_bytes);
} else {
tmp_read_bytes = read(0, buffer + read_bytes,
count_bytes -
read_bytes);
}
Previous Comments:
[2007-01-31 11:56:49] gabriel at oxeva dot fr
And today, I can now confirm that the bugs exists with PHP 5.2.0 too.
Here is the backtrace :
(gdb) bt
#0 0xb7fb2410 in ?? ()
#1 0xbfc06988 in ?? ()
#2 0x0008 in ?? ()
#3 0xbfc069b0 in ?? ()
#4 0x006ee4f3 in __read_nocancel () from /lib/tls/libc.so.6
#5 0x0841b6d4 in fcgi_init_request ()
#6 0x0841b770 in fcgi_read ()
#7 0x0841c546 in fcgi_putenv ()
#8 0x08382d33 in sapi_deactivate ()
#9 0x0837c4f6 in php_request_shutdown ()
#10 0x0841e463 in main ()
[2007-01-30 14:33:38] gabriel at oxeva dot fr
Forgot to mention that the backtrace provided is from a PHP 5.1.4
process, not php 5.2. Sorry for the misreading.
I can compile and run a PHP 5.2 process and wait for having one killed
without his children, but it will take some time to give you the
results.
[2007-01-30 14:27:52] gabriel at oxeva dot fr
Missed to say that PHP 5 has exactly the same problem
[2007-01-30 14:26:42] gabriel at oxeva dot fr
strace -p provides the following :
read(3,
and gdb program and "bt" provides :
(gdb) bt
#0 0xb7fe3410 in ?? ()
#1 0xbfd86618 in ?? ()
#2 0x0008 in ?? ()
#3 0xbfd86600 in ?? ()
#4 0x008e14f3 in __read_nocancel () from /lib/tls/libc.so.6
#5 0x083ba23e in fcgi_read ()
#6 0x083bbb38 in FCGX_FPrintF ()
#7 0x0831ab22 in sapi_deactivate ()
#8 0x08314a3d in php_request_shutdown ()
#9 0x083bcdeb in main ()
Please note that I can't test with debugging symbols (the libraries and
PHP are stripped), as this binary is in production environment and the
bug occurs only under load.
[2007-01-30 13:20:40] [EMAIL PROTECTED]
Could you plase attach debugger to non-killed process and provide
backtrace.
Do php-5.2 has the same problem?
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/40286
--
Edit this bug report at http://bugs.php.net/?id=40286&edit=1
#40417 [Opn]: Suddenly binding as many vars as there are *identical* prepared tokens
ID: 40417
User updated by: exaton at free dot fr
Reported By: exaton at free dot fr
Status: Open
Bug Type: PDO related
Operating System: Windows XP Pro SP2
PHP Version: 5.2.1
New Comment:
Hey again people,
I don't mean to be annoying, but I've just done a bit more research, so
I thought I'd share it with you.
Iliaa, I found the code change where you added the infamous
spec-altering error check that I'm going on about :
PHP_5_2 :
http://cvs.php.net/viewcvs.cgi/php-src/ext/pdo/pdo_sql_parser.c?r1=1.35.2.6.2.3&r2=1.35.2.6.2.4
Also applied to MAIN, with both times the comment : "Added missing
check for mismatching number of tokens & bound params in prepared
statement emulation."
That perfectly matches my error conditions.
The problem is, the bindno variable contains the number of individual
tokens. However, multiple tokens may have the same name ; but each
token name can only be bound once ! So comparing bindno to the number
of bindings is incorrect. It introduces the following specification :
"multiple tokens may not have the same name in a prepared statement".
The workaround is still the same : binding enough bogus tokens to match
the number of individual tokens used in the prepared statement, when
some share the same name.
Oh, did I mention that this prevented anyone with prepared statements
containing multiple tokens sharing the same name from upgrading to PHP
5.2.1 ? :-)
Previous Comments:
[2007-02-10 17:18:20] exaton at free dot fr
OK, I've taken a look at the source code to try and lend a hand in
clearing up this issue. My first time though, so here's hoping I'm not
too far off the mark.
Diffing ext/pdo/ and ext/pdo_pgsql/ files between PHP 5.2.0 and 5.2.1,
I find that the error message I am encountering is due to a new
paragraph having been *added* to the much remangled
ext/pdo/pdo_sql_parser.c (line 262) :
if (params && bindno != zend_hash_num_elements(params) &&
stmt->supports_placeholders == PDO_PLACEHOLDER_NONE) {
pdo_raise_impl_error(stmt->dbh, stmt, "HY093", "number of bound
variables does not match number of tokens" TSRMLS_CC);
ret = -1;
goto clean_up;
}
Somehow I'm trigerring the error condition, here. I'm guessing that my
bindno is different from the number of elements in the params hash
table.
bindno is incremented on line 214. I could be wrong, but I'm under the
impression that it is *incremented with each _placeholder_*, which in
turn I take to be the "token *instances*" we were talking about
before.
Now, I think we both agree that we only have to bind as many
values/vars as there are *different* tokens in the statement. That is
in any case how things worked up to PHP 5.2.0.
With the new error detection that has been added (the above paragraph
of code), and if I'm right about the way bindno is counted, then we are
expected to bind as many values/vars as there are *placeholders* in the
statement, even if there are 2 or more placeholders for the same token
name.
That would be very coherent with the new error I am getting. It would
also be coherent with my workaround, in which one just had to bind
extra, bogus values/vars (thus artificially filling up the params hash
table, with params = stmt -> bound_params) in order to not get this
error.
So :
1) The new error detection breaks existing scripts that worked with
5.2.0.
2) I think we agree that the specification introduced by this new error
detection is incorrect. One may, as far as I know, use several times the
same placeholder for bound values/vars in a statement. It is only
possible to bind a given token once (because that binding fills a hash
table, which will of course not increase in size if the same token is
bound several times). Therefore, forcing one to bind as many
values/vars as there are *placeholders* is surely incorrect.
3) The workaround is symptomatic of something real fishy going on
(having to write bogus code to "unblock" a piece of functionality,
wt... ?).
That's as much as I can do guys, I have no setup whatsoever for tracing
variables in the code. The object of such a trace would be to confirm
that, with my test case (in which there are 2 identical ":id"
placeholders in the statement), bindno = 2 versus only 1 entry in the
params = stmt -> bound_params hash table.
Good luck, and thank you for your patience, I'm not much good at
writing simple sentences :)
[2007-02-10 16:18:08] exaton at free dot fr
I'm sorry, but I don't understand your reply.
Perhaps my use of the word "token" is wrong. The multiple instances
"count[ing] as one token, since they reference the same bound
parameter" is exactly the behaviour I expect, and had been counting on
*and getting* up to now.
However, Re. my initial example and test case, *several bindings* are
required, *as many as there are _instances_*, not just
#39221 [Com]: php5ts.dll faulting every few minutes on apache2.2
ID: 39221 Comment by: niels at keurentjes dot net Reported By: kris at k-software dot org Status: No Feedback Bug Type: Apache2 related Operating System: windows server 2003 x64 PHP Version: 5CVS-2006-10-20 (snap) New Comment: I have the exact same issue: a stock Win2k3 setup with Apache 2.2.4 and PHP 5.2.1 on a Dual Xeon HT setup, and regular crashes, several times per day, sometimes 15 in 30 minutes when the site is being hit severely. I have performed several recent software upgrades, the problems also occurred in the exact same fasion in Apache 2.0.59 + PHP 5.1.4, Apache 2.0.59 + PHP 5.2.0 and Apache 2.2.4 + PHP 5.2.1. I am currently testing whether hard-forcing uniprocessor operation using ImageCfg (http://www.robpol86.com/Pages/imagecfg.php) works. I have set the httpd.exe process to the following: --- httpd.exe contains the following configuration information: Process Affinity Mask: 0001 httpd.exe contains a Subsystem Version of 4.0 Image can only run in uni-processor mode on multi-processor systems --- Notably the crashes seemed to become less frequent when I disabled all caching on the site. At first I suspected this pointed towards problems with too many files open simultaneously, but I am now after reading these problems pretty sure that it merely slowed down the site enough not to trigger the synchronization issues or race conditions. Previous Comments: [2007-01-04 04:05:22] judexidoneus_g6 at hotmail dot com So, there is no solution for this bug? [2006-11-07 07:44:44] paradiso at gmail dot com This is really a bug. on my p4 2.4c + 865G + 1G ram, win2k3 server, apache 2.2.3.0 & php 5.2, this happens all the time. [2006-10-31 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". [2006-10-22 14:14:23] kris at k-software dot org Error in CPU IDs in previous comment, from microsoft support article ID 252867: Processor enumeration on computers that use hyperthreading first assign processor numbers to the primary logical processor for each processor and then assign numbers to the secondary. For example, for dual physical processor computers with hyperthreading, the first processor has logical processor 0 and 2, and the second processor has logical processor 1 and 3. [2006-10-22 13:59:13] kris at k-software dot org It appears that setting the CPU affinity of the apache http process to a single physical processor stops the crashing... Setting the server to NOT use the second hyperthreaded core of the xeons (i.e. CPUs 0+2 or 1+3) seems to solve this random crashing. Will test with a prefork MPM. 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/39221 -- Edit this bug report at http://bugs.php.net/?id=39221&edit=1
#40506 [NEW]: Suggestion: json_encode() and non-UTF8 strings
From: php at koterov dot ru
Operating system: all
PHP version: 5.2.1
PHP Bug Type: Unknown/Other Function
Bug description: Suggestion: json_encode() and non-UTF8 strings
Description:
Could you please explain why json_encode() takes care about the encoding
at all? Why not to treat all the string data as a binary flow? This is
very inconvenient and disallows the usage of json_encode() in non-UTF8
sites! :-(
I have written a small substitution for json_encode(), but note that it of
course works much more slow than json_encode() with big data arrays..
/**
* Convert PHP scalar, array or hash to JS scalar/array/hash.
*/
function php2js($a)
{
if (is_null($a)) return 'null';
if ($a === false) return 'false';
if ($a === true) return 'true';
if (is_scalar($a)) {
$a = addslashes($a);
$a = str_replace("\n", '\n', $a);
$a = str_replace("\r", '\r', $a);
$a = preg_replace('{($v)
$result[] = php2js($k) . ': ' . php2js($v);
return '{ ' . join(', ', $result) . ' }';
}
}
So, my suggestion is remove all string analyzation from json_encode()
code. It also make this function to work faster.
Reproduce code:
---
'проверка', 'b' =>
array('слуха',
'глухого'));
echo json_encode($a);
?>
Expected result:
Correctly encoded string in the source 1-byte encoding.
Actual result:
--
Empty strings everywhere (and sometimes - notices that a string contains
non-UTF8 characters).
--
Edit bug report at http://bugs.php.net/?id=40506&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=40506&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=40506&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=40506&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=40506&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=40506&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=40506&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=40506&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=40506&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=40506&r=support
Expected behavior:http://bugs.php.net/fix.php?id=40506&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=40506&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=40506&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=40506&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40506&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=40506&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=40506&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=40506&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=40506&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=40506&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=40506&r=mysqlcfg
#40505 [Opn->Csd]: redirect.php of squirrelmail 1.4.9a crashes php (cgi) if register_globals is on
ID: 40505 Updated by: [EMAIL PROTECTED] Reported By: php-bug at test-2 dot de -Status: Open +Status: Closed Bug Type: Reproducible crash Operating System: Linux PHP Version: 4.4.5 New Comment: Fixed in CVS. Previous Comments: [2007-02-16 10:02:33] php-bug at test-2 dot de Description: ext/session/session.c:287 Reproduce code: --- php redirect.php (of squirrelmail 1.4.9a) Expected result: don't segfault Actual result: -- Starting program: ./php redirect.php Program received signal SIGSEGV, Segmentation fault. (gdb) bt #0 0x08126396 in php_add_session_var (name=0x854ba3c "sq_base_url", namelen=11) at (...) php-4.4.5/ext/session/session.c:287 -- Edit this bug report at http://bugs.php.net/?id=40505&edit=1
#40505 [NEW]: redirect.php of squirrelmail 1.4.9a crashes php (cgi) if register_globals is on
From: php-bug at test-2 dot de Operating system: Linux PHP version: 4.4.5 PHP Bug Type: Reproducible crash Bug description: redirect.php of squirrelmail 1.4.9a crashes php (cgi) if register_globals is on Description: ext/session/session.c:287 Reproduce code: --- php redirect.php (of squirrelmail 1.4.9a) Expected result: don't segfault Actual result: -- Starting program: ./php redirect.php Program received signal SIGSEGV, Segmentation fault. (gdb) bt #0 0x08126396 in php_add_session_var (name=0x854ba3c "sq_base_url", namelen=11) at (...) php-4.4.5/ext/session/session.c:287 -- Edit bug report at http://bugs.php.net/?id=40505&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40505&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40505&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40505&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40505&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40505&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40505&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40505&r=needscript Try newer version:http://bugs.php.net/fix.php?id=40505&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40505&r=support Expected behavior:http://bugs.php.net/fix.php?id=40505&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40505&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40505&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40505&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40505&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40505&r=dst IIS Stability:http://bugs.php.net/fix.php?id=40505&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40505&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40505&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40505&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40505&r=mysqlcfg
#40502 [Fbk->Csd]: interbase.c:3051: `buf' undeclared In function `_php_ibase_user'
ID: 40502 User updated by: jn at forever dot cz Reported By: jn at forever dot cz -Status: Feedback +Status: Closed Bug Type: Compile Failure Operating System: linux PHP Version: 4.4.5 New Comment: thnx! Previous Comments: [2007-02-16 07:11:51] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip Please try using the next snapshot. [2007-02-15 22:54:57] jn at forever dot cz Description: /usr/src/php-4.4.5/ext/interbase/interbase.c: In function `_php_ibase_user': /usr/src/php-4.4.5/ext/interbase/interbase.c:3051: `buf' undeclared (first use in this function) /usr/src/php-4.4.5/ext/interbase/interbase.c:3051: (Each undeclared identifier is reported only once /usr/src/php-4.4.5/ext/interbase/interbase.c:3051: for each function it appears in.) make: *** [ext/interbase/interbase.lo] Error 1 -- Edit this bug report at http://bugs.php.net/?id=40502&edit=1
