#40951 [Opn->Bgs]: combination of header() and imagegif/png/jpeg() makes script run more than once
ID: 40951 Updated by: [EMAIL PROTECTED] Reported By: zirephoenix at rogers dot com -Status: Open +Status: Bogus Bug Type: Scripting Engine problem Operating System: Linux PHP Version: 4.4.6 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Previous Comments: [2007-03-29 17:57:30] zirephoenix at rogers dot com This bug was only for FireFox 1.5.x. Seems to be gone in 2. [2007-03-29 17:25:49] zirephoenix at rogers dot com Description: Without the header() and imagegif() functions, the code is basically a hit counter script. However, with the combination of those two lines of code, the hit counter will increment by 2. Something is causing the script to run twice. Reproduce code: --- Expected result: test.txt should increment by 1 every time the script is accessed Actual result: -- test.txt increments by 2 every time the script is accessed -- Edit this bug report at http://bugs.php.net/?id=40951&edit=1
#40981 [Opn->Bgs]: Pass by reference and object assignment problem
ID: 40981
User updated by: sir dot mordred dot service at gmail dot com
Reported By: sir dot mordred dot service at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Windows XP, apache 2.0
PHP Version: 4.4.6
New Comment:
Got it, sorry, my bad. Changing status to "Bogus".
Previous Comments:
[2007-04-02 20:19:43] [EMAIL PROTECTED]
Recommended reading:
http://www.php.net/manual/en/language.references.php
http://www.php.net/manual/en/language.references.arent.php
[2007-04-02 20:07:30] sir dot mordred dot service at gmail dot com
Description:
If a parameter passed by reference to a function is assigned a new
object with the =& operator, after the function call the variable passed
to the function will not contain the object, but its previous value (or
null). Assignment with = works fine.
Reproduce code:
---
Expected result:
4.4.6
object(a)(0) {
}
object(a)(0) {
}
Actual result:
--
4.4.6
int(1)
object(a)(0) {
}
--
Edit this bug report at http://bugs.php.net/?id=40981&edit=1
#40984 [NEW]: Feed back not working
From: sivanarayanan_s at eth dot net Operating system: Windows XP PHP version: 5.2.1 PHP Bug Type: *Mail Related Bug description: Feed back not working Description: I've designed test feedback.php form. But it's not working. I've changed code in php.ini (windows dir).SMTP=smtp.eth.net (my ISP), but phpinfo() showing SMTP=localhost. Can you please help me out in this situation. I'm learing PHP now. Kindly help me. Reproduce code: --- feedback Thanks for your feedback!"); else: ?> Please send us your feedback (above code, I've taken it from my PHP book) Expected result: mail not received Actual result: -- mail should reach, [EMAIL PROTECTED] -- Edit bug report at http://bugs.php.net/?id=40984&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40984&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40984&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40984&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40984&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40984&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40984&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40984&r=needscript Try newer version:http://bugs.php.net/fix.php?id=40984&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40984&r=support Expected behavior:http://bugs.php.net/fix.php?id=40984&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40984&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40984&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40984&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40984&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40984&r=dst IIS Stability:http://bugs.php.net/fix.php?id=40984&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40984&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40984&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40984&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40984&r=mysqlcfg
#40984 [Opn->Bgs]: Feed back not working
ID: 40984 Updated by: [EMAIL PROTECTED] Reported By: sivanarayanan_s at eth dot net -Status: Open +Status: Bogus Bug Type: *Mail Related Operating System: Windows XP PHP Version: 5.2.1 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. . Previous Comments: [2007-04-03 08:41:01] sivanarayanan_s at eth dot net Description: I've designed test feedback.php form. But it's not working. I've changed code in php.ini (windows dir).SMTP=smtp.eth.net (my ISP), but phpinfo() showing SMTP=localhost. Can you please help me out in this situation. I'm learing PHP now. Kindly help me. Reproduce code: --- feedback Thanks for your feedback!"); else: ?> Please send us your feedback (above code, I've taken it from my PHP book) Expected result: mail not received Actual result: -- mail should reach, [EMAIL PROTECTED] -- Edit this bug report at http://bugs.php.net/?id=40984&edit=1
#40985 [NEW]: CLI version crashes while trying to shutdown, using tsrm_shutdown()
From: charlie at lemurconsulting dot com Operating system: Windows XP PHP version: 5.2.1 PHP Bug Type: Reproducible crash Bug description: CLI version crashes while trying to shutdown, using tsrm_shutdown() Description: While trying to make the Xapian (www.xapian.org) PHP bindings work on Windows using Visual C++, we found that the CLI version of PHP would crash when unloading the bindings. The bindings are written using SWIG. PHP appears to be trying to unload resources when the crash occurs. The crash does not occur on earlier versions of PHP i.e. 4.4.6 Reproduce code: --- The following patch fixes the problem and has been used as a workaround: Patch php_cli.c as follows by commenting out line 1283: #ifdef ZTS /*tsrm_shutdown(); */ #endif Expected result: No crash :) Actual result: -- n/a -- Edit bug report at http://bugs.php.net/?id=40985&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40985&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40985&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40985&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40985&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40985&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40985&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40985&r=needscript Try newer version:http://bugs.php.net/fix.php?id=40985&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40985&r=support Expected behavior:http://bugs.php.net/fix.php?id=40985&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40985&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40985&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40985&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40985&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40985&r=dst IIS Stability:http://bugs.php.net/fix.php?id=40985&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40985&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40985&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40985&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40985&r=mysqlcfg
#40961 [Bgs]: problem with preg_replace and preg_match functions
ID: 40961
User updated by: jfgingras at cegep-ste-foy dot qc dot ca
Reported By: jfgingras at cegep-ste-foy dot qc dot ca
Status: Bogus
Bug Type: *Regular Expressions
Operating System: FreeBSD 6.1-RELEASE
PHP Version: 5.2.1
New Comment:
You're probably right. But still, if I use the following pattern
"/([^\x09\x0A\x0D\x20-\x7E\xA0-\xFF])/", preg_replace always return
NULL. But if I use "[^\x09\x0A\x0D\x20-\x7E\xA0-\xFF]" it "works", that
is, it will not return NULL.
If I use '/^[a-f\d]{32}$/i' on "a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6",
preg_match always return false.
The exemples above occur on FreeBSD 6.1 with PHP 5.2.1.
I test thoses on Linux 2.6.9 with PHP 5.1.6 and it work.
Any idea ?
Previous Comments:
[2007-04-02 21:27:49] [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
Your regex is wrong, you cannot include the "$" (end of string) inside
a
capturing sub-pattern.
[2007-04-02 15:53:05] jfgingras at cegep-ste-foy dot qc dot ca
Forget to mention that no php error are logged in the log file. I even
set 666 mode on phperror.log just to be sure that php can write in it.
But still no error shown.
Strangly, like I said preg_replace works if I remove the '/(' and ')/'
from the pattern, but preg_match always return false. But, it print an
error:
[02-Apr-2007 11:51:29] PHP Warning: preg_match() [function.preg-match]: No ending delimiter
'^' found in /usr/local/www/f.php on line 6
And here's the line 6:
if(preg_match('^[a-f0-9]{32}$', $body)) echo "YEAH #2!";
[2007-04-02 15:45:18] jfgingras at cegep-ste-foy dot qc dot ca
$body = "b2c3d4e5f6a7b8c9e0f1a2b3c4d5e6f7";
$body = preg_replace('/(^[a-f0-9]{32}$)/', '?', $body );
var_dump($body);
It is not even returning a empty string, it return NULL!
Here's what I have in my php.ini
error_reporting = E_ALL
log_errors = On
error_log = /var/log/phperror.log
Here's my php info
[EMAIL PROTECTED] ~]# php -v
PHP 5.2.1 with Suhosin-Patch 0.9.6.2 (cli) (built: Mar 30 2007
10:03:24)
Copyright (c) 1997-2007 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies
Any help is more than welcome.
Thx!
[2007-03-30 22:33:13] tijnema at gmail dot com
$body = "b2c3d4e5f6a7b8c9e0f1a2b3c4d5e6f7";
$body = preg_replace('/(^[a-f0-9]{32}$)/', '?', $body );
var_dump($body);
Above code gives me string(1) "?" on PHP-5.1.6/5.2.1/6.0-dev on linux
using CLI or Apache.
[2007-03-30 21:06:46] smlerman at gmail dot com
$body = "b2c3d4e5f6a7b8c9e0f1a2b3c4d5e6f7";
$body = preg_replace('/(^[a-f0-9]{32}$)/', '?', $body );
var_dump($body);
string(1) "?"
That's what I get in 5.1.6 on Linux and 5.2.1 on Windows.
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/40961
--
Edit this bug report at http://bugs.php.net/?id=40961&edit=1
#39089 [Fbk->Opn]: Missing -liconv during GD configuring fails ./configure run
ID: 39089 User updated by: suhachov at gmail dot com Reported By: suhachov at gmail dot com -Status: Feedback +Status: Open Bug Type: GD related Operating System: Linux FC PHP Version: 5.1.6 Assigned To: pajoye New Comment: Of course no! I specified it in ./configure option (--with-iconv). And it seems to me that it is ./configure business, to set neccessary envs and paths. Previous Comments: [2007-04-02 21:43:09] [EMAIL PROTECTED] Is this paths set in your LD_LIBRARY_PATH or in /etc/ld.so.conf file: /usr/apache-2006-10-10/libiconv-1.9.2/lib/ ?? [2006-10-10 12:53:19] suhachov at gmail dot com No. It's still here: /usr/apache-2006-10-10/gd-2.0.33/lib/libgd.so: undefined reference to `libiconv_open' php: php6.0-200610100830 gd: gd-2.0.33 #/usr/apache-2006-10-10/gd-2.0.33/bin/gdlib-config --all GD library 2.0.33 includedir: /usr/apache-2006-10-10/gd-2.0.33/include cflags: -I/usr/apache-2006-10-10/gd-2.0.33/include ldflags: -L/usr/local/lib -L/usr/local/lib -Wl,-rpath,/usr/local/lib -L/usr/apache-2006-10-10/jpeg-6b/lib -L/usr/X11R6/lib libs: -ljpeg -lfreetype -lpng12 -lz -lm /usr/apache-2006-10-10/libiconv-1.9.2/lib/libiconv.so -Wl,-rpath -Wl,/usr/apache-2006-10-10/libiconv-1.9.2/lib libdir: /usr/apache-2006-10-10/gd-2.0.33/lib features: GD_JPEG GD_FREETYPE GD_PNG GD_GIF [2006-10-09 16:14:03] [EMAIL PROTECTED] Can you try with php6 (HEAD), we use gdlib-config and should solve this problem. [2006-10-09 12:59:34] suhachov at gmail dot com Thanx, I know. But sometimes even glibc becomes updated... And I think it's very confusing behavior - to allow use "--with-iconv" (for PHP itself) and don't allow to used GD compiled with the same iconv... [2006-10-09 09:46:25] [EMAIL PROTECTED] Linux has libiconv bundled into glibc, no need for external libraries. 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/39089 -- Edit this bug report at http://bugs.php.net/?id=39089&edit=1
#40985 [Com]: CLI version crashes while trying to shutdown, using tsrm_shutdown()
ID: 40985 Comment by: daniel dot menard at bdsp dot tm dot fr Reported By: charlie at lemurconsulting dot com Status: Open Bug Type: Reproducible crash Operating System: Windows XP PHP Version: 5.2.1 New Comment: The same bug appear with the cgi version. The only known workaround for now is to patch php_cgi.c in the same way, removing any call to tsrm_shutdown() Previous Comments: [2007-04-03 14:00:47] charlie at lemurconsulting dot com Description: While trying to make the Xapian (www.xapian.org) PHP bindings work on Windows using Visual C++, we found that the CLI version of PHP would crash when unloading the bindings. The bindings are written using SWIG. PHP appears to be trying to unload resources when the crash occurs. The crash does not occur on earlier versions of PHP i.e. 4.4.6 Reproduce code: --- The following patch fixes the problem and has been used as a workaround: Patch php_cli.c as follows by commenting out line 1283: #ifdef ZTS /*tsrm_shutdown(); */ #endif Expected result: No crash :) Actual result: -- n/a -- Edit this bug report at http://bugs.php.net/?id=40985&edit=1
#38670 [Com]: Whole 4.4.x branch has problem with open_basedir option nested from Apache2
ID: 38670 Comment by: marcel dot prisi at virtua dot ch Reported By: serokka at hrn dot ru Status: Open Bug Type: Apache2 related Operating System: FreeBSD 4.10 PHP Version: 4.4.4 New Comment: I got the exact same problem on a FreeBSD-5.5 / Apache-2.0.59 / php-4.4.6 (all from ports) Adding a trailing slash to session.save_path didn't help, I had to comment it from the virtualhost config in order to have the error go away. Quite serious I think ... Previous Comments: [2007-03-14 13:02:05] david dot guenault at gmail dot com update my precedent post : if you simply add a trailing slash to session.save_path this will discard the problem. here is why : in safe_mode.c in the function php_checkuid_ex when mode argument is CHECKUID_ALLOW_ONLY_DIR at line 119 s = strrchr(filename, DEFAULT_SLASH); returns a pointer to the last occurrence of the character / in the string filename. if your path is like this /data1sys/phpsession the pointer is on the second slash not at the end of the path. The uid/gid check is made on the parent folder (/data1sys) not the real folder (/data1sys/phpsession). So when /data1sys is owned by a user that is different from the user running apache, the test fail. [2007-03-14 10:14:18] david dot guenault at gmail dot com first of all this is my environment >SLES 10 >Apache 2.0.59 >Php 4.4.6 I use virtual host to configure my different web sites like this DocumentRoot /data1user/apache/domain.tld ServerName www.domain.tld ErrorLog /data1sys/journaux/apache/domain/error_log CustomLog /data1sys/journaux/apache/domain/access_log combined # specific php configuration for this virtual host php_admin_value doc_root /data1user/apache/domain.tld php_admin_value session.save_path /data1sys/phpsession_domain.tld php_admin_value file_uploads on php_admin_value upload_tmp_dir /data1sys/phpupload_domain.tld php_admin_value error_log /data1sys/journaux/apache/testphp/php_domain.tld.log I've noticied one interesting thing. before the error occure i check session.save_path => ok this is the right directory. When the error occure session.save_path back to the default value (aka /tmp). apache is running as user usrhttpd and group grphttpd. The top level directory for storing session is /data1sys and is owned by user root and group root. The directory used to store sessions is phpsession_domain.tld under /data1sys and is owned by usrhttpd:grphttpd. If i change /datasys group to grphttpd the error disapear. If i remove the directive php_admin_value session.save_path /data1sys/phpsession_domain.tld. from my vhost then all is going right. hope this help. [2007-03-09 07:18:31] mspado at hotmail dot com Forgot to say: A common thread to issues with this bug has been the use of 'php_admin_value upload_tmp_dir /xxx/xxx/xxx/tmp' M. [2007-03-09 07:10:51] mspado at hotmail dot com Hi, We've experienced this issue numerous times since rolling out Apache2 (2.2.3) with PHP 4 (4.4.2 - yes only 4.4.2 because of http://bugs.php.net/bug.php?id=40514) last week. Example error 1: Warning: Unknown(): SAFE MODE Restriction in effect. The script whose uid/gid is 0/0 is not allowed to access /home/xx/xxx/xxxdomain.net/tmp owned by uid/gid 306628/100 in Unknown on line 0 Example error 2: The XML page cannot be displayed Cannot view XML input using XSL style sheet. Please correct the error and then click the Refresh button, or try again later. Only one top level element is allowed in an XML document. Error processing resource 'http://www.xxdomain.org/'. ... Warning: Unknown(): SAFE MODE Restriction in effect. The script whose uid/gid is 0/0 is not allowed to ... (cut off due to xml doc style error) Example error 3. This error is especially interesting because you can note that the requested file on yydomain and the allowed path of xxdomain (and no, its not a configuration error): *Warning*: Unknown(): open_basedir restriction in effect. File(/home/yy/yy/yydomain.com.au/public/www/admin/index.php) is not within the allowed path(s): (/home/xx/xx/xxdomain.org.au/:/usr/local/lib/php:/tmp/php_upload) in *Unknown* on line *0* This is a serious bug, we will have to roll back to Apache1. -- PHP PHP 4.4.2 (cli) (built: Feb 28 2007 17:14:01) Copyright (c) 1997-2006 The PHP Group Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies -- Apache Server version: Apache/2.2.3 Server built: Feb 28 2007 16:59:03 Server's Module Magic Number: 20051115:3 Server loaded: APR 1.2.7, APR-Util 1.2.7 Compiled using: APR 1.2.7, APR-Util 1.2.7 Architecture: 32-bit S
#40986 [NEW]: mssql_field_name() retrieves only first 30 characters
From: Arne dot Heizmann at csr dot com Operating system: Windows 2000 PHP version: 5.2.1 PHP Bug Type: MSSQL related Bug description: mssql_field_name() retrieves only first 30 characters Description: The function mssql_field_name() appears to return only the first 30 characters of the field name. Reproduce code: --- Expected result: 'This is a field name that is longer than 30 characters' Actual result: -- 'This is a field name that is l' -- Edit bug report at http://bugs.php.net/?id=40986&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40986&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40986&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40986&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40986&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40986&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40986&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40986&r=needscript Try newer version:http://bugs.php.net/fix.php?id=40986&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40986&r=support Expected behavior:http://bugs.php.net/fix.php?id=40986&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40986&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40986&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40986&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40986&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40986&r=dst IIS Stability:http://bugs.php.net/fix.php?id=40986&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40986&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40986&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40986&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40986&r=mysqlcfg
#40952 [Opn->Fbk]: mail: Malformed date header (H0600)
ID: 40952 Updated by: [EMAIL PROTECTED] Reported By: sh at nnoncarey dot com -Status: Open +Status: Feedback Bug Type: Mail related Operating System: Windows Server 2003 PHP Version: 4.4.6 New Comment: Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. Previous Comments: [2007-03-29 20:14:46] sh at nnoncarey dot com Description: Email sent with PHP's mail() function often (but not always) has a malformed Date: header. Specifically, the minus sign before the UTC offset is replaced with a capital letter "H". In my timezone (US Central Standard -6), this means "H0600" instead of "-0600". The occurrence of this problem does not appear to be related to the recent US DST change. Here is a date header illustrating the problem, along with the X-OriginalArrivalTime header from the same email, just for comparison: Date: Wed, 28 Mar 2007 14:04:37 H0600 X-OriginalArrivalTime: 28 Mar 2007 19:04:36.0042 (UTC) FILETIME=[ED52E2A0:01C7716B] But here is just one example which worked as expected. Date: Tue, 06 Feb 2007 07:54:42 -0600 X-OriginalArrivalTime: 06 Feb 2007 13:54:30.0533 (UTC) -- Edit this bug report at http://bugs.php.net/?id=40952&edit=1
#40956 [Opn->Fbk]: DOMDocumentType entities fails
ID: 40956
Updated by: [EMAIL PROTECTED]
Reported By: 131 dot php at cloudyks dot org
-Status: Open
+Status: Feedback
Bug Type: DOM XML related
Operating System: Linux RedHat
PHP Version: 5.2.1
New Comment:
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
Previous Comments:
[2007-03-30 07:10:28] 131 dot php at cloudyks dot org
Description:
DOMDocumentType entities fails to return a valid tree
Reproduce code:
---
$xml_str=XML_VERSIOn."s
&lang_key.fr;";
$doc = new DOMDocument("1.0","utf-8");
$doc->resolveExternals=true;
$doc->substituteEntities=true;
$doc->loadXML($xml_str);
$dtd=$doc->firstChild;
echo $dtd->publicId;//('')=>ok
echo $dtd->systemId;//('lang/fr.dtd')=>ok
echo $dtd->name;//('jsx')=>ok
echo $dtd->internalSubset;//('ok
foreach($dtd->entities as $elem) echo "even one";
//nope :(
echo $doc->saveXML();die;//s Francais=>ok
Expected result:
.*?
even one
.*?
--
Edit this bug report at http://bugs.php.net/?id=40956&edit=1
#40958 [Opn->Bgs]: install-pear-nozlib.phar Not valid internal .phar file
ID: 40958
Updated by: [EMAIL PROTECTED]
Reported By: dauphin at enst dot fr
-Status: Open
+Status: Bogus
Bug Type: Compile Failure
Operating System: solaris 10 sparc64
PHP Version: 5.2.1
New Comment:
Duplicate of bug #40841.
Previous Comments:
[2007-03-30 13:53:00] dauphin at enst dot fr
Description:
when installing php5 i got an error with PEAR install
Reproduce code:
---
in file install-pear-nozlib.phar
if (self::$_manifest[$this->_archiveName][$path][3] !=
sprintf("
%u", crc32($data))) {
return array("Not valid internal .phar file
(checksum error)
");
}
Expected result:
install PEAR
crc32 return int32 on 64bits architecture
Actual result:
--
gmake install
...
Installing PEAR environment: /usr/pkg/lib/php/
Fatal error: Not valid internal .phar file (checksum error) in
/pkg/obj/lang/php
5/work/php-5.2.1/pear/install-pear-nozlib.phar on line 411
gmake[1]: *** [install-pear-installer] Error 255
--
Edit this bug report at http://bugs.php.net/?id=40958&edit=1
#40985 [Opn->Fbk]: CLI version crashes while trying to shutdown, using tsrm_shutdown()
ID: 40985 Updated by: [EMAIL PROTECTED] Reported By: charlie at lemurconsulting dot com -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: Windows XP PHP Version: 5.2.1 New Comment: 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 Previous Comments: [2007-04-03 15:00:21] daniel dot menard at bdsp dot tm dot fr The same bug appear with the cgi version. The only known workaround for now is to patch php_cgi.c in the same way, removing any call to tsrm_shutdown() [2007-04-03 14:00:47] charlie at lemurconsulting dot com Description: While trying to make the Xapian (www.xapian.org) PHP bindings work on Windows using Visual C++, we found that the CLI version of PHP would crash when unloading the bindings. The bindings are written using SWIG. PHP appears to be trying to unload resources when the crash occurs. The crash does not occur on earlier versions of PHP i.e. 4.4.6 Reproduce code: --- The following patch fixes the problem and has been used as a workaround: Patch php_cli.c as follows by commenting out line 1283: #ifdef ZTS /*tsrm_shutdown(); */ #endif Expected result: No crash :) Actual result: -- n/a -- Edit this bug report at http://bugs.php.net/?id=40985&edit=1
#40978 [Opn->Asn]: PHP 5.2.1 Installer failure
ID: 40978 Updated by: [EMAIL PROTECTED] Reported By: jim_mcnally at yahoo dot com -Status: Open +Status: Assigned -Bug Type: *General Issues +Bug Type: Unknown/Other Function Operating System: Windows VISTA PHP Version: 5.2.1 -Assigned To: +Assigned To: jmertic Previous Comments: [2007-04-02 15:44:18] jim_mcnally at yahoo dot com Description: PHP 5.2.1 installer package terminated before installing. message from Vista: "There was a problem with this Windows Installer package. A program that was run as part of this setup did not finish as expected. Contact your package vendor." IIS v. 7.0 was installed and it works. PHP 5.2.1 installer was run selecting "IIS CGI'. No other options were selected. -- Edit this bug report at http://bugs.php.net/?id=40978&edit=1
#40977 [Opn->Fbk]: strftime failed on 2nd April 2007
ID: 40977
Updated by: [EMAIL PROTECTED]
Reported By: srisamir at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: Date/time related
Operating System: Windows 2003
PHP Version: 4.4.6
New Comment:
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
Previous Comments:
[2007-04-02 14:04:10] srisamir at gmail dot com
Description:
I tried the smarty function format_date to format a
date-time(mmddhhmmss).
It was working till last Saturday. Today, Monday when I tried the same,
it was showing wrong date(like 16 Jul, 98 00:00:00).
But when I changed the system date(say, 1st April or 3rd April) the
output date string was correct.
I went inside the smarty function and try to reproduce the result.
I used the function strftime to format the date-time and got the same
error (wrong display for 2nd April, 2007).
I tried with other dates (say 20070403181644) and got correct display.
Reproduce code:
---
error_reporting(E_ALL);
$string = "20070402181644"; //"20070403181644"
$time = strtotime($string);
if (is_numeric($time) && $time != -1) {}
else {
$time = mktime(substr($string,8,2),substr($string,10,2),substr
($string,12,2), substr($string,4,2),
substr ($string,6,2),substr($string,0,4));
}
echo strftime("%d,%b,%Y", $time);
Expected result:
02,Apr,2007
Actual result:
--
08,Mar,2006
--
Edit this bug report at http://bugs.php.net/?id=40977&edit=1
#40968 [Opn->Bgs]: Multiple intances of a singleton class when stored in session
ID: 40968
Updated by: [EMAIL PROTECTED]
Reported By: oriol dot gual at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: Session related
Operating System: Windows XP SP2
PHP Version: 5.2.1
New Comment:
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
Previous Comments:
[2007-04-02 13:24:44] smlerman at gmail dot com
The only thing that can guarantee only one instance of your class
existing is that Singleton::$instance is the only place you store an
instance and getInstance() is the only way to retrieve an instance. Once
you create a second place that an instance can be stored, such as
storing an instance somewhere else (in the session data) and destroying
the instance in the static property (which happens when the script
ends), you create a second way to retrieve an entirely different
instance. In general, there's no 100% guaranteed way to ensure that only
one instance of a given class can ever exist.
[2007-04-01 01:42:08] b dot fore at mail dot com
That's a gross abuse of ext/session dude.
[2007-03-31 16:54:52] oriol dot gual at gmail dot com
Description:
When storing an object of a singleton class in the session, you can
have more than one instance of that class in other subsequent
executions.
Reproduce code:
---
class Singleton {
private static $instance;
private function __construct() {}
final public static function getInstance()
{
if (!isset(Singleton::$instance))
{
Singleton::$instance = &new Singleton;
}
return Singleton::$instance;
}
}
session_start();
if(!isset($_SESSION['singleton'])) $_SESSION['singleton'] =
Singleton::getInstance();
$test = Singleton::getInstance();
$anotherTest = Singleton::getInstance();
var_dump(Singleton::getInstance() === $test);
var_dump(Singleton::getInstance() === $anotherTest);
var_dump($test === $anotherTest);
var_dump(Singleton::getInstance() === $_SESSION['singleton']);
var_dump($test === $_SESSION['singleton']);
var_dump($anotherTest === $_SESSION['singleton']);
session_write_close();
Expected result:
Session not started (first execution)
bool(true)
bool(true)
bool(true)
bool(true)
bool(true)
bool(true)
Subsequent executions
bool(true)
bool(true)
bool(true)
bool(true)
bool(true)
bool(true)
Actual result:
--
Session not started (first execution it's OK)
bool(true)
bool(true)
bool(true)
bool(true)
bool(true)
bool(true)
Subsequent executions (fails, multiple instances)
bool(true)
bool(true)
bool(true)
bool(false)
bool(false)
bool(false)
--
Edit this bug report at http://bugs.php.net/?id=40968&edit=1
#40967 [Opn->Fbk]: Resolved: execution environment change 'fixed' this??!!
ID: 40967
Updated by: [EMAIL PROTECTED]
Reported By: Webbed dot Pete at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: Reproducible crash
Operating System: Linux
PHP Version: 5.2.1
New Comment:
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
Previous Comments:
[2007-04-02 09:06:51] Webbed dot Pete at gmail dot com
[To answer your question directly: the getarray() function retrieves an
array from an in-memory global cache var]
Actually, the getarray() function is immaterial; it's never called when
the system is set in "crash mode". I put a debug trace-to-file on the
line before and after the array_merge() call, and also as the first
element of the getarray() function. The debug trace inside getarray() is
never called while getarray() is embedded in the array_merge() call.
Now the good-yet-a-bit-frustrating news: we've resolved this issue, in
an unusual way. The solution may be informative to other hard to
track-down bugs.
Bottom line: the array_merge() problem went away when our webhost
company rebuilt the custom php5 cgi script that runs php5 in the
phpSuExec environment! How the execution environment can have any impact
on array_merge() is beyond me, but that's the facts.
How we found this. Told here for the benefit of others who may find
similarly troubling issues:
I discovered another 500 error that *did* point to execution
environment (crash on chdir() with 100% perfect permissions) and
reported it to our sitehost tech support, who escalated it to top tier
support.
The chdir() crash was recognized as a phpSuExec issue, specifically "a
problem with our php5 cgi script that launches PHP5 with custom
configuration options which resulted in premature end of script headers
errors."
Unfortunately, the corrupted cgi script was not saved for analysis.
They simply ran their rebuild-php5-environment script, overwriting the
whole thing.
In retrospect, they suspect an update to cPanel may have corrupted the
script. The conversation continues: if an update did this, then perhaps
other servers in their farm have the same problem and can be diff'd with
mine. They don't keep backups of these scripts since they can be
auto-gen'd.
I hope that helps! I'm still amazed that *anything* in the execution
environment can impact the operation of something as benign as
array_merge().
Pete
[2007-04-01 22:51:22] judas dot iscariote at gmail dot com
Then tell use what the.. the getarray() function does **exactly**
[2007-03-31 15:06:34] Webbed dot Pete at gmail dot com
Description:
If I do
{
$from=getarray();
$tgt=array_merge($to,$from);
}
all is well. But if I do
{
$tgt=array_merge($to,getarray());
}
then the page blows up with a 500 internal server error (and getarray()
is never called).
I can't (yet) duplicate this as a simple test case; it only happens in
the middle of a large site source base.
This is on an Apache server (1.3.37) with PHP 5.2.1 running as CGI.
The *really* painful part is the 500 Internal Server Error, with no PHP
error messages of any kind. Made it incredibly painful to track this
down ;)
Reproduce code:
---
See above. I've not yet got a simple test case. All of the following
produce the 500 error:
$tgt=array_merge($to,getarray());
$tgt=array_merge($to,$from=getarray());
$tgt=array_merge($to,(array)getarray());
Only if the getarray() call is outside the array_merge() does it
succeed.
Expected result:
a) No error
b) Better debugability of 500 Internal Server Errors caused by PHP
Actual result:
--
500 Internal Server Error with no other message.
--
Edit this bug report at http://bugs.php.net/?id=40967&edit=1
#40964 [Opn->Bgs]: Variable lost data using session
ID: 40964 Updated by: [EMAIL PROTECTED] Reported By: joao at paintbox dot com dot br -Status: Open +Status: Bogus Bug Type: Session related Operating System: Windows 2003 / IIS 6 PHP Version: 5.2.1 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Previous Comments: [2007-03-30 21:57:56] joao at paintbox dot com dot br Description: I have 2 websites one of them are running in a Linux server with Apache and got NO PROBLEM... the other one is running in a Windows 2003 with IIS 6 and I have a problem. After change a page the values of session variables are lost. I wrote a simple test script but I didn't find a solution, I read lots of articles along the internet but dind't find a solution: teste_Sessao.php "; echo "User: ".$usr.""; echo "User2: ".$usracesso2.""; // making a link to the other page echo "teste_sessao2.php?PHPSESSID=".$idsession.""; ?> teste_sessao2.php "; echo "User: ".$usr.""; echo "User2: ".$usr2.""; ?> I have no problem to get SessionID value but the others variables (usr and usr2) lost their values. -- Edit this bug report at http://bugs.php.net/?id=40964&edit=1
#40954 [Opn->Bgs]: Apache conection lost during php
ID: 40954 Updated by: [EMAIL PROTECTED] Reported By: gbasco at gmail dot com -Status: Open +Status: Bogus Bug Type: Output Control Operating System: Linux 2.6.9-42.ELsmp PHP Version: 4.4.6 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Previous Comments: [2007-04-01 23:09:17] gbasco at gmail dot com PHP Version 5.2.1 System Linux xx 2.6.9-42.ELsmp #1 SMP Wed Jul 12 23:27:17 EDT 2006 i686 Build Date Mar 30 2007 04:29:37 Configure Command './configure' '--with-apxs2=/usr/local/apache2/bin/apxs' '--with-mysql' Server API Apache 2.0 Handler Virtual Directory Support disabled Configuration File (php.ini) Path /usr/local/lib/php.ini PHP API 20041225 PHP Extension 20060613 Zend Extension 220060519 Debug Build no Thread Safety disabled Zend Memory Manager enabled IPv6 Support enabled Registered PHP Streams php, file, data, http, ftp Registered Stream Socket Transports tcp, udp, unix, udg Registered Stream Filters string.rot13, string.toupper, string.tolower, string.strip_tags, convert.*, consumed, convert.iconv.* [EMAIL PROTECTED] conf]# ../bin/httpd -V Server version: Apache/2.2.4 (Unix) Server built: Mar 30 2007 04:24:59 Server's Module Magic Number: 20051115:4 Server loaded: APR 1.2.8, APR-Util 1.2.8 Compiled using: APR 1.2.8, APR-Util 1.2.8 Architecture: 32-bit Server MPM: Prefork threaded: no forked: yes (variable process count) Server compiled with -D APACHE_MPM_DIR="server/mpm/prefork" -D APR_HAS_SENDFILE -D APR_HAS_MMAP -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled) -D APR_USE_SYSVSEM_SERIALIZE -D APR_USE_PTHREAD_SERIALIZE -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT -D APR_HAS_OTHER_CHILD -D AP_HAVE_RELIABLE_PIPED_LOGS -D DYNAMIC_MODULE_LIMIT=128 -D HTTPD_ROOT="/usr/local/apache2" -D SUEXEC_BIN="/usr/local/apache2/bin/suexec" -D DEFAULT_PIDLOG="logs/httpd.pid" -D DEFAULT_SCOREBOARD="logs/apache_runtime_status" -D DEFAULT_LOCKFILE="logs/accept.lock" -D DEFAULT_ERRORLOG="logs/error_log" -D AP_TYPES_CONFIG_FILE="conf/mime.types" -D SERVER_CONFIG_FILE="conf/httpd.conf" [2007-03-29 21:53:06] gbasco at gmail dot com I miss spelled the Apache Server version, its Apache/2.0.52 [2007-03-29 21:51:53] gbasco at gmail dot com Description: Apache Webserver 20.52 with PHP lib4 4.4.6 works fine serving large images and normal html pages. But when it executes medium large , even a file only with phpinfo(); in it, its starts displaying the page then resets and the browser clear the page giving a no conection error. In the error_log a broken pipe msg appears at the same time. [Thu Mar 29 16:21:00 2007] [info] (32)Broken pipe: core_output_filter: writing data to the network -- Edit this bug report at http://bugs.php.net/?id=40954&edit=1
#40946 [Opn->Asn]: Use of newer GD install prevents text functions from working.
ID: 40946 Updated by: [EMAIL PROTECTED] Reported By: gfrank at neoservers dot com -Status: Open +Status: Assigned Bug Type: GD related Operating System: Linux 2.6.20 PHP Version: 4.4.6 Assigned To: pajoye Previous Comments: [2007-03-30 02:07:04] gfrank at neoservers dot com Oh, as for if I have a stack trace: Working on getting one. ulimit doesn't want to cooperate, but I'll have one sometime soon. The last few times a crash happened the system stalled out before a crashdump could be sent out (so much for my attempts to kill Apache before this happened). [2007-03-30 02:04:04] gfrank at neoservers dot com "Which web server do you use (and version, threaded or not)?" Apache 2.2.4, non-threaded (prefork) "Which error do you get? Do you have a backtrace?" Lots of: *** glibc detected *** double free or corruption (!prev): 0x2ad9b120 *** *** glibc detected *** malloc(): memory corruption: 0x2aaab08abba0 *** *** glibc detected *** double free or corruption (out): 0x2d465c70 *** *** glibc detected *** malloc(): memory corruption (fast): 0x2d465d50 *** *** glibc detected *** double free or corruption (fasttop): 0x01f3c7f0 *** *** glibc detected *** double free or corruption (fasttop): 0x2d064920 *** *** glibc detected *** double free or corruption (fasttop): 0x01bc1ab0 *** *** glibc detected *** double free or corruption (fasttop): 0x2c004c40 *** *** glibc detected *** double free or corruption (!prev): 0x00c5b370 *** *** glibc detected *** double free or corruption (out): 0x03d6ca50 *** *** glibc detected *** double free or corruption (out): 0x2f831df0 *** System would crash sometimes with the "double free or corruption (fasttop)" messages, but not always. The rest only seem to kill that specific child. Tracking the access_log for the times of the error points us to GD but it's virtually impossible to use that to determine what exactly caused it as there would be 60 or so different requests spanning virtually all of our services. "Do you get this error using the bundled GD? (compiled using "--with-gd") Can you also try using a 4.4 snapshot (http://snaps.php.net/)?" The error with text is NOT present in the bundled GD. It's only an issue with external GD (have tested 2.0.34 and 2.0.35RC2). What I will do is test the latest PHP snapshot with the external GD install. I'll post my results, tho it may be a few days before I can find the time to do this. Thanks. [2007-03-30 01:12:22] [EMAIL PROTECTED] "We actually did try specifying an absolute path to the font, and it still wouldn't work." Which web server do you use (and version, threaded or not)? "The reason we were trying the external GD was due to a string of glibc errors causing the system to crash, and after a lot of investigating we had reason to believe that the issue lied within GD as we heavily rely on it." Which error do you get? Do you have a backtrace? Do you get this error using the bundled GD? (compiled using "--with-gd") Can you also try using a 4.4 snapshot (http://snaps.php.net/)? "would you like me to respond?" yes, please. [2007-03-29 19:30:38] gfrank at neoservers dot com We actually did try specifying an absolute path to the font, and it still wouldn't work. The exact same code, however, worked with the bundled GD without issue. The reason we were trying the external GD was due to a string of glibc errors causing the system to crash, and after a lot of investigating we had reason to believe that the issue lied within GD as we heavily rely on it. Later this week I will recompile PHP back to the alternate config using the external GD and try your suggestion. If that also produces errors, would you like me to respond? Thank you. [2007-03-29 11:07:32] [EMAIL PROTECTED] "I'm not sure if this is an issue with PHP not being compatible with the newer GD or if this is a bug in GD." It is not really a bug, not in php neither in GD. Environment like apache requires an absolute path as the CWD differs. The problem is solved by PHP internal functions. the php CWD is used by php functions. Add: $font = realpath($font); Question, why do you want to use the external GD? 2.0.34 has not all new functions and improvements available in the bundled GD (but all bug fixes). I strongly recommend to use the bundled GD with php. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug rep
#40937 [Opn->Asn]: date() and dst update
ID: 40937
Updated by: [EMAIL PROTECTED]
Reported By: ctrlaltca at libero dot it
-Status: Open
+Status: Assigned
Bug Type: Date/time related
Operating System: Slackware Linux
PHP Version: 5.2.1
-Assigned To:
+Assigned To: derick
Previous Comments:
[2007-03-31 17:51:15] ctrlaltca at libero dot it
sorry, i forgot to update bug summary
[2007-03-31 17:49:20] ctrlaltca at libero dot it
First, thank you for the reply.
I tried the script:
|Sat, 31 Mar 2007 00:00:00 +=Sat, 31 Mar 2007 17:18:59
+|1174780800=1174843139|20070324 23=20070325 171859|
I understand that strtotime($d. "-1 day") is an alias for "-24 hours",
and dst handling routines adds one more hour to compensate.
Afaik summer time begins and ends at 1:00 a.m. Universal Time (GMT) in
Europe, and at 2:00 a.m. localtime in the US. Other states do it at
midnight (example: Chile).
Trying this other script it seems that php updates the time at
midnight:
Do all we live in Chile? :) Or am i wrong again?
Thank you again for your comment, i'll use gm* class of functions.
[2007-03-28 19:11:01] [EMAIL PROTECTED]
We are happy to tell you that you just discovered Daylight Savings
Time. For more information see:
http://webexhibits.org/daylightsaving/b.html
Instead of using mktime/date consider using gmmktime and gmdate which
do
not suffer from DST.
Try this script instead, that also shows the time to see what's
happening:
=0; $i--)
{
$a=mktime(0, 0, 0, $mo,$day, $year);
$b=date("r",$a);
$c=strtotime($b. "-" . $i . " day");
$curdate=date("Ymd His",$c);
$d=date("r");
$e=strtotime($d. "-" . $i . " day");
$curdate2=date("Ymd His",$e);
echo
"\n|".$b."=".$d."|".$c."=".$e."|".$curdate."=".$curdate2."|";
}
?>
[2007-03-28 15:21:00] ctrlaltca at libero dot it
Description:
It seems that the date() function "jumps over" sundays when converting
timestamps not referring to midnight.
Similar to #461
Reproduce code:
---
=0; $i--)
{
$a=mktime(0, 0, 0, $mo,$day, $year);
$b=date("r",$a);
$c=strtotime($b. "-" . $i . " day");
$curdate=date("Ymd",$c);
$d=date("r");
$e=strtotime($d. "-" . $i . " day");
$curdate2=date("Ymd",$e);
echo
"\n|".$b."=".$d."|".$c."=".$e."|".$curdate."=".$curdate2."|";
}
?>
Expected result:
I expect this script to return the right "Ymd" dates of the last seven
days.
Actual result:
--
It works:
|Wed, 28 Mar 2007 00:00:00 +0200=Wed, 28 Mar 2007 17:13:37
+0200|1175032800=1175094817|20070328!=20070328|
but when it finds a sunday, dates are shifted off of 1 day:
|Wed, 28 Mar 2007 00:00:00 +0200=Wed, 28 Mar 2007 17:13:37
+0200|1174773600=1174835617|20070324!=20070325|
--
Edit this bug report at http://bugs.php.net/?id=40937&edit=1
#40935 [Opn->Fbk]: Error/Exception with PDO::fetch/fetchAll and disabled ATTR_EMULATE_PREPARES
ID: 40935
Updated by: [EMAIL PROTECTED]
Reported By: phpbugs at filofox dot com
-Status: Open
+Status: Feedback
Bug Type: PDO related
Operating System: Linux Debian Sarge 3.1
PHP Version: 5.2.1
New Comment:
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
Previous Comments:
[2007-03-28 13:28:58] phpbugs at filofox dot com
Description:
When using PDO with MySQL, if ATTR_EMULATE_PREPARES is disabled, an
exception (or error if not using ERRMODE_EXCEPTION) is thrown if you try
to fetch() or fetchAll() a null result set (i.e. after INSERT, UPDATE
etc.). However, if ATTR_EMULATE_PREPARES is enabled, the exception/error
is not triggered.
Clearly fetch on a null result set is redundant, but either it should
throw an exception/error or it shouldn't, regardless of the state of
ATTR_EMULATE_PREPARES.
Reproduce code:
---
$db = new PDO( $dsn, $username, $password );
// enables exceptions
$db->setAttribute( PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION );
// disable emulation <--- this triggers the problem
$db->setAttribute( PDO::ATTR_EMULATE_PREPARES, false );
$sql = 'INSERT INTO TestTable VALUES ( NULL )';
$query = $db->prepare( $sql );
if( $query->execute() )
{
$results = $query->fetchAll( PDO::FETCH_ASSOC );
}
$query->closeCursor();
Expected result:
Either an exception/error should be thrown in both cases, or neither.
Actual result:
--
'PDOException' :: 'SQLSTATE[HY000]: General error: 2053 '
--
Edit this bug report at http://bugs.php.net/?id=40935&edit=1
#40922 [Opn->Asn]: parse_packet_soap does not decode objects properties from local message schema
ID: 40922
Updated by: [EMAIL PROTECTED]
Reported By: php dot ajr at vitalphone dot net
-Status: Open
+Status: Assigned
-Bug Type: SOAP related
+Bug Type: Feature/Change Request
Operating System: Mandriva Linux 2007.0
PHP Version: 5.1.6
-Assigned To:
+Assigned To: dmitry
Previous Comments:
[2007-03-31 16:10:48] php dot ajr at vitalphone dot net
Best category about this bug or featur
[2007-03-26 15:00:43] php dot ajr at vitalphone dot net
Removed version at the first time.
[2007-03-26 14:42:11] php dot ajr at vitalphone dot net
Description:
Hi,
Our script are using PHP5/SOAP functionality. It interoperates with
.Net Webservices. The server WSDL does not content the description of
object properties. The Microsoft Server return the XML Schema for the
object properties into the response with the data in the "Diffgr"
contener like :
-
--
---
---
---
---
---
--
-
and
-
--
---DSLFMTIF
---6048
---14528
---256
---SHARED
--
--
---DSLFMDTTIF
---6048
---14528
---256
---FULL
--
-
The parse_packet_soap.c programm decodes the object properties only
from the WSDL schema, see the lines between 257 and 342. For the
compatibility with all webservice form, it is necessary to add the
property decoding from the response XML schema.
Reproduce code:
---
$client = new
SoapClient('http://test.isdbwssignup.telecomitalia-entreprises.fr/WSSignup.asmx?WSDL',
array('trace' => 1, 'soap_version' => SOAP_1_1));
$resultat = $client->GetInfoEligibility($parametres);
//
// Affichage du resultat
//
echo 'Analyse du resultat';
var_dump($resultat);
Expected result:
-
--
---DSLFMTIF
---6048
---14528
---256
---SHARED
--
--
---DSLFMDTTIF
---6048
---14528
---256
---FULL
--
-
Actual result:
--
object(stdClass)#3 (1) { ["GetInfoEligibilityResult"]=>
object(stdClass)#4 (1) { ["any"]=> string(10418)
"DSLFMTIF604814528256SHAREDDSLFMDTTIF604814528256FULL" } }
--
Edit this bug report at http://bugs.php.net/?id=40922&edit=1
#40937 [Asn->Fbk]: date() and dst update
ID: 40937
Updated by: [EMAIL PROTECTED]
Reported By: ctrlaltca at libero dot it
-Status: Assigned
+Status: Feedback
Bug Type: Date/time related
Operating System: Slackware Linux
PHP Version: 5.2.1
Assigned To: derick
New Comment:
What does the following output:
echo date_default_timezone_get(), "\n";
Previous Comments:
[2007-03-31 17:51:15] ctrlaltca at libero dot it
sorry, i forgot to update bug summary
[2007-03-31 17:49:20] ctrlaltca at libero dot it
First, thank you for the reply.
I tried the script:
|Sat, 31 Mar 2007 00:00:00 +=Sat, 31 Mar 2007 17:18:59
+|1174780800=1174843139|20070324 23=20070325 171859|
I understand that strtotime($d. "-1 day") is an alias for "-24 hours",
and dst handling routines adds one more hour to compensate.
Afaik summer time begins and ends at 1:00 a.m. Universal Time (GMT) in
Europe, and at 2:00 a.m. localtime in the US. Other states do it at
midnight (example: Chile).
Trying this other script it seems that php updates the time at
midnight:
Do all we live in Chile? :) Or am i wrong again?
Thank you again for your comment, i'll use gm* class of functions.
[2007-03-28 19:11:01] [EMAIL PROTECTED]
We are happy to tell you that you just discovered Daylight Savings
Time. For more information see:
http://webexhibits.org/daylightsaving/b.html
Instead of using mktime/date consider using gmmktime and gmdate which
do
not suffer from DST.
Try this script instead, that also shows the time to see what's
happening:
=0; $i--)
{
$a=mktime(0, 0, 0, $mo,$day, $year);
$b=date("r",$a);
$c=strtotime($b. "-" . $i . " day");
$curdate=date("Ymd His",$c);
$d=date("r");
$e=strtotime($d. "-" . $i . " day");
$curdate2=date("Ymd His",$e);
echo
"\n|".$b."=".$d."|".$c."=".$e."|".$curdate."=".$curdate2."|";
}
?>
[2007-03-28 15:21:00] ctrlaltca at libero dot it
Description:
It seems that the date() function "jumps over" sundays when converting
timestamps not referring to midnight.
Similar to #461
Reproduce code:
---
=0; $i--)
{
$a=mktime(0, 0, 0, $mo,$day, $year);
$b=date("r",$a);
$c=strtotime($b. "-" . $i . " day");
$curdate=date("Ymd",$c);
$d=date("r");
$e=strtotime($d. "-" . $i . " day");
$curdate2=date("Ymd",$e);
echo
"\n|".$b."=".$d."|".$c."=".$e."|".$curdate."=".$curdate2."|";
}
?>
Expected result:
I expect this script to return the right "Ymd" dates of the last seven
days.
Actual result:
--
It works:
|Wed, 28 Mar 2007 00:00:00 +0200=Wed, 28 Mar 2007 17:13:37
+0200|1175032800=1175094817|20070328!=20070328|
but when it finds a sunday, dates are shifted off of 1 day:
|Wed, 28 Mar 2007 00:00:00 +0200=Wed, 28 Mar 2007 17:13:37
+0200|1174773600=1174835617|20070324!=20070325|
--
Edit this bug report at http://bugs.php.net/?id=40937&edit=1
#40973 [Opn->Fbk]: session don't work if used $_SERVER in any way
ID: 40973
Updated by: [EMAIL PROTECTED]
Reported By: krassesache at gmx dot net
-Status: Open
+Status: Feedback
Bug Type: Session related
Operating System: WinXP SP2
PHP Version: 5.2.1
New Comment:
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
Works perfectly fine.
Previous Comments:
[2007-04-01 16:12:13] krassesache at gmx dot net
Description:
if i use $_SERVER in any way but with pdo statements [
$stmt->execute(array($_SERVER['REMOTE_ADDR'])) ] a session will not
work.
in my example i first open foobar.php and then foobar2.php. if remove
the 4th line in foobar2.php [ $var = $_SERVER['REMOTE_ADDR']; ] the the
text "bar" appears but with the line, nothing happens. in other case is
used preg_match('#MSIE#',$_SERVER['HTTP_USER_AGENT']) with the result
that the website will be shown but the session dont work (the original
problem).
Reproduce code:
---
=> foobar.php
=> foobar2.php
Expected result:
bar
Actual result:
--
--
Edit this bug report at http://bugs.php.net/?id=40973&edit=1
#40957 [Opn->Bgs]: PDO & UTF8 string length & truncate issues
ID: 40957
Updated by: [EMAIL PROTECTED]
Reported By: gerald at copix dot org
-Status: Open
+Status: Bogus
Bug Type: PDO related
Operating System: Linux
PHP Version: 5.2.1
New Comment:
UTF8 requires 2 bytes per character.
Your database can store only 2 bytes (because it's ISO8859), but you're
trying to put 4 and receive the expected error.
Not PHP problem.
Previous Comments:
[2007-03-30 09:27:32] gerald at copix dot org
I made a mistake writing the actual result, it is obviously :
(array[0]->MYFIELD === 'é') === true
(array[0]->MYFIELD === 'éa') === false
Sorry for the typo.
[2007-03-30 09:19:21] gerald at copix dot org
Description:
Hello,
While configured in UTF8 mode (eg with the connection string
allRequiredInfos;charset=UTF8), when we try to get a VARCHAR2 field
limited to X chars, PDO is assuming accents (éà è...) are 2 letters
length) and then generates a warning if our content is X chars length
(with accents) and truncates the end of the field.
Warning: PDOStatement::fetchAll()
[scriptAdr/function.PDOStatement-fetchAll]: column 0 data was too large
for buffer and was truncated to fit it in /scriptPath.class.php on line
73
We tryed to activate mbstring extension, to use func_overload=4 with no
success (the database itself is in ISO-8859-1).
If we try not to communicate with the database in UTF8, accents are
just ignored (é becomes e, ...) even with correct session parameters.
Reproduce code:
---
Considering the table
MYTABLE {
MYFIELD VARCHAR2(2);
}
with one record :
MyField
éa
$pdo = new PDO ('pdo_oci:dbname=
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = myhost)(PORT = 1521))
)
(CONNECT_DATA =
(SID = mysid)
)
);charset=UTF8', 'myLogin', 'myPassword');
$stmt = $pdo->doQuery ('select MYFIELD from MYTABLE');
$stmt->fetchAll (); //warning
Expected result:
(array[0]->MYFIELD === 'éa') === true;
Actual result:
--
(array[0]->MYFIELD === 'é') === true
(array[0]->MYFIELD === 'éa') === true
--
Edit this bug report at http://bugs.php.net/?id=40957&edit=1
#39351 [Opn->Csd]: require and include fails to open file in current directory
ID: 39351
Updated by: [EMAIL PROTECTED]
Reported By: lampiluoto at gmail dot com
-Status: Open
+Status: Closed
Bug Type: *Directory/Filesystem functions
Operating System: Solaris10
PHP Version: 5.2.0
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:
[2007-04-02 15:33:04] nospam at dede dot fr
It's been five month that the bug is open...
Is there a chance that it'll be resolved in PHP 5.2.2 ?
The bug exits too when including (include or require function) by using
.. : for example : include("../test.php");
[2007-03-28 16:45:15] koper at koper dot biz
I've experienced the same bug on Solaris 10 with PHP 5.2.1 and Apache
2.2.4. The solution (at least temporary) is to allow webservd (apache
uid/gid) +rx on every directory leading to DocumentRoot.
[2007-03-12 15:00:20] webtech at get-telecom dot fr
I've tried with "allow_url_include = On",
but with PHP 5.2.1, I've the same include problem.
[2007-03-10 13:22:44] lampiluoto at gmail dot com
Hi,
I emailed with Tony about providing
Sol10 environment for reproducing the
problem and debugging it.
--
Tero
[2007-03-07 07:38:42] [EMAIL PROTECTED]
>Anybody looking to fix this bug?
No, we're unable to replicate it.
If you have a Solaris10 handy - please provide an account with PHP,
GDB, GCC and other utils required to reproduce and invesigate it.
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/39351
--
Edit this bug report at http://bugs.php.net/?id=39351&edit=1
#40967 [Fbk->Opn]: Please read the report... not one that needs php script ;)
ID: 40967
User updated by: Webbed dot Pete at gmail dot com
-Summary: Resolved: execution environment change 'fixed'
this??!!
Reported By: Webbed dot Pete at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: Reproducible crash
Operating System: Linux
PHP Version: 5.2.1
New Comment:
Tony,
Sorry but the boilerplate response doesn't match the bug report.
I've already diagnosed the 'bug' as far as possible. Apparently the
real issue had more to do with a strange interaction with the run
environment more than with the code itself.
For now this might as well be placed on hold until someone else finds a
similar situation, because my host provider lost the 'buggy' version of
the php5-cgi-run script.
For now, my hope is that this report will at least help others track
down the problem when they see similar attributes.
Previous Comments:
[2007-04-03 18:47:08] [EMAIL PROTECTED]
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.
[2007-04-02 09:06:51] Webbed dot Pete at gmail dot com
[To answer your question directly: the getarray() function retrieves an
array from an in-memory global cache var]
Actually, the getarray() function is immaterial; it's never called when
the system is set in "crash mode". I put a debug trace-to-file on the
line before and after the array_merge() call, and also as the first
element of the getarray() function. The debug trace inside getarray() is
never called while getarray() is embedded in the array_merge() call.
Now the good-yet-a-bit-frustrating news: we've resolved this issue, in
an unusual way. The solution may be informative to other hard to
track-down bugs.
Bottom line: the array_merge() problem went away when our webhost
company rebuilt the custom php5 cgi script that runs php5 in the
phpSuExec environment! How the execution environment can have any impact
on array_merge() is beyond me, but that's the facts.
How we found this. Told here for the benefit of others who may find
similarly troubling issues:
I discovered another 500 error that *did* point to execution
environment (crash on chdir() with 100% perfect permissions) and
reported it to our sitehost tech support, who escalated it to top tier
support.
The chdir() crash was recognized as a phpSuExec issue, specifically "a
problem with our php5 cgi script that launches PHP5 with custom
configuration options which resulted in premature end of script headers
errors."
Unfortunately, the corrupted cgi script was not saved for analysis.
They simply ran their rebuild-php5-environment script, overwriting the
whole thing.
In retrospect, they suspect an update to cPanel may have corrupted the
script. The conversation continues: if an update did this, then perhaps
other servers in their farm have the same problem and can be diff'd with
mine. They don't keep backups of these scripts since they can be
auto-gen'd.
I hope that helps! I'm still amazed that *anything* in the execution
environment can impact the operation of something as benign as
array_merge().
Pete
[2007-04-01 22:51:22] judas dot iscariote at gmail dot com
Then tell use what the.. the getarray() function does **exactly**
[2007-03-31 15:06:34] Webbed dot Pete at gmail dot com
Description:
If I do
{
$from=getarray();
$tgt=array_merge($to,$from);
}
all is well. But if I do
{
$tgt=array_merge($to,getarray());
}
then the page blows up with a 500 internal server error (and getarray()
is never called).
I can't (yet) duplicate this as a simple test case; it only happens in
the middle of a large site source base.
This is on an Apache server (1.3.37) with PHP 5.2.1 running as CGI.
The *really* painful part is the 500 Internal Server Error, with no PHP
error messages of any kind. Made it incredibly painful to track this
down ;)
Reproduce code:
---
See above. I've not yet got a simple test case. All of the following
produce the 500 error:
$tgt=array_merge($to,getarray());
$tgt=array_merge($to,$from=getarray());
$tgt=array_merge($to,(array)getarray());
Only if the getarray() call is outside the array_merge() does it
succeed.
Expected result:
a) No error
b) Better debugability of 500 Internal Server
#40967 [Opn->Bgs]: Please read the report... not one that needs php script ;)
ID: 40967
Updated by: [EMAIL PROTECTED]
Reported By: Webbed dot Pete at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: Reproducible crash
Operating System: Linux
PHP Version: 5.2.1
New Comment:
500 Error is not PHP problem.
Please reopen the report when/if you have more information on the issue
and how to reproduce it.
It doesn't make much sense to keep the report in the current state,
because I can name you thousand reasons for this behaviour and all of
them has nothing to do with PHP.
Previous Comments:
[2007-04-03 21:02:52] Webbed dot Pete at gmail dot com
Tony,
Sorry but the boilerplate response doesn't match the bug report.
I've already diagnosed the 'bug' as far as possible. Apparently the
real issue had more to do with a strange interaction with the run
environment more than with the code itself.
For now this might as well be placed on hold until someone else finds a
similar situation, because my host provider lost the 'buggy' version of
the php5-cgi-run script.
For now, my hope is that this report will at least help others track
down the problem when they see similar attributes.
[2007-04-03 18:47:08] [EMAIL PROTECTED]
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.
[2007-04-02 09:06:51] Webbed dot Pete at gmail dot com
[To answer your question directly: the getarray() function retrieves an
array from an in-memory global cache var]
Actually, the getarray() function is immaterial; it's never called when
the system is set in "crash mode". I put a debug trace-to-file on the
line before and after the array_merge() call, and also as the first
element of the getarray() function. The debug trace inside getarray() is
never called while getarray() is embedded in the array_merge() call.
Now the good-yet-a-bit-frustrating news: we've resolved this issue, in
an unusual way. The solution may be informative to other hard to
track-down bugs.
Bottom line: the array_merge() problem went away when our webhost
company rebuilt the custom php5 cgi script that runs php5 in the
phpSuExec environment! How the execution environment can have any impact
on array_merge() is beyond me, but that's the facts.
How we found this. Told here for the benefit of others who may find
similarly troubling issues:
I discovered another 500 error that *did* point to execution
environment (crash on chdir() with 100% perfect permissions) and
reported it to our sitehost tech support, who escalated it to top tier
support.
The chdir() crash was recognized as a phpSuExec issue, specifically "a
problem with our php5 cgi script that launches PHP5 with custom
configuration options which resulted in premature end of script headers
errors."
Unfortunately, the corrupted cgi script was not saved for analysis.
They simply ran their rebuild-php5-environment script, overwriting the
whole thing.
In retrospect, they suspect an update to cPanel may have corrupted the
script. The conversation continues: if an update did this, then perhaps
other servers in their farm have the same problem and can be diff'd with
mine. They don't keep backups of these scripts since they can be
auto-gen'd.
I hope that helps! I'm still amazed that *anything* in the execution
environment can impact the operation of something as benign as
array_merge().
Pete
[2007-04-01 22:51:22] judas dot iscariote at gmail dot com
Then tell use what the.. the getarray() function does **exactly**
[2007-03-31 15:06:34] Webbed dot Pete at gmail dot com
Description:
If I do
{
$from=getarray();
$tgt=array_merge($to,$from);
}
all is well. But if I do
{
$tgt=array_merge($to,getarray());
}
then the page blows up with a 500 internal server error (and getarray()
is never called).
I can't (yet) duplicate this as a simple test case; it only happens in
the middle of a large site source base.
This is on an Apache server (1.3.37) with PHP 5.2.1 running as CGI.
The *really* painful part is the 500 Internal Server Error, with no PHP
error messages of any kind. Made it incredibly painful to track this
down ;)
Reproduce code:
---
See above. I've not yet got a simple test case. All of the follow
#40967 [Bgs]: On hold until seen again
ID: 40967 User updated by: Webbed dot Pete at gmail dot com -Summary: Please read the report... not one that needs php script ;) Reported By: Webbed dot Pete at gmail dot com Status: Bogus Bug Type: Reproducible crash Operating System: Linux PHP Version: 5.2.1 New Comment: "It doesn't make much sense to keep the report in the current state" I certainly agree! :) "I can name you thousand reasons for this behaviour and all of them has nothing to do with PHP." Well, in this case it's clearly not the interpreter itself but MAY be related to the PHP environment variables used for setup. As you suggested, we'll ask our network to report any similar situation(s). Thanks much! Previous Comments: [2007-04-03 21:10:15] [EMAIL PROTECTED] 500 Error is not PHP problem. Please reopen the report when/if you have more information on the issue and how to reproduce it. It doesn't make much sense to keep the report in the current state, because I can name you thousand reasons for this behaviour and all of them has nothing to do with PHP. [2007-04-03 21:02:52] Webbed dot Pete at gmail dot com Tony, Sorry but the boilerplate response doesn't match the bug report. I've already diagnosed the 'bug' as far as possible. Apparently the real issue had more to do with a strange interaction with the run environment more than with the code itself. For now this might as well be placed on hold until someone else finds a similar situation, because my host provider lost the 'buggy' version of the php5-cgi-run script. For now, my hope is that this report will at least help others track down the problem when they see similar attributes. [2007-04-03 18:47:08] [EMAIL PROTECTED] 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. [2007-04-02 09:06:51] Webbed dot Pete at gmail dot com [To answer your question directly: the getarray() function retrieves an array from an in-memory global cache var] Actually, the getarray() function is immaterial; it's never called when the system is set in "crash mode". I put a debug trace-to-file on the line before and after the array_merge() call, and also as the first element of the getarray() function. The debug trace inside getarray() is never called while getarray() is embedded in the array_merge() call. Now the good-yet-a-bit-frustrating news: we've resolved this issue, in an unusual way. The solution may be informative to other hard to track-down bugs. Bottom line: the array_merge() problem went away when our webhost company rebuilt the custom php5 cgi script that runs php5 in the phpSuExec environment! How the execution environment can have any impact on array_merge() is beyond me, but that's the facts. How we found this. Told here for the benefit of others who may find similarly troubling issues: I discovered another 500 error that *did* point to execution environment (crash on chdir() with 100% perfect permissions) and reported it to our sitehost tech support, who escalated it to top tier support. The chdir() crash was recognized as a phpSuExec issue, specifically "a problem with our php5 cgi script that launches PHP5 with custom configuration options which resulted in premature end of script headers errors." Unfortunately, the corrupted cgi script was not saved for analysis. They simply ran their rebuild-php5-environment script, overwriting the whole thing. In retrospect, they suspect an update to cPanel may have corrupted the script. The conversation continues: if an update did this, then perhaps other servers in their farm have the same problem and can be diff'd with mine. They don't keep backups of these scripts since they can be auto-gen'd. I hope that helps! I'm still amazed that *anything* in the execution environment can impact the operation of something as benign as array_merge(). Pete [2007-04-01 22:51:22] judas dot iscariote at gmail dot com Then tell use what the.. the getarray() function does **exactly** The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report
#40894 [Asn->Csd]: fix for bug #38770 causes more harm than good on big-endian 64bit
ID: 40894 Updated by: [EMAIL PROTECTED] Reported By: mmarek at suse dot cz -Status: Assigned +Status: Closed Bug Type:*Programming Data Structures PHP Version: 5.2.1 Assigned To: iliaa 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: [2007-03-22 15:59:03] mmarek at suse dot cz Description: Fix for bug #38770 breaks unpack() on big-endian 64bit, because it reads uninitialized memory or memory that doesn't relate to the data being processed. In http://cvs.php.net/viewvc.cgi/php-src/ext/standard/pack.c?r1=1.62&r2=1.63 input[inputpos + machine_endian_long_map[3]] will read input[inputpos+7] when unpacking 4 bytes. Please revert the fix, as it tries to fix a questionable issue (-3 simply doesn't fit into unsigned type) and causes trouble in cases where it worked before (eg. pear is not even installable on POWER, b/c install-pear-nozlib.phar makes heavy use of unpack()). Reproduce code: --- run print_r( unpack( "V", pack( "V", 200 ) )); several times on ppc64. Expected result: It should output Array ( [1] => 200 ) all the time. Actual result: -- # ./sapi/cli/php -r 'print_r( unpack( "V", pack( "V", 200 ) ));' Array ( [1] => 200 ) # ./sapi/cli/php -r 'print_r( unpack( "V", pack( "V", 200 ) ));' Array ( [1] => -2147483448 ) # ./sapi/cli/php -r 'print_r( unpack( "V", pack( "V", 200 ) ));' Array ( [1] => 200 ) # ./sapi/cli/php -r 'print_r( unpack( "V", pack( "V", 200 ) ));' Array ( [1] => 200 ) # ./sapi/cli/php -r 'print_r( unpack( "V", pack( "V", 200 ) ));' Array ( [1] => -2147483448 ) -- Edit this bug report at http://bugs.php.net/?id=40894&edit=1
#40841 [Asn->Fbk]: #38770/#40543 Not fixed on Solaris 10
ID: 40841 Updated by: [EMAIL PROTECTED] Reported By: lovan at lifesci dot ucsb dot edu -Status: Assigned +Status: Feedback Bug Type: Unknown/Other Function Operating System: Solaris 10 PHP Version: 5.2.1 Assigned To: iliaa New Comment: 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 Previous Comments: [2007-03-30 01:35:24] brian at eng dot wayne dot edu Sorry, I should have said - not exactly the same but similar: Warning: unpack(): Type V: not enough input, need 4, have 0 in /usr/people/brian /php5.2-200703280830/pear/install-pear-nozlib.phar on line 290 Warning: unpack(): Type V: not enough input, need 4, have 0 in /usr/people/brian /php5.2-200703280830/pear/install-pear-nozlib.phar on line 302 Warning: array_values(): The argument should be an array in /usr/people/brian/ph p5.2-200703280830/pear/install-pear-nozlib.phar on line 302 Notice: Undefined offset: 5 in /usr/people/brian/php5.2-200703280830/pear/insta ll-pear-nozlib.phar on line 304 Notice: Undefined offset: 2 in /usr/people/brian/php5.2-200703280830/pear/insta ll-pear-nozlib.phar on line 311 Notice: Undefined offset: 5 in /usr/people/brian/php5.2-200703280830/pear/insta ll-pear-nozlib.phar on line 312 Fatal error: Error: "index.php" is not a file in phar "install-pear-nozlib.phar" in /usr/people/brian/php5.2-200703280830/pear/install-pear-nozlib.phar on line 543 [2007-03-30 01:32:02] brian at eng dot wayne dot edu I'm seeing the same error message on SGI IRIX 6.5/64-bit using the commercial IRIX MIPSPro C compiler. [2007-03-20 16:41:24] lovan at lifesci dot ucsb dot edu I'm saying that the 5.2.0 unpack core dumped under GCC 4.1.2 on Solaris 10 but worked on Solaris 10 if compiled using the Sun C compiler. I'm also saying that the 5.2.1 unpack reports spurious errors instead of core dumping (regardless of compiler) on Solaris 10. [2007-03-20 14:57:41] [EMAIL PROTECTED] so you are saying that PHP 5.2.0 worked fine on Solaris 10, but PHP 5.2.1 doesn't? The phar did not change between PHP 5.2.0 and PHP 5.2.1. That sounds like a regression in unpack(), not a phar issue. Changing to feedback to confirm that I understand the user's last comment, and re-assigning to tony, with the assumption that it is an unpack() regression [2007-03-19 19:17:01] lovan at lifesci dot ucsb dot edu Update: I tried compiling 5.2.0 to see if I could narrow the problem. First I compiled it using GCC 4.1.2 (CFLAGS="-m64 -mcpu=v9"). When this binary attempted to unpack the phar archives, it segfaulted. I then compiled it using SunPro CC (CFLAGS="-xtarget=ultra -xarch=v9b -xcode=pic32"). This compiled and installed cleanly though it fails many more pieces of a "make test". 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/40841 -- Edit this bug report at http://bugs.php.net/?id=40841&edit=1
#40749 [Asn->Fbk]: pack and unpack erroneous behavior on 64bits hosts
ID: 40749
Updated by: [EMAIL PROTECTED]
Reported By: ben at ateor dot com
-Status: Assigned
+Status: Feedback
Bug Type: Unknown/Other Function
Operating System: OpenBSD amd64 and sparc64
PHP Version: 5.2.1
Assigned To: iliaa
New Comment:
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
Previous Comments:
[2007-03-16 14:03:01] martin at netimage dot dk
It appears that the sign bit is taken from LSB instead of MSB
> php -r 'print_r( unpack('N',pack('N',127)));'
Array
(
[1] => 127
)
> php -r 'print_r( unpack('N',pack('N',128)));'
Array
(
[1] => -2147483520
)
The last number is 2's complement of -128 for 32 bit integers
Cheers
[2007-03-14 20:57:41] pz at mysqlperformanceblog dot com
In any case if you call it bug or a feature this is serious behavior
change for something which a lot of people could be depending on.
It breaks in MySQL 5.2.0 -> 5.2.1 which is minor version upgrade.
[2007-03-09 09:06:47] windeler at mediafinanz dot de
Here is another example of a problem with unpack on 64bit systems. It
worked in 5.1.6, but with 5.2.1 the results are bogus.
The expected value from the file content is 200, but PHP says
-2147483448 when I echo $a['i'].
[2007-03-07 17:12:58] ben at ateor dot com
Description:
This is a follow-up on #40543 (http://bugs.php.net/bug.php?id=40543,
since
that bug is closed, I can't add comments).
Please note : it's not identical to #4053 (other weird behaviors
are demonstrated).
Iliaa,
Not sure why you suggest to use little endian or host conversions
routines,
but in my standpoint if you reverse twice a number's byte ordering
then you should get the original number back (assuming the number
don't
overflows php's internals).
At least, that's the standard behavior for perl and python.
Beside, I can't see why php should handles those endianness
conversions
differently on an i386 (32 bits) and on an x86_64 (64 bits), both
having the same byte order.
The following on a 64bit, little endian host :
x86_64$ uname -mprsv
OpenBSD 4.0 GENERIC#0 amd64 AMD Sempron(tm) Processor 3400+
x86_64$ perl -e 'print unpack("N", pack("N", 41445)) ."\n"'
41445
x86_64$ python
Python 2.4.3 (#1, Sep 6 2006, 20:33:08)
[GCC 3.3.5 (propolice)] on openbsd4
Type "help", "copyright", "credits" or "license" for more information.
>>> from struct import *
>>> unpack('>L', pack('>L', 41445))
(41445L,)
And, indeed :
#include
#include
int main(void)
{
u_int32_t x, y, z; /* 32 bits unsigned longs */
x = 41445;
/* conv host (little) to network (big endian) long : pack("N",
41445) */
y = htonl(x);
/* conv network (big endian) to host (little) long :
unpack("N", ...) */
z = ntohl(y);
printf("Host : %li\nBig : %li\nHost : %li\n", x, y, z);
return 0;
}
x86_64$ gcc conv.c -o conv ; ./conv
Host : 41445
Big : -442433536
Host : 41445
But still (PHP 5.2.2-dev (cli) (built: Feb 27 2007 22:10:11)) :
x86_64$ php -r 'print_r(unpack("N", pack("N", 41445)));'
Array
(
[1] => -2147442203
)
While on a plain old x86 little endian host (PHP 4.4.0), we get
a different result :
i386_32$ uname -mprsv
OpenBSD 3.9 GENERIC#0 i386 Intel(R) Pentium(R) 4 CPU 1.70GHz
("GenuineIntel" 686-class)
i386_32$ php -r 'print_r(unpack("N", pack("N", 41445)));'
Array
(
[1] => 41445
)
Still on the 64 bits little endian host :
x86_64$ php -r '$a = unpack("N", pack("N", 65536));
printf("$a[1]\n");'
65536 # Ok
x86_64$ php -r '$a = unpack("N", pack("N", 65535));
printf("$a[1]\n");'
-2147418113 # Weird
x86_64$ php -r '$a = unpack("N", pack("N", 0x1234)); printf("0x%x\n",
$a[1]);'
0x1234 # Ok
x86_64$ php -r '$a = unpack("L", pack("N", 0x1234)); printf("0x%x\n",
$a[1]);'
0x3412 # Ok
x86_64$ php -r '$a = unpack("L", pack("L", 0x)); printf("0x%x\n",
$a[1]);'
0x # Ok
x86_64$ php -r '$a = unpack("N", pack("N", 0x)); printf("0x%x\n",
$a[1]);'
0x8000 # The doc says "N" gives you "always 32 bit", and we
get
# 8 bytes. No wonder why we overflow.
x86_64$ php -r '$a = unpack("N", pack("N", 0xff )); printf("0x%x\n",
$a[1]);'
0x80ff # Same. Don't tell me 0xff is too large.
And now, all the following tests are on a 64 bits _big endian_ host
(sparc64, running php-5.2.1) :
sparc64$ uname -mprsv
OpenBSD 3.8 GENERIC#607 sparc64 SUNW,UltraSPARC-IIi @ 440 MHz, version
0 FPU
sparc64$ php -r '$a = unpack("N", pack("N", 0x)); printf("0x%x\n",
$a[1]);'
0x # Ok
# The same, but prefixing to the argument :
sparc64$ php -
#40985 [Fbk]: CLI version crashes while trying to shutdown, using tsrm_shutdown()
ID: 40985
Updated by: [EMAIL PROTECTED]
Reported By: charlie at lemurconsulting dot com
Status: Feedback
Bug Type: Reproducible crash
Operating System: Windows XP
PHP Version: 5.2.1
New Comment:
This seams to me like a problem outside of PHP. The xapian extension
create module globals but does not do any cleanup. Looks to me like it
can be solved with code like this:
PHP_MSHUTDOWN_FUNCTION(printer)
{
#ifdef ZTS
ts_free_id(printer_globals_id);
#else
php_printer_shutdown(&printer_globals TSRMLS_CC);
#endif
UNREGISTER_INI_ENTRIES();
return SUCCESS;
}
I have not tested anything, but just remembering the same type of
problem with the printer (and other) exntension in the past.
Previous Comments:
[2007-04-03 18:40:33] [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
[2007-04-03 15:00:21] daniel dot menard at bdsp dot tm dot fr
The same bug appear with the cgi version.
The only known workaround for now is to patch php_cgi.c in the same
way, removing any call to tsrm_shutdown()
[2007-04-03 14:00:47] charlie at lemurconsulting dot com
Description:
While trying to make the Xapian (www.xapian.org) PHP bindings work on
Windows using Visual C++, we found that the CLI version of PHP would
crash when unloading the bindings. The bindings are written using SWIG.
PHP appears to be trying to unload resources when the crash occurs. The
crash does not occur on earlier versions of PHP i.e. 4.4.6
Reproduce code:
---
The following patch fixes the problem and has been used as a
workaround:
Patch php_cli.c as follows by commenting out line 1283:
#ifdef ZTS
/*tsrm_shutdown(); */
#endif
Expected result:
No crash :)
Actual result:
--
n/a
--
Edit this bug report at http://bugs.php.net/?id=40985&edit=1
#40986 [Opn->Bgs]: mssql_field_name() retrieves only first 30 characters
ID: 40986 Updated by: [EMAIL PROTECTED] Reported By: Arne dot Heizmann at csr dot com -Status: Open +Status: Bogus Bug Type: MSSQL related Operating System: Windows 2000 PHP Version: 5.2.1 New Comment: This is a limit in the MSSQL library (ntwdblib.dll) used to build the extension. Use the php_dblib.dll version of the extension. This version is build with FreeTDS and does not have these limitations. This has been reported many times before. Please search the archives before posting the same bugs over and over. Previous Comments: [2007-04-03 17:43:05] Arne dot Heizmann at csr dot com Description: The function mssql_field_name() appears to return only the first 30 characters of the field name. Reproduce code: --- Expected result: 'This is a field name that is longer than 30 characters' Actual result: -- 'This is a field name that is l' -- Edit this bug report at http://bugs.php.net/?id=40986&edit=1
#40987 [NEW]: SVN PECL extension does not properly prototype all its functions
From: edwardzyang at thewritingpot dot com
Operating system:
PHP version: 6CVS-2007-04-03 (CVS)
PHP Bug Type: Unknown/Other Function
Bug description: SVN PECL extension does not properly prototype all its
functions
Description:
The svn extension does not properly prototype all of its PHP_FUNCTION
declarations. Thus, when xml_proto.php is run on it, it misses some of the
functions. Below is a patch that adds prototype declarations to:
svn_auth_get_parameter
svn_auth_set_parameter
svn_cat
svn_client_version
svn_import
svn_log
Index: svn.c
===
RCS file: /repository/pecl/svn/svn.c,v
retrieving revision 1.23
diff -u -r1.23 svn.c
--- svn.c 18 Apr 2006 03:11:52 - 1.23
+++ svn.c 3 Apr 2007 22:07:41 -
@@ -312,6 +312,8 @@
SVN_G(ctx)->auth_baton = ab;
}
+/* {{{ proto string svn_auth_get_parameter(string key)
+ Retrieves authentication parameter at key */
PHP_FUNCTION(svn_auth_get_parameter)
{
char *key;
@@ -329,7 +331,10 @@
RETURN_STRING((char*)value, 1);
}
}
+/* }}} */
+/* {{{ proto void svn_auth_set_parameter(string key, string value)
+ Sets authentication parameter at key to value */
PHP_FUNCTION(svn_auth_set_parameter)
{
char *key, *value;
@@ -342,7 +347,10 @@
svn_auth_set_parameter(SVN_G(ctx)->auth_baton, apr_pstrdup(SVN_G(pool),
key), apr_pstrdup(SVN_G(pool), value));
}
+/* }}} */
+/* {{{ proto bool svn_import(string path, string url, bool nonrecursive)
+ Imports unversioned path into repository at url */
PHP_FUNCTION(svn_import)
{
svn_client_commit_info_t *commit_info_p = NULL;
@@ -379,6 +387,7 @@
svn_pool_destroy(subpool);
}
+/* }}} */
/* {{{ PHP_MINIT_FUNCTION */
PHP_MINIT_FUNCTION(svn)
@@ -530,6 +539,8 @@
/* }}} */
+/* {{{ proto string svn_cat(string repos_url[, int revision_no])
+ Returns the contents of repos_url, optionally at revision_no */
PHP_FUNCTION(svn_cat)
{
char *repos_url = NULL;
@@ -597,8 +608,11 @@
svn_pool_destroy(subpool);
if (retdata) efree(retdata);
}
+/* }}} */
+/* {{{ proto array svn_ls(string repos_url[, int revision_no])
+ Returns list of directory contents in repos_url, optionally at
revision_no */
PHP_FUNCTION(svn_ls)
{
char *repos_url = NULL;
@@ -702,6 +716,7 @@
svn_pool_destroy(subpool);
}
+/* }}} */
static svn_error_t *
php_svn_log_message_receiver ( void *baton,
@@ -779,7 +794,9 @@
add_next_index_zval(return_value, row);
return SVN_NO_ERROR;
}
-
+
+/* {{{ proto array svn_log(string repos_url[, int revision_no])
+ Returns the commit log messages of repos_url, optionally at
revision_no */
PHP_FUNCTION(svn_log)
{
const char *repos_url = NULL, *utf8_repos_url = NULL;
@@ -844,6 +861,7 @@
svn_pool_destroy(subpool);
}
+/* }}} */
static size_t php_apr_file_write(php_stream *stream, const char *buf,
size_t count TSRMLS_DC)
{
@@ -1881,6 +1899,8 @@
snprintf(buf, buflen, "%d.%d.%d", vers->major, vers->minor,
vers->patch);
}
+/* {{{ proto string svn_client_version()
+ Returns the version of the SVN client libraries */
PHP_FUNCTION(svn_client_version)
{
char vers[128];
@@ -1892,6 +1912,7 @@
php_svn_get_version(vers, sizeof(vers));
RETURN_STRING(vers, 1);
}
+/* }}} */
/* {{{ proto resource svn_repos_fs_begin_txn_for_commit(resource repos,
long rev, string author, string log_msg)
create a new transaction */
--
Edit bug report at http://bugs.php.net/?id=40987&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=40987&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=40987&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=40987&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=40987&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=40987&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=40987&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=40987&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=40987&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=40987&r=support
Expected behavior:http://bugs.php.net/fix.php?id=40987&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=40987&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=40987&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=40987&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40987&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=40987&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=40987&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=40987&r=gnused
F
#40987 [Opn->Bgs]: SVN PECL extension does not properly prototype all its functions
ID: 40987
Updated by: [EMAIL PROTECTED]
Reported By: edwardzyang at thewritingpot dot com
-Status: Open
+Status: Bogus
Bug Type:Unknown/Other Function
PHP Version: 6CVS-2007-04-03 (CVS)
New Comment:
It would be better to upload this patch somewhere and put the link in
the report.
Also PECL bugs should be reported in PECL bug tracker:
http://pecl.php.net/bugs/search.php?cmd=display&status=Open&package_name[]=svn
Previous Comments:
[2007-04-03 22:14:59] edwardzyang at thewritingpot dot com
Description:
The svn extension does not properly prototype all of its PHP_FUNCTION
declarations. Thus, when xml_proto.php is run on it, it misses some of
the functions. Below is a patch that adds prototype declarations to:
svn_auth_get_parameter
svn_auth_set_parameter
svn_cat
svn_client_version
svn_import
svn_log
Index: svn.c
===
RCS file: /repository/pecl/svn/svn.c,v
retrieving revision 1.23
diff -u -r1.23 svn.c
--- svn.c 18 Apr 2006 03:11:52 - 1.23
+++ svn.c 3 Apr 2007 22:07:41 -
@@ -312,6 +312,8 @@
SVN_G(ctx)->auth_baton = ab;
}
+/* {{{ proto string svn_auth_get_parameter(string key)
+ Retrieves authentication parameter at key */
PHP_FUNCTION(svn_auth_get_parameter)
{
char *key;
@@ -329,7 +331,10 @@
RETURN_STRING((char*)value, 1);
}
}
+/* }}} */
+/* {{{ proto void svn_auth_set_parameter(string key, string value)
+ Sets authentication parameter at key to value */
PHP_FUNCTION(svn_auth_set_parameter)
{
char *key, *value;
@@ -342,7 +347,10 @@
svn_auth_set_parameter(SVN_G(ctx)->auth_baton,
apr_pstrdup(SVN_G(pool), key), apr_pstrdup(SVN_G(pool), value));
}
+/* }}} */
+/* {{{ proto bool svn_import(string path, string url, bool
nonrecursive)
+ Imports unversioned path into repository at url */
PHP_FUNCTION(svn_import)
{
svn_client_commit_info_t *commit_info_p = NULL;
@@ -379,6 +387,7 @@
svn_pool_destroy(subpool);
}
+/* }}} */
/* {{{ PHP_MINIT_FUNCTION */
PHP_MINIT_FUNCTION(svn)
@@ -530,6 +539,8 @@
/* }}} */
+/* {{{ proto string svn_cat(string repos_url[, int revision_no])
+ Returns the contents of repos_url, optionally at revision_no */
PHP_FUNCTION(svn_cat)
{
char *repos_url = NULL;
@@ -597,8 +608,11 @@
svn_pool_destroy(subpool);
if (retdata) efree(retdata);
}
+/* }}} */
+/* {{{ proto array svn_ls(string repos_url[, int revision_no])
+ Returns list of directory contents in repos_url, optionally at
revision_no */
PHP_FUNCTION(svn_ls)
{
char *repos_url = NULL;
@@ -702,6 +716,7 @@
svn_pool_destroy(subpool);
}
+/* }}} */
static svn_error_t *
php_svn_log_message_receiver ( void *baton,
@@ -779,7 +794,9 @@
add_next_index_zval(return_value, row);
return SVN_NO_ERROR;
}
-
+
+/* {{{ proto array svn_log(string repos_url[, int revision_no])
+ Returns the commit log messages of repos_url, optionally at
revision_no */
PHP_FUNCTION(svn_log)
{
const char *repos_url = NULL, *utf8_repos_url = NULL;
@@ -844,6 +861,7 @@
svn_pool_destroy(subpool);
}
+/* }}} */
static size_t php_apr_file_write(php_stream *stream, const char *buf,
size_t count TSRMLS_DC)
{
@@ -1881,6 +1899,8 @@
snprintf(buf, buflen, "%d.%d.%d", vers->major, vers->minor,
vers->patch);
}
+/* {{{ proto string svn_client_version()
+ Returns the version of the SVN client libraries */
PHP_FUNCTION(svn_client_version)
{
char vers[128];
@@ -1892,6 +1912,7 @@
php_svn_get_version(vers, sizeof(vers));
RETURN_STRING(vers, 1);
}
+/* }}} */
/* {{{ proto resource svn_repos_fs_begin_txn_for_commit(resource
repos, long rev, string author, string log_msg)
create a new transaction */
--
Edit this bug report at http://bugs.php.net/?id=40987&edit=1
#40987 [Bgs]: SVN PECL extension does not properly prototype all its functions
ID: 40987
User updated by: edwardzyang at thewritingpot dot com
Reported By: edwardzyang at thewritingpot dot com
Status: Bogus
Bug Type:Unknown/Other Function
PHP Version: 6CVS-2007-04-03 (CVS)
New Comment:
I was wondering why there was no PECL category in this bugtracker!
Thanks for the pointer.
Previous Comments:
[2007-04-03 22:18:19] [EMAIL PROTECTED]
It would be better to upload this patch somewhere and put the link in
the report.
Also PECL bugs should be reported in PECL bug tracker:
http://pecl.php.net/bugs/search.php?cmd=display&status=Open&package_name[]=svn
[2007-04-03 22:14:59] edwardzyang at thewritingpot dot com
Description:
The svn extension does not properly prototype all of its PHP_FUNCTION
declarations. Thus, when xml_proto.php is run on it, it misses some of
the functions. Below is a patch that adds prototype declarations to:
svn_auth_get_parameter
svn_auth_set_parameter
svn_cat
svn_client_version
svn_import
svn_log
Index: svn.c
===
RCS file: /repository/pecl/svn/svn.c,v
retrieving revision 1.23
diff -u -r1.23 svn.c
--- svn.c 18 Apr 2006 03:11:52 - 1.23
+++ svn.c 3 Apr 2007 22:07:41 -
@@ -312,6 +312,8 @@
SVN_G(ctx)->auth_baton = ab;
}
+/* {{{ proto string svn_auth_get_parameter(string key)
+ Retrieves authentication parameter at key */
PHP_FUNCTION(svn_auth_get_parameter)
{
char *key;
@@ -329,7 +331,10 @@
RETURN_STRING((char*)value, 1);
}
}
+/* }}} */
+/* {{{ proto void svn_auth_set_parameter(string key, string value)
+ Sets authentication parameter at key to value */
PHP_FUNCTION(svn_auth_set_parameter)
{
char *key, *value;
@@ -342,7 +347,10 @@
svn_auth_set_parameter(SVN_G(ctx)->auth_baton,
apr_pstrdup(SVN_G(pool), key), apr_pstrdup(SVN_G(pool), value));
}
+/* }}} */
+/* {{{ proto bool svn_import(string path, string url, bool
nonrecursive)
+ Imports unversioned path into repository at url */
PHP_FUNCTION(svn_import)
{
svn_client_commit_info_t *commit_info_p = NULL;
@@ -379,6 +387,7 @@
svn_pool_destroy(subpool);
}
+/* }}} */
/* {{{ PHP_MINIT_FUNCTION */
PHP_MINIT_FUNCTION(svn)
@@ -530,6 +539,8 @@
/* }}} */
+/* {{{ proto string svn_cat(string repos_url[, int revision_no])
+ Returns the contents of repos_url, optionally at revision_no */
PHP_FUNCTION(svn_cat)
{
char *repos_url = NULL;
@@ -597,8 +608,11 @@
svn_pool_destroy(subpool);
if (retdata) efree(retdata);
}
+/* }}} */
+/* {{{ proto array svn_ls(string repos_url[, int revision_no])
+ Returns list of directory contents in repos_url, optionally at
revision_no */
PHP_FUNCTION(svn_ls)
{
char *repos_url = NULL;
@@ -702,6 +716,7 @@
svn_pool_destroy(subpool);
}
+/* }}} */
static svn_error_t *
php_svn_log_message_receiver ( void *baton,
@@ -779,7 +794,9 @@
add_next_index_zval(return_value, row);
return SVN_NO_ERROR;
}
-
+
+/* {{{ proto array svn_log(string repos_url[, int revision_no])
+ Returns the commit log messages of repos_url, optionally at
revision_no */
PHP_FUNCTION(svn_log)
{
const char *repos_url = NULL, *utf8_repos_url = NULL;
@@ -844,6 +861,7 @@
svn_pool_destroy(subpool);
}
+/* }}} */
static size_t php_apr_file_write(php_stream *stream, const char *buf,
size_t count TSRMLS_DC)
{
@@ -1881,6 +1899,8 @@
snprintf(buf, buflen, "%d.%d.%d", vers->major, vers->minor,
vers->patch);
}
+/* {{{ proto string svn_client_version()
+ Returns the version of the SVN client libraries */
PHP_FUNCTION(svn_client_version)
{
char vers[128];
@@ -1892,6 +1912,7 @@
php_svn_get_version(vers, sizeof(vers));
RETURN_STRING(vers, 1);
}
+/* }}} */
/* {{{ proto resource svn_repos_fs_begin_txn_for_commit(resource
repos, long rev, string author, string log_msg)
create a new transaction */
--
Edit this bug report at http://bugs.php.net/?id=40987&edit=1
#40841 [Fbk->Opn]: #38770/#40543 Not fixed on Solaris 10
ID: 40841 User updated by: lovan at lifesci dot ucsb dot edu Reported By: lovan at lifesci dot ucsb dot edu -Status: Feedback +Status: Open Bug Type: Unknown/Other Function Operating System: Solaris 10 PHP Version: 5.2.1 Assigned To: iliaa New Comment: CVS snapshot 200704032230 is successful in unpacking the PEAR archive file. Previous Comments: [2007-04-03 22:00:03] [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 [2007-03-30 01:35:24] brian at eng dot wayne dot edu Sorry, I should have said - not exactly the same but similar: Warning: unpack(): Type V: not enough input, need 4, have 0 in /usr/people/brian /php5.2-200703280830/pear/install-pear-nozlib.phar on line 290 Warning: unpack(): Type V: not enough input, need 4, have 0 in /usr/people/brian /php5.2-200703280830/pear/install-pear-nozlib.phar on line 302 Warning: array_values(): The argument should be an array in /usr/people/brian/ph p5.2-200703280830/pear/install-pear-nozlib.phar on line 302 Notice: Undefined offset: 5 in /usr/people/brian/php5.2-200703280830/pear/insta ll-pear-nozlib.phar on line 304 Notice: Undefined offset: 2 in /usr/people/brian/php5.2-200703280830/pear/insta ll-pear-nozlib.phar on line 311 Notice: Undefined offset: 5 in /usr/people/brian/php5.2-200703280830/pear/insta ll-pear-nozlib.phar on line 312 Fatal error: Error: "index.php" is not a file in phar "install-pear-nozlib.phar" in /usr/people/brian/php5.2-200703280830/pear/install-pear-nozlib.phar on line 543 [2007-03-30 01:32:02] brian at eng dot wayne dot edu I'm seeing the same error message on SGI IRIX 6.5/64-bit using the commercial IRIX MIPSPro C compiler. [2007-03-20 16:41:24] lovan at lifesci dot ucsb dot edu I'm saying that the 5.2.0 unpack core dumped under GCC 4.1.2 on Solaris 10 but worked on Solaris 10 if compiled using the Sun C compiler. I'm also saying that the 5.2.1 unpack reports spurious errors instead of core dumping (regardless of compiler) on Solaris 10. [2007-03-20 14:57:41] [EMAIL PROTECTED] so you are saying that PHP 5.2.0 worked fine on Solaris 10, but PHP 5.2.1 doesn't? The phar did not change between PHP 5.2.0 and PHP 5.2.1. That sounds like a regression in unpack(), not a phar issue. Changing to feedback to confirm that I understand the user's last comment, and re-assigning to tony, with the assumption that it is an unpack() regression 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/40841 -- Edit this bug report at http://bugs.php.net/?id=40841&edit=1
#40841 [Opn->Csd]: #38770/#40543 Not fixed on Solaris 10
ID: 40841 Updated by: [EMAIL PROTECTED] Reported By: lovan at lifesci dot ucsb dot edu -Status: Open +Status: Closed Bug Type: Unknown/Other Function Operating System: Solaris 10 PHP Version: 5.2.1 Assigned To: iliaa 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: [2007-04-03 23:02:44] lovan at lifesci dot ucsb dot edu CVS snapshot 200704032230 is successful in unpacking the PEAR archive file. [2007-04-03 22:00:03] [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 [2007-03-30 01:35:24] brian at eng dot wayne dot edu Sorry, I should have said - not exactly the same but similar: Warning: unpack(): Type V: not enough input, need 4, have 0 in /usr/people/brian /php5.2-200703280830/pear/install-pear-nozlib.phar on line 290 Warning: unpack(): Type V: not enough input, need 4, have 0 in /usr/people/brian /php5.2-200703280830/pear/install-pear-nozlib.phar on line 302 Warning: array_values(): The argument should be an array in /usr/people/brian/ph p5.2-200703280830/pear/install-pear-nozlib.phar on line 302 Notice: Undefined offset: 5 in /usr/people/brian/php5.2-200703280830/pear/insta ll-pear-nozlib.phar on line 304 Notice: Undefined offset: 2 in /usr/people/brian/php5.2-200703280830/pear/insta ll-pear-nozlib.phar on line 311 Notice: Undefined offset: 5 in /usr/people/brian/php5.2-200703280830/pear/insta ll-pear-nozlib.phar on line 312 Fatal error: Error: "index.php" is not a file in phar "install-pear-nozlib.phar" in /usr/people/brian/php5.2-200703280830/pear/install-pear-nozlib.phar on line 543 [2007-03-30 01:32:02] brian at eng dot wayne dot edu I'm seeing the same error message on SGI IRIX 6.5/64-bit using the commercial IRIX MIPSPro C compiler. [2007-03-20 16:41:24] lovan at lifesci dot ucsb dot edu I'm saying that the 5.2.0 unpack core dumped under GCC 4.1.2 on Solaris 10 but worked on Solaris 10 if compiled using the Sun C compiler. I'm also saying that the 5.2.1 unpack reports spurious errors instead of core dumping (regardless of compiler) on Solaris 10. 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/40841 -- Edit this bug report at http://bugs.php.net/?id=40841&edit=1
#40988 [NEW]: Can't use a sendmail_path with whitespace
From: webmaster at wiedmann-online dot de
Operating system: Windows_NT
PHP version: 5.2.1
PHP Bug Type: *Mail Related
Bug description: Can't use a sendmail_path with whitespace
Description:
If I have the sendmail binary in a path with a whitespace, PHP can't
open/find this program, because the path is not quotet in the popen call
(mail.c).
On *nix this is not a problem, because on *nix you escape a space with a
backslash (Program\ Files) and don't quote the hole path ("Program Files")
like on Windows. And a backslash I can add myself in php.ini.
BTW:
A 8.3 name (PROGRA~1) will still work on Windows, if it's not disabled in
the NTFS settings.
Reproduce code:
---
[php.ini]
sendmail_path = "C:\Pogram Files\sendmail\sendmail.exe -t"
Expected result:
Mail is send without problems.
Actual result:
--
'C:\Program' is not recognized as an internal or external command,
operable program or batch file.
--
Edit bug report at http://bugs.php.net/?id=40988&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=40988&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=40988&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=40988&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=40988&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=40988&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=40988&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=40988&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=40988&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=40988&r=support
Expected behavior:http://bugs.php.net/fix.php?id=40988&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=40988&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=40988&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=40988&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40988&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=40988&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=40988&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=40988&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=40988&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=40988&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=40988&r=mysqlcfg
#40858 [Asn->Fbk]: Thread safety issue in GD
ID: 40858 Updated by: [EMAIL PROTECTED] Reported By: scottmacvicar at ntlworld dot com -Status: Assigned +Status: Feedback Bug Type: GD related Operating System: RHEL 4 PHP Version: 5.2.1 Assigned To: pajoye New Comment: 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 Previous Comments: [2007-03-23 12:39:34] scottmacvicar at ntlworld dot com I don't have access to a Windows machine at the moment but the following patch should fix the issues in libGD, I'll try and do a test when I have access to the machine. PHP 5.2 Patch: http://public.vbulletin.com/bugs/php/gd-mutex-patch.txt libGD Patch: http://public.vbulletin.com/bugs/php/libgd-mutex-patch.txt Explanation: * pthread now initialises the mutex only once * win32 can set the mutex within DLLMain * Race condition fix by locking prior to checking font cache Problems not fixed: * calling gdFontCacheSetup before obtaining a lock is going to cause the race condition still, I know the ruby wrappers do this. * Unusure about behaviour of using the non bundled GD library on windows with PHP since DLLMain and gdFontCacheMutexSetup may setup the critical section twice. Could make gdMutexSetup(x) a no-op for win32 too. [2007-03-23 01:21:26] [EMAIL PROTECTED] Hi Scott, Nuno, "Regarding the patch to the bundled GD library and the php wrapper, does it look reasonable? We've been running it for the past 2 days now without issue on a production server. I'd rather see something put into 5.2.2 " Yes, the patch for php (and unix) looks good. I will apply it during the weekend as well (or Nuno, you can do it if you have the time before). For the windows version, that's a good news, thanks to take the time to work on it. [2007-03-23 00:31:35] scottmacvicar at ntlworld dot com I have some time to spare over the weekend and a copy of VC6 installed now so I'll have a go at the win32 implementation. Regarding the patch to the bundled GD library and the php wrapper, does it look reasonable? We've been running it for the past 2 days now without issue on a production server. I'd rather see something put into 5.2.2 and then fix libGD. [2007-03-22 23:15:13] [EMAIL PROTECTED] yep, having a statically declared mutex would fix the problems we are having. I've a patch identical to yours (http://mega.ist.utl.pt/~ncpl/libgd_mutexes.txt) for a while, but we are still waiting for a win32 implementation to merge the patches (there is another open bug report in the gd bugs db about a similar issue) to definitely fix those nasty TS issues. [2007-03-21 01:37:18] scottmacvicar at ntlworld dot com Patch is available at http://public.vbulletin.com/bugs/php/gd-mutex-patch.txt Quick explanation: * The mutex is created at module startup and destroyed at module shutdown courtesy of two new helper functions within the libGD code base. * The mutex is no longer destroyed at request shutdown. * Locking is performed prior to checking fontCache to prevent the race condition we're seeing. This can't be merged back into libGD at the moment since it breaks backwards compatibility by assuming a mutex has been allocated, the way to fix this for pthread is fairly easy. #define gdMutexDeclare(x) pthread_mutex_t x #define gdMutexDeclare(x) pthread_mutex_t x becomes #define gdMutexDeclare(x) static pthread_mutex_t x = PTHREAD_MUTEX_INITIALIZER #define gdMutexSetup(x) That would just leave the win32 implementation to deal with via DLLMain, a quick patch to add that would only take a few minutes though I don't have VC6 installed yet. 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/40858 -- Edit this bug report at http://bugs.php.net/?id=40858&edit=1
#40989 [NEW]: PHPinfo output truncated
From: matt dot parrett at gmail dot com Operating system: RHEL-latest PHP version: 5.2.1 PHP Bug Type: Unknown/Other Function Bug description: PHPinfo output truncated Description: php 5.2.1 compiled with: './configure' '--prefix=/usr/local/php-5.2.1' '--with-apxs2=/usr/local/apache2.2/bin/apxs' '--with-mysql' '--with-mysqli' '--with-gd' '--with-pear' '--with-zlib-dir=/usr' '--with-mysql=/opt' '--with-jpeg-dir=/opt' '--with-png-dir=/opt' seems to give truncated output when viewed in a browser. Using wget to retrieve the page gives the expected result. php -i gives proper output. It seems like PHP or our configuration of PHP is doing something wacky with the headers. Not really sure what to look at though. I've configured everything by the book, and have used the same configuration on another server without trouble. Additionally, IE attempts to display the page, then has second thoughts and says 'page cannot be displayed'. We are having similar weird issues with some of our scripts, and found that the simple phpinfo page does the same thing. This is a brand new server with fresh compiles of Apache 2.2 and PHP 5.2.1 - I've tested with PHP 4.4.4 (similar compilation options) and get the same result. Reproduce code: --- Expected result: Full PHPinfo with PHP Variables section at the bottom. Actual result: -- Output ends prior to HTTP Headers Information. -- Edit bug report at http://bugs.php.net/?id=40989&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40989&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40989&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40989&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40989&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40989&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40989&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40989&r=needscript Try newer version:http://bugs.php.net/fix.php?id=40989&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40989&r=support Expected behavior:http://bugs.php.net/fix.php?id=40989&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40989&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40989&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40989&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40989&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40989&r=dst IIS Stability:http://bugs.php.net/fix.php?id=40989&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40989&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40989&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40989&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40989&r=mysqlcfg
