#40624 [Opn-Fbk]: pcrelib broken with php 4.4.5
ID: 40624 Updated by: [EMAIL PROTECTED] Reported By: test_junk at hotmail dot it -Status: Open +Status: Feedback Bug Type: PCRE related Operating System: linux 2.4 i386 PHP Version: 4.4.5 New Comment: Is this issue going to be fixed in the next release? We got a workaround for it in PHP5, but we're not going to add it to PHP4, so you have to upgrade your PHP first. This issue (if it's really what it seems to be) is actually not PHP problem, but a well-known PCRE issue. Though, I wouldn't be 100% sure without a test-case. Previous Comments: [2007-02-28 07:07:52] test_junk at hotmail dot it Is this issue going to be fixed in the next release? Unfortunately it breaks lots of things, including very popular apps. I will try to do my best in finding the responsible php code but I'm not sure it will be possibile. Thanks for your interest in this matter. [2007-02-28 00:13:38] [EMAIL PROTECTED] Yup, it does look like a stack overflow (which is a known issue in PCRE), though we would appreciate a test case anyway. [2007-02-27 23:39:19] test_junk at hotmail dot it I couldn't isolate the code yet. However the full backtrace is the following (I ran the same app twice): 1st time: #0 0x081851f2 in match (eptr=0x61737361 Address 0x61737361 out of bounds, ecode=0x2c69746c Address 0x2c69746c out of bounds, offset_top=1919250464, md=0x7474656d, ims=1868852837, eptrb=0x736f6320, flags=1629531331, rdepth=1702192160) at /sources/php/php-4.4.6/ext/pcre/pcrelib/pcre_exec.c:2209 #1 0x in ?? () 2nd time: #0 0x0818257f in match (eptr=0x61737361 Address 0x61737361 out of bounds, ecode=0x2c69746c Address 0x2c69746c out of bounds, offset_top=1919250464, md=0x7474656d, ims=1868852837, eptrb=0x736f6320, flags=1629531331, rdepth=1702192160) at /sources/php/php-4.4.6/ext/pcre/pcrelib/pcre_exec.c:1071 Cannot access memory at address 0xbf70 [2007-02-26 14:00:30] [EMAIL PROTECTED] also please post the whole backtrace, so that we can see what's happening (it may be just a stack overflow..) [2007-02-26 08:58:27] [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 ?php and ends with ?, is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. 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/40624 -- Edit this bug report at http://bugs.php.net/?id=40624edit=1
#38965 [Com]: mssql_connect doesn't use TCP 1433 for external SQL Server
ID: 38965 Comment by: mds135 at yahoo dot co dot uk Reported By: aren at cambre dot biz Status: Open Bug Type: MSSQL related Operating System: Windows 2003 (for both servers) PHP Version: 4.4.4 Assigned To: fmk New Comment: We have the same problem, where we get the message mssql_Connect() not a defined function. We are using version 4.4.5 of PHP on Windows Server 2003. We have found out from forums that we should use an older version of the ntwdblib.dll, but we are unable to find an older version. We use HTMLkit as an editor, and connection works fine when we display the page in the editor's preview. The problem occurs when we use the browser, MS Explorer 6 with SP1. This is extremly important to us. Previous Comments: [2006-09-28 03:18:55] aren at cambre dot biz There is a clear documentation error. From http://us3.php.net/manual/en/ref.mssql.php: The Client Tools can be installed ... by copying ntwdblib.dll from \winnt\system32 on the server to \winnt\system32 on the PHP box. Copying ntwdblib.dll will only provide access. Configuration of the client will require installation of all the tools. The method suggested by the manual, simply copying the ntwdblib.dll, will force PHP to use named pipes. This needs to be documented. Until then, you have a documentation bug because PHP will be unable to talk to SQL Server in its industry standard configuration (i.e., TCP 1433, not named pipes) if you simply copy the DLL on a machine that does not have the SQL Server Client Tools installed. [2006-09-27 21:23:56] [EMAIL PROTECTED] The MSSQL Extension for PHP uses ntwdblib as the library to connect to teh server. The configuration of this library is done with MS SQL Server Client Tools. These tools are installed from the CD and can be installed without the rest of the server to allow remote connections to the server. If ntwdblib.dll is copied to the server one way or the other, there is no way (except for registry hacks) to configure the library. PHP is not responsible for installation of a Microsoft tool or any other 3rd party libraries, but we expect them to be installed correct. There is no bugs in PHP here. [2006-09-26 19:15:13] aren at cambre dot biz Lemme add some more info: The IIS (web) server is a really vanilla Windows Server 2003 box. All that is installed, per Add or Remove Programs, is McAfee VirusScan Enterprise, Microsoft .NET Framework 2.0, PHP 4.4.4, and WMware Tools (it's virtual). I also installed Wireshark 0.99.3 and WinPcap 3.1, but they were installed afte the fact and did not affect the issue. If PHP's SQL Server connect script doesn't work right on a vanilla box, I can't believe this is bogus. SQL Server or SQL Server Client Tools has never been installed on this box. Programs should adhere to industry standard behaviors on vanilla Windows boxes, and industry standard for talking to SQL Server is TCP 1433. If PHP is not doing it, it needs to be fixed or properly documented. It may be as simply as classifying this as a documentation bug and adding documentation that addresses the issue, if that is the proper solution. [2006-09-26 18:23:45] aren at cambre dot biz This ntwdblib was on a default installation of Windows Server 2003. [2006-09-26 17:35:43] [EMAIL PROTECTED] No PHP uses ntwdblib and if you install the Client tools from MSSQL server you can define the default protocol. Older versions of ntwdblib (or combinations of other MS tools installed) uses named pipes as the default. The best way is to install the Client Tools and us the Clinet Network utility to set default protocol as well as create aliases for different servers. Each alias can be defined with the prefered protocol. 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/38965 -- Edit this bug report at http://bugs.php.net/?id=38965edit=1
#40664 [NEW]: String conversion functions wrong for multibyte chars
From: fjortiz at comunet dot es
Operating system: Win32
PHP version: 5.2.1
PHP Bug Type: COM related
Bug description: String conversion functions wrong for multibyte chars
Description:
when converting a UTF-8 encoded, multibyte string (Russian for example),
to a COM string, a wrong number of bytes are allocated, thus creating the
COM string with junk bytes at the end.
For example, when I pass my COM-based ADODB driver a 5-letter word in
Russian, I get at destination a 10 (5*2) characters string, the first 5
are the right Russian chars and the rest 5 are junk characters.
This was also explained for 4.4.2 in bug #37899
Actual result:
--
this is solved patching two files:
\ext\com_dotnet\com_variant.c, function php_com_variant_from_zval, line
156:
156,157c156
V_BSTR(v) = SysAllocString((char*)olestring);
---
V_BSTR(v) = SysAllocStringByteLen((char*)olestring,
Z_STRLEN_P(z) *
sizeof(OLECHAR));
\ext\com_dotnet\com_olechar.c, function php_com_string_to_olestring:
37d36
uint unicode_strlen;
39,40c38,44
unicode_strlen = MultiByteToWideChar(codepage, (codepage == CP_UTF8 ?
0 : MB_PRECOMPOSED | MB_ERR_INVALID_CHARS), string, -1, NULL,
0);
---
if (string_len == -1) {
/* determine required length for the buffer (includes NUL
terminator)
*/
string_len = MultiByteToWideChar(codepage, flags, string, -1,
NULL,
0);
} else {
/* allow room for NUL terminator */
string_len++;
}
42,44c46,48
if (unicode_strlen 0) {
olestring = (OLECHAR*)safe_emalloc(sizeof(OLECHAR),
unicode_strlen,
0);
ok = MultiByteToWideChar(codepage, flags, string, -1, olestring,
unicode_srlen);
---
if (strlen 0) {
olestring = (OLECHAR*)safe_emalloc(sizeof(OLECHAR), string_len,
0);
ok = MultiByteToWideChar(codepage, flags, string, string_len,
olestring, string_len);
--
Edit bug report at http://bugs.php.net/?id=40664edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=40664r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=40664r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=40664r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=40664r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=40664r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=40664r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=40664r=needscript
Try newer version:http://bugs.php.net/fix.php?id=40664r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=40664r=support
Expected behavior:http://bugs.php.net/fix.php?id=40664r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=40664r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=40664r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=40664r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40664r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=40664r=dst
IIS Stability:http://bugs.php.net/fix.php?id=40664r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=40664r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=40664r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=40664r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=40664r=mysqlcfg
#40624 [Fbk-Opn]: pcrelib broken with php 4.4.5
ID: 40624 User updated by: test_junk at hotmail dot it Reported By: test_junk at hotmail dot it -Status: Feedback +Status: Open Bug Type: PCRE related Operating System: linux 2.4 i386 PHP Version: 4.4.5 New Comment: I downgraded the PCRE lib to the 6.6 release, the one shipped with php 4.4.4 and the problem appears to be resolved. It's indeed a PCRE issue, I hope they will fix it in the future releases. Previous Comments: [2007-02-28 08:01:11] [EMAIL PROTECTED] Is this issue going to be fixed in the next release? We got a workaround for it in PHP5, but we're not going to add it to PHP4, so you have to upgrade your PHP first. This issue (if it's really what it seems to be) is actually not PHP problem, but a well-known PCRE issue. Though, I wouldn't be 100% sure without a test-case. [2007-02-28 07:07:52] test_junk at hotmail dot it Is this issue going to be fixed in the next release? Unfortunately it breaks lots of things, including very popular apps. I will try to do my best in finding the responsible php code but I'm not sure it will be possibile. Thanks for your interest in this matter. [2007-02-28 00:13:38] [EMAIL PROTECTED] Yup, it does look like a stack overflow (which is a known issue in PCRE), though we would appreciate a test case anyway. [2007-02-27 23:39:19] test_junk at hotmail dot it I couldn't isolate the code yet. However the full backtrace is the following (I ran the same app twice): 1st time: #0 0x081851f2 in match (eptr=0x61737361 Address 0x61737361 out of bounds, ecode=0x2c69746c Address 0x2c69746c out of bounds, offset_top=1919250464, md=0x7474656d, ims=1868852837, eptrb=0x736f6320, flags=1629531331, rdepth=1702192160) at /sources/php/php-4.4.6/ext/pcre/pcrelib/pcre_exec.c:2209 #1 0x in ?? () 2nd time: #0 0x0818257f in match (eptr=0x61737361 Address 0x61737361 out of bounds, ecode=0x2c69746c Address 0x2c69746c out of bounds, offset_top=1919250464, md=0x7474656d, ims=1868852837, eptrb=0x736f6320, flags=1629531331, rdepth=1702192160) at /sources/php/php-4.4.6/ext/pcre/pcrelib/pcre_exec.c:1071 Cannot access memory at address 0xbf70 [2007-02-26 14:00:30] [EMAIL PROTECTED] also please post the whole backtrace, so that we can see what's happening (it may be just a stack overflow..) 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/40624 -- Edit this bug report at http://bugs.php.net/?id=40624edit=1
#40658 [Fbk-Opn]: Segmentation fault
ID: 40658 User updated by: errol at issi dot co dot za Reported By: errol at issi dot co dot za -Status: Feedback +Status: Open Bug Type: CGI related Operating System: Linux 2.6.20 on ARM PHP Version: 5.2.1 New Comment: I have downloaded and built gcc 4.1.2 as a cross compiler for the ARM and php 5.2.1 now runs without a segmentation fault even when compiled with -g -O2. Thanks for the help. Previous Comments: [2007-02-27 20:01:28] [EMAIL PROTECTED] Could you please upgrade to GCC 4.1.2 ? Or (that would be perfect) downgrade to 3.4.x ? [2007-02-27 19:55:38] errol at issi dot co dot za I am using gcc 4.1.1 on linux 2.6.20 with eabi toolchain (arm-unknown-linux-gnueabi). [2007-02-27 19:44:04] [EMAIL PROTECTED] Heh. What version of GCC are you using? [2007-02-27 19:38:47] errol at issi dot co dot za Just logged in to work and did the compile with -O0 -g (it was using -O2 -g. Now the same php script runs without a seg fault!! I will give it a full test tomorrow when I can access via browser. [2007-02-27 19:12:08] errol at issi dot co dot za Will do. I am at home and the embedded setup is at work. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/40658 -- Edit this bug report at http://bugs.php.net/?id=40658edit=1
#40658 [Opn-Bgs]: Segmentation fault
ID: 40658 Updated by: [EMAIL PROTECTED] Reported By: errol at issi dot co dot za -Status: Open +Status: Bogus Bug Type: CGI related Operating System: Linux 2.6.20 on ARM PHP Version: 5.2.1 New Comment: Great news, thanks. Previous Comments: [2007-02-28 11:51:00] errol at issi dot co dot za I have downloaded and built gcc 4.1.2 as a cross compiler for the ARM and php 5.2.1 now runs without a segmentation fault even when compiled with -g -O2. Thanks for the help. [2007-02-27 20:01:28] [EMAIL PROTECTED] Could you please upgrade to GCC 4.1.2 ? Or (that would be perfect) downgrade to 3.4.x ? [2007-02-27 19:55:38] errol at issi dot co dot za I am using gcc 4.1.1 on linux 2.6.20 with eabi toolchain (arm-unknown-linux-gnueabi). [2007-02-27 19:44:04] [EMAIL PROTECTED] Heh. What version of GCC are you using? [2007-02-27 19:38:47] errol at issi dot co dot za Just logged in to work and did the compile with -O0 -g (it was using -O2 -g. Now the same php script runs without a seg fault!! I will give it a full test tomorrow when I can access via browser. 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/40658 -- Edit this bug report at http://bugs.php.net/?id=40658edit=1
#40624 [Opn-Fbk]: pcrelib broken with php 4.4.5
ID: 40624 Updated by: [EMAIL PROTECTED] Reported By: test_junk at hotmail dot it -Status: Open +Status: Feedback Bug Type: PCRE related Operating System: linux 2.4 i386 PHP Version: 4.4.5 Previous Comments: [2007-02-28 11:49:42] test_junk at hotmail dot it I downgraded the PCRE lib to the 6.6 release, the one shipped with php 4.4.4 and the problem appears to be resolved. It's indeed a PCRE issue, I hope they will fix it in the future releases. [2007-02-28 08:01:11] [EMAIL PROTECTED] Is this issue going to be fixed in the next release? We got a workaround for it in PHP5, but we're not going to add it to PHP4, so you have to upgrade your PHP first. This issue (if it's really what it seems to be) is actually not PHP problem, but a well-known PCRE issue. Though, I wouldn't be 100% sure without a test-case. [2007-02-28 07:07:52] test_junk at hotmail dot it Is this issue going to be fixed in the next release? Unfortunately it breaks lots of things, including very popular apps. I will try to do my best in finding the responsible php code but I'm not sure it will be possibile. Thanks for your interest in this matter. [2007-02-28 00:13:38] [EMAIL PROTECTED] Yup, it does look like a stack overflow (which is a known issue in PCRE), though we would appreciate a test case anyway. [2007-02-27 23:39:19] test_junk at hotmail dot it I couldn't isolate the code yet. However the full backtrace is the following (I ran the same app twice): 1st time: #0 0x081851f2 in match (eptr=0x61737361 Address 0x61737361 out of bounds, ecode=0x2c69746c Address 0x2c69746c out of bounds, offset_top=1919250464, md=0x7474656d, ims=1868852837, eptrb=0x736f6320, flags=1629531331, rdepth=1702192160) at /sources/php/php-4.4.6/ext/pcre/pcrelib/pcre_exec.c:2209 #1 0x in ?? () 2nd time: #0 0x0818257f in match (eptr=0x61737361 Address 0x61737361 out of bounds, ecode=0x2c69746c Address 0x2c69746c out of bounds, offset_top=1919250464, md=0x7474656d, ims=1868852837, eptrb=0x736f6320, flags=1629531331, rdepth=1702192160) at /sources/php/php-4.4.6/ext/pcre/pcrelib/pcre_exec.c:1071 Cannot access memory at address 0xbf70 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/40624 -- Edit this bug report at http://bugs.php.net/?id=40624edit=1
#40665 [NEW]: DOM/EXSLT not enabled in Windows binaries
From: bat at flurf dot net Operating system: Windows XP PHP version: 4CVS-2007-02-28 (snap) PHP Bug Type: XSLT related Bug description: DOM/EXSLT not enabled in Windows binaries Description: In a Windows binary of PHP4, enable DOMXML and look at a phpinfo() page. DOM/XSLT is listed as enabled, but DOM/EXSLT, a feature built in to libxslt, is not enabled. There appears to be no way to enable it, short of perhaps fixing the switch in the standard/snapshot Windows build scripts that are disabling the feature. Reproduce code: --- Ensure that your PHP.ini contains the line: extension=php_domxml.dll Look at a phpinfo() page, in the domxml section, typically about halfway down the page. Mine contains these settings only: DOM/XML enabled DOM/XML API Version 20020815 libxml Version 20626 HTML Supportenabled XPath Support enabled XPointer Supportenabled DOM/XSLTenabled libxslt Version 1.1.17 libxslt compiled against libxml Version 2.6.26 Expected result: Should also contain: DOM/EXSLT enabled libexslt Versionx.x.xx Actual result: -- Consequence: attempting to use the exslt:node-set() function to get past an egregious limitation in XSLT 1.0 gives the warning messages as follows on any Windows build of PHP4: Warning: process() [function.process]: xmlXPathCompOpEval: function node-set not found in ... Warning: process() [function.process]: Unregistered function in ... This indicates that libxslt is working, but access to its EXSLT features has been prevented. The phpinfo() result indicates that this prevention has occurred at build time, not as a consequence of any PHP script. On a standard Linux build, this function works perfectly well. It is therefore a bug in the way PHP is being built. Note: this is not a bug in libxslt! -- Edit bug report at http://bugs.php.net/?id=40665edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40665r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40665r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40665r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40665r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40665r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40665r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40665r=needscript Try newer version:http://bugs.php.net/fix.php?id=40665r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40665r=support Expected behavior:http://bugs.php.net/fix.php?id=40665r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40665r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40665r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40665r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40665r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40665r=dst IIS Stability:http://bugs.php.net/fix.php?id=40665r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40665r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40665r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40665r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40665r=mysqlcfg
#40666 [NEW]: handling of relative paths in include()
From: mfr at bmx-chemnitz dot de Operating system: all PHP version: 5.2.1 PHP Bug Type: Feature/Change Request Bug description: handling of relative paths in include() Description: To start with, PHP version is irrevelant for this request, regardless what your bug report form says. This is Change Request. Change the way relative includes are handled. The current way of NOT using the script directory but the current working directory, while documented, cannot be considered a feature but is clearly a bug. A script should NOT have to worry about where it was included from when it needs to include other files, regardless of the way it includes them (relative, absolute, relative with ./ / ../). The way this is implemented generates confusion and, quite frankly, breaks stuff. Pushing responsibility to properly deal with basic functionality like this to the user is just wrong. Following this up with an intended reply to bug #22865: I am sorry, but how can this not be a bug? You say the documentation says that Relative paths in include/require are always relative to the initial script, *not* to the file doing the include-ing. Which, regarding the state of documention, is all fine and well, given that the documentation describes the wrongness of the behaviour correctly. HOWEVER, the behaviour itself is the bug. How can it be intended that, in any given file, any relative include has to know where the originally called file is located? Why should it care? How would it know? If I have a file x that just knows it needs file y in the parent directory, then this is all there should be to it. You claim that You will need to use some kind of tracking of the base path for the current invocation.. Pardon me, but this is exactly the kind of house-keeping that include() itself is supposed to do. Reproduce code: --- foo/bar.php: ?php echo foo/bar.php ; include(../baz.inc); ? baz.inc: ?php echo baz.inc ; ? index.php: ?php echo index.php ; include(foo/bar.php); ? Expected result: http://host/foo/bar.php foo/bar.php baz.inc http://host/index.php index.php foo/bar.php baz.inc Actual result: -- http://host/foo/bar.php foo/bar.php baz.inc http://host/index.php index.php foo/bar.php Warning: main(../test.inc) [missing file...] -- Edit bug report at http://bugs.php.net/?id=40666edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40666r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40666r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40666r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40666r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40666r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40666r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40666r=needscript Try newer version:http://bugs.php.net/fix.php?id=40666r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40666r=support Expected behavior:http://bugs.php.net/fix.php?id=40666r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40666r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40666r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40666r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40666r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40666r=dst IIS Stability:http://bugs.php.net/fix.php?id=40666r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40666r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40666r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40666r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40666r=mysqlcfg
#40665 [Opn-Asn]: DOM/EXSLT not enabled in Windows binaries
ID: 40665 Updated by: [EMAIL PROTECTED] Reported By: bat at flurf dot net -Status: Open +Status: Assigned Bug Type: XSLT related Operating System: Windows XP PHP Version: 4CVS-2007-02-28 (snap) -Assigned To: +Assigned To: edink Previous Comments: [2007-02-28 12:35:56] bat at flurf dot net Description: In a Windows binary of PHP4, enable DOMXML and look at a phpinfo() page. DOM/XSLT is listed as enabled, but DOM/EXSLT, a feature built in to libxslt, is not enabled. There appears to be no way to enable it, short of perhaps fixing the switch in the standard/snapshot Windows build scripts that are disabling the feature. Reproduce code: --- Ensure that your PHP.ini contains the line: extension=php_domxml.dll Look at a phpinfo() page, in the domxml section, typically about halfway down the page. Mine contains these settings only: DOM/XML enabled DOM/XML API Version 20020815 libxml Version 20626 HTML Supportenabled XPath Support enabled XPointer Supportenabled DOM/XSLTenabled libxslt Version 1.1.17 libxslt compiled against libxml Version 2.6.26 Expected result: Should also contain: DOM/EXSLT enabled libexslt Versionx.x.xx Actual result: -- Consequence: attempting to use the exslt:node-set() function to get past an egregious limitation in XSLT 1.0 gives the warning messages as follows on any Windows build of PHP4: Warning: process() [function.process]: xmlXPathCompOpEval: function node-set not found in ... Warning: process() [function.process]: Unregistered function in ... This indicates that libxslt is working, but access to its EXSLT features has been prevented. The phpinfo() result indicates that this prevention has occurred at build time, not as a consequence of any PHP script. On a standard Linux build, this function works perfectly well. It is therefore a bug in the way PHP is being built. Note: this is not a bug in libxslt! -- Edit this bug report at http://bugs.php.net/?id=40665edit=1
#40656 [Bgs-Opn]: DOMDocument::load() urlencodes parts of an URI
ID: 40656
User updated by: bugs at php dot frankkleine dot de
-Summary: DOMDocument::load() does not support stream wrappers
Reported By: bugs at php dot frankkleine dot de
-Status: Bogus
+Status: Open
-Bug Type: Feature/Change Request
+Bug Type: DOM XML related
Operating System: irrelevant
PHP Version: 5.2.1
New Comment:
Thanks to your reply I found out what the real problem is. The
DOMDocument::load() urlencodes parts of the URI used for the stream
wrapper:
myStream://C:\master\bla.php?foo.xml
becomes
myStream://C:%5Cmaster%5Cbla.php?foo.xml
To work properly, the stream wrapper class first has to look if the
$path argument of stream_open() does exist, if not it has to do an
urldecode() on the $path and then check if the urldecoded $path
exists. It is my expectation that the stream wrapper should get the
correct $path from DOMDocument::load(), not an urlencoded one.
Previous Comments:
[2007-02-27 11:22:35] [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
url_stat needs to return an array
[2007-02-27 10:05:52] bugs at php dot frankkleine dot de
Description:
The DOMDocument::load() method does not support working with stream
wrappers. It's an inconsistency within PHP, one would expect that this
method works with stream wrappers as well just as other methods and
functions do.
Reproduce code:
---
class MyStreamWrapper
{
protected $read = false;
protected $stream = '?xml version=1.0
encoding=iso-8859-1?foobar id=1hello world/bar/foo';
public function stream_open($path, $mode, $options, $opened_path)
{return true; }
public function stream_close() { }
public function stream_read($count)
{
if (true == $this-read) { return ''; }
$this-read = true;
return $this-stream;
}
public function stream_eof() { return $this-read; }
public function stream_stat() { return strlen($this-stream); }
public function url_stat($path) { return strlen($this-stream); }
}
stream_wrapper_register('myStream', 'MyStreamWrapper');
$doc = DOMDocument::load('myStream://foo.xml');
var_dump($doc);
Expected result:
object(DOMDocument)#1 (0) { }
Actual result:
--
Warning: DOMDocument::load() [function.DOMDocument-load]: I/O warning :
failed to load external entity myStream://foo in
DomDocument_load-StreamWrapper.php on line 43
--
Edit this bug report at http://bugs.php.net/?id=40656edit=1
#40641 [Fbk-Opn]: open_basedir crash httpd
ID: 40641 User updated by: jfgingras at cegep-ste-foy dot qc dot ca Reported By: jfgingras at cegep-ste-foy dot qc dot ca -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: FreeBSD 6.1-RELEASE PHP Version: 5.2.1 New Comment: Well, the portage of Valgrind under FreeBSD 6.1 is only for i386 and it complains because I'm on a amd64. So I can't get valgrind to compile. I'll try the source directly from http://valgrind.org/, they saids it support amd64. Stay tune! Previous Comments: [2007-02-26 20:25:26] [EMAIL PROTECTED] Please check if valgrind is able to find something there. [2007-02-26 20:14:31] jfgingras at cegep-ste-foy dot qc dot ca Ok, I wasn't able to generate a backtrace even if I rebuild Apache and PHP with debug option, I can't get a core file. Anyway, like I said earlier, PHP without extionsion doesn't crash if open_basedir is defined, but as soon as I build the following extentions, I receive a Bus error from httpd: php5-bcmath-5.2.1_2 The bcmath shared extension for php php5-bz2-5.2.1_2The bz2 shared extension for php php5-calendar-5.2.1_2 The calendar shared extension for php php5-ctype-5.2.1_2 The ctype shared extension for php php5-dom-5.2.1_2The dom shared extension for php php5-extensions-1.1 A meta-port to install PHP extensions php5-gd-5.2.1_2 The gd shared extension for php php5-gettext-5.2.1_2 The gettext shared extension for php php5-iconv-5.2.1_2 The iconv shared extension for php php5-imap-5.2.1_2 The imap shared extension for php php5-mbstring-5.2.1_2 The mbstring shared extension for php php5-mcrypt-5.2.1_2 The mcrypt shared extension for php php5-mhash-5.2.1_2 The mhash shared extension for php php5-mysql-5.2.1_2 The mysql shared extension for php php5-mysqli-5.2.1_2 The mysqli shared extension for php php5-odbc-5.2.1_2 The odbc shared extension for php php5-pcre-5.2.1_2 The pcre shared extension for php php5-pdo-5.2.1_2The pdo shared extension for php php5-pdo_sqlite-5.2.1_2 The pdo_sqlite shared extension for php php5-posix-5.2.1_3 The posix shared extension for php php5-session-5.2.1_2 The session shared extension for php php5-simplexml-5.2.1_2 The simplexml shared extension for php php5-spl-5.2.1_2The spl shared extension for php php5-sqlite-5.2.1_2 The sqlite shared extension for php php5-tidy-5.2.1_2 The tidy shared extension for php php5-tokenizer-5.2.1_2 The tokenizer shared extension for php php5-xml-5.2.1_2The xml shared extension for php php5-xmlreader-5.2.1_2 The xmlreader shared extension for php php5-xmlwriter-5.2.1_2 The xmlwriter shared extension for php php5-zlib-5.2.1_2 The zlib shared extension for php phpMyAdmin-2.9.0.1 A set of PHP-scripts to manage MySQL over the web pecl-filter-0.11.0 PHP extension for safely dealing with input parameters pecl-hash-1.3 HASH Message Digest Framework for PHP pecl-json-1.2.1 PHP extension for JSON (JavaScript Object Notation) seriali pecl-pdflib-2.1.2 A PECL extension to create PDF on the fly I did exactly what was written on this page, http://bugs.php.net/bugs-generating-backtrace.php, but no core file and gdb can't stand httpd so no backtrace. Any help will be most welcome. Thx [2007-02-26 19:12:42] jfgingras at cegep-ste-foy dot qc dot ca Well, if that can help.. PHP with --enable-debug and no extension doesn't crash if open_basedir is defined. I'll have to test this with --disable-debug. I'm buidling the extensions we use for the debug version and see if I can reproduce the crash. [2007-02-26 18:32:06] jfgingras at cegep-ste-foy dot qc dot ca I'll keep trying generate a backtrace for httpd, but gdb doesn't like that very much. Since I can't stop our production server, I have create an exact duplicate of httpd.conf and name it httpd-debug.conf and simply change the Listen directive and my VirtualHost. I launch httpd directly from command line like this: /usr/local/sbin/httpd -X -f /usr/local/etc/apache2/httpd-debug.conf And the server start ok, and crash as expected when I enter a directory with open_basedir defined. But I can't manage to start it via gdb, here's what happen: [EMAIL PROTECTED] apache2]# gdb /usr/local/sbin/httpd GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as amd64-marcel-freebsd...(no debugging symbols found)... (gdb) run -X -f
#40641 [Opn-Fbk]: open_basedir crash httpd
ID: 40641 Updated by: [EMAIL PROTECTED] Reported By: jfgingras at cegep-ste-foy dot qc dot ca -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: FreeBSD 6.1-RELEASE PHP Version: 5.2.1 Previous Comments: [2007-02-28 14:32:39] jfgingras at cegep-ste-foy dot qc dot ca Well, the portage of Valgrind under FreeBSD 6.1 is only for i386 and it complains because I'm on a amd64. So I can't get valgrind to compile. I'll try the source directly from http://valgrind.org/, they saids it support amd64. Stay tune! [2007-02-26 20:25:26] [EMAIL PROTECTED] Please check if valgrind is able to find something there. [2007-02-26 20:14:31] jfgingras at cegep-ste-foy dot qc dot ca Ok, I wasn't able to generate a backtrace even if I rebuild Apache and PHP with debug option, I can't get a core file. Anyway, like I said earlier, PHP without extionsion doesn't crash if open_basedir is defined, but as soon as I build the following extentions, I receive a Bus error from httpd: php5-bcmath-5.2.1_2 The bcmath shared extension for php php5-bz2-5.2.1_2The bz2 shared extension for php php5-calendar-5.2.1_2 The calendar shared extension for php php5-ctype-5.2.1_2 The ctype shared extension for php php5-dom-5.2.1_2The dom shared extension for php php5-extensions-1.1 A meta-port to install PHP extensions php5-gd-5.2.1_2 The gd shared extension for php php5-gettext-5.2.1_2 The gettext shared extension for php php5-iconv-5.2.1_2 The iconv shared extension for php php5-imap-5.2.1_2 The imap shared extension for php php5-mbstring-5.2.1_2 The mbstring shared extension for php php5-mcrypt-5.2.1_2 The mcrypt shared extension for php php5-mhash-5.2.1_2 The mhash shared extension for php php5-mysql-5.2.1_2 The mysql shared extension for php php5-mysqli-5.2.1_2 The mysqli shared extension for php php5-odbc-5.2.1_2 The odbc shared extension for php php5-pcre-5.2.1_2 The pcre shared extension for php php5-pdo-5.2.1_2The pdo shared extension for php php5-pdo_sqlite-5.2.1_2 The pdo_sqlite shared extension for php php5-posix-5.2.1_3 The posix shared extension for php php5-session-5.2.1_2 The session shared extension for php php5-simplexml-5.2.1_2 The simplexml shared extension for php php5-spl-5.2.1_2The spl shared extension for php php5-sqlite-5.2.1_2 The sqlite shared extension for php php5-tidy-5.2.1_2 The tidy shared extension for php php5-tokenizer-5.2.1_2 The tokenizer shared extension for php php5-xml-5.2.1_2The xml shared extension for php php5-xmlreader-5.2.1_2 The xmlreader shared extension for php php5-xmlwriter-5.2.1_2 The xmlwriter shared extension for php php5-zlib-5.2.1_2 The zlib shared extension for php phpMyAdmin-2.9.0.1 A set of PHP-scripts to manage MySQL over the web pecl-filter-0.11.0 PHP extension for safely dealing with input parameters pecl-hash-1.3 HASH Message Digest Framework for PHP pecl-json-1.2.1 PHP extension for JSON (JavaScript Object Notation) seriali pecl-pdflib-2.1.2 A PECL extension to create PDF on the fly I did exactly what was written on this page, http://bugs.php.net/bugs-generating-backtrace.php, but no core file and gdb can't stand httpd so no backtrace. Any help will be most welcome. Thx [2007-02-26 19:12:42] jfgingras at cegep-ste-foy dot qc dot ca Well, if that can help.. PHP with --enable-debug and no extension doesn't crash if open_basedir is defined. I'll have to test this with --disable-debug. I'm buidling the extensions we use for the debug version and see if I can reproduce the crash. [2007-02-26 18:32:06] jfgingras at cegep-ste-foy dot qc dot ca I'll keep trying generate a backtrace for httpd, but gdb doesn't like that very much. Since I can't stop our production server, I have create an exact duplicate of httpd.conf and name it httpd-debug.conf and simply change the Listen directive and my VirtualHost. I launch httpd directly from command line like this: /usr/local/sbin/httpd -X -f /usr/local/etc/apache2/httpd-debug.conf And the server start ok, and crash as expected when I enter a directory with open_basedir defined. But I can't manage to start it via gdb, here's what happen: [EMAIL PROTECTED] apache2]# gdb /usr/local/sbin/httpd GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was
#40656 [Opn-Bgs]: DOMDocument::load() urlencodes parts of an URI
ID: 40656
Updated by: [EMAIL PROTECTED]
Reported By: bugs at php dot frankkleine dot de
-Status: Open
+Status: Bogus
Bug Type: DOM XML related
Operating System: irrelevant
PHP Version: 5.2.1
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
You have to use valid URIs (hence the \ gets encoded).
Previous Comments:
[2007-02-28 14:23:58] bugs at php dot frankkleine dot de
Thanks to your reply I found out what the real problem is. The
DOMDocument::load() urlencodes parts of the URI used for the stream
wrapper:
myStream://C:\master\bla.php?foo.xml
becomes
myStream://C:%5Cmaster%5Cbla.php?foo.xml
To work properly, the stream wrapper class first has to look if the
$path argument of stream_open() does exist, if not it has to do an
urldecode() on the $path and then check if the urldecoded $path
exists. It is my expectation that the stream wrapper should get the
correct $path from DOMDocument::load(), not an urlencoded one.
[2007-02-27 11:22:35] [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
url_stat needs to return an array
[2007-02-27 10:05:52] bugs at php dot frankkleine dot de
Description:
The DOMDocument::load() method does not support working with stream
wrappers. It's an inconsistency within PHP, one would expect that this
method works with stream wrappers as well just as other methods and
functions do.
Reproduce code:
---
class MyStreamWrapper
{
protected $read = false;
protected $stream = '?xml version=1.0
encoding=iso-8859-1?foobar id=1hello world/bar/foo';
public function stream_open($path, $mode, $options, $opened_path)
{return true; }
public function stream_close() { }
public function stream_read($count)
{
if (true == $this-read) { return ''; }
$this-read = true;
return $this-stream;
}
public function stream_eof() { return $this-read; }
public function stream_stat() { return strlen($this-stream); }
public function url_stat($path) { return strlen($this-stream); }
}
stream_wrapper_register('myStream', 'MyStreamWrapper');
$doc = DOMDocument::load('myStream://foo.xml');
var_dump($doc);
Expected result:
object(DOMDocument)#1 (0) { }
Actual result:
--
Warning: DOMDocument::load() [function.DOMDocument-load]: I/O warning :
failed to load external entity myStream://foo in
DomDocument_load-StreamWrapper.php on line 43
--
Edit this bug report at http://bugs.php.net/?id=40656edit=1
#40641 [Fbk-Opn]: open_basedir crash httpd
ID: 40641 User updated by: jfgingras at cegep-ste-foy dot qc dot ca Reported By: jfgingras at cegep-ste-foy dot qc dot ca -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: FreeBSD 6.1-RELEASE PHP Version: 5.2.1 New Comment: I should I have read more before posting my last comment, seems like the FreeBSD port only support i386 and the amd64 support is only for Linux right now. Guess I'll have to forget about open_basedir for now :( Previous Comments: [2007-02-28 14:32:39] jfgingras at cegep-ste-foy dot qc dot ca Well, the portage of Valgrind under FreeBSD 6.1 is only for i386 and it complains because I'm on a amd64. So I can't get valgrind to compile. I'll try the source directly from http://valgrind.org/, they saids it support amd64. Stay tune! [2007-02-26 20:25:26] [EMAIL PROTECTED] Please check if valgrind is able to find something there. [2007-02-26 20:14:31] jfgingras at cegep-ste-foy dot qc dot ca Ok, I wasn't able to generate a backtrace even if I rebuild Apache and PHP with debug option, I can't get a core file. Anyway, like I said earlier, PHP without extionsion doesn't crash if open_basedir is defined, but as soon as I build the following extentions, I receive a Bus error from httpd: php5-bcmath-5.2.1_2 The bcmath shared extension for php php5-bz2-5.2.1_2The bz2 shared extension for php php5-calendar-5.2.1_2 The calendar shared extension for php php5-ctype-5.2.1_2 The ctype shared extension for php php5-dom-5.2.1_2The dom shared extension for php php5-extensions-1.1 A meta-port to install PHP extensions php5-gd-5.2.1_2 The gd shared extension for php php5-gettext-5.2.1_2 The gettext shared extension for php php5-iconv-5.2.1_2 The iconv shared extension for php php5-imap-5.2.1_2 The imap shared extension for php php5-mbstring-5.2.1_2 The mbstring shared extension for php php5-mcrypt-5.2.1_2 The mcrypt shared extension for php php5-mhash-5.2.1_2 The mhash shared extension for php php5-mysql-5.2.1_2 The mysql shared extension for php php5-mysqli-5.2.1_2 The mysqli shared extension for php php5-odbc-5.2.1_2 The odbc shared extension for php php5-pcre-5.2.1_2 The pcre shared extension for php php5-pdo-5.2.1_2The pdo shared extension for php php5-pdo_sqlite-5.2.1_2 The pdo_sqlite shared extension for php php5-posix-5.2.1_3 The posix shared extension for php php5-session-5.2.1_2 The session shared extension for php php5-simplexml-5.2.1_2 The simplexml shared extension for php php5-spl-5.2.1_2The spl shared extension for php php5-sqlite-5.2.1_2 The sqlite shared extension for php php5-tidy-5.2.1_2 The tidy shared extension for php php5-tokenizer-5.2.1_2 The tokenizer shared extension for php php5-xml-5.2.1_2The xml shared extension for php php5-xmlreader-5.2.1_2 The xmlreader shared extension for php php5-xmlwriter-5.2.1_2 The xmlwriter shared extension for php php5-zlib-5.2.1_2 The zlib shared extension for php phpMyAdmin-2.9.0.1 A set of PHP-scripts to manage MySQL over the web pecl-filter-0.11.0 PHP extension for safely dealing with input parameters pecl-hash-1.3 HASH Message Digest Framework for PHP pecl-json-1.2.1 PHP extension for JSON (JavaScript Object Notation) seriali pecl-pdflib-2.1.2 A PECL extension to create PDF on the fly I did exactly what was written on this page, http://bugs.php.net/bugs-generating-backtrace.php, but no core file and gdb can't stand httpd so no backtrace. Any help will be most welcome. Thx [2007-02-26 19:12:42] jfgingras at cegep-ste-foy dot qc dot ca Well, if that can help.. PHP with --enable-debug and no extension doesn't crash if open_basedir is defined. I'll have to test this with --disable-debug. I'm buidling the extensions we use for the debug version and see if I can reproduce the crash. [2007-02-26 18:32:06] jfgingras at cegep-ste-foy dot qc dot ca I'll keep trying generate a backtrace for httpd, but gdb doesn't like that very much. Since I can't stop our production server, I have create an exact duplicate of httpd.conf and name it httpd-debug.conf and simply change the Listen directive and my VirtualHost. I launch httpd directly from command line like this: /usr/local/sbin/httpd -X -f /usr/local/etc/apache2/httpd-debug.conf And the server start ok, and crash as expected when I enter a directory with open_basedir defined. But I can't manage to start it via gdb, here's what happen: [EMAIL PROTECTED] apache2]# gdb /usr/local/sbin/httpd GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the
#38819 [Com]: segfault in ldap_get_entries()
ID: 38819 Comment by: cardoe at gentoo dot org Reported By: madcoder at gmail dot com Status: No Feedback Bug Type: LDAP related Operating System: 2.6.17-gentoo linux amd64 PHP Version: 5.1.6 New Comment: Several other Gentoo users are experiencing this issue as well. The issue is still an opened one with no fixes having occurred in PHP. You can see the Gentoo bug @ http://bugs.gentoo.org/show_bug.cgi?id=133467 Previous Comments: [2006-10-10 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2006-10-02 11:42:02] [EMAIL PROTECTED] works *without* any segfaults. Ok, great. Please don't close the report until the issue is resolved in PHP. Could you please also ask OpenLDAP developers if this flag would affect anything else? I.e. if it didn't segfault before, could this flag add any problems? If no, I'll add it to the config.m4, so it'll be defined in all builds. But wouldn't it be beneficial to take the OpenLDAP developers' advice, and rewrite this so-called deprecated use of OpenLDAP? Sure it would be. And we would gladly accept their help. But the current situation is that ext/ldap maintainer is not active for a long time and nobody really interested in ldap. If you can help us with that - you're welcome. Also, it would be good if OpenLDAP developers keep the backward compatibility, since we cannot rely on users using the most latest-and-greatest OpenLDAP version and rewrite ext/ldap each time they change the API. [2006-10-02 11:32:34] madcoder at gmail dot com Sorry, it appears I added that in the wrong place. I added it to the Makefile for ext/ldap, and it compiled, and works *without* any segfaults. I don't want to sound rude, so please don't take this the wrong way, ... But wouldn't it be beneficial to take the OpenLDAP developers' advice, and rewrite this so-called deprecated use of OpenLDAP? It appears to only occur on certain machines, perhaps even only on certain amd64 machines, but it is still rather annoying if no one is sure what causes it, and it takes 2 weeks (or longer, in my case, since I've been having this problem long before I posted to any trackers) to get an answer from someone. Thanks again for your help, and patience while working through this problem. [2006-10-02 11:20:50] madcoder at gmail dot com In ext/ldap/config.m4, I changed the following to add the flag you mentioned: CPPFLAGS=$CPPFLAGS -I$LDAP_INCDIR -DLDAP_DEPRECATED=1 Then reconfigured and rebuilt php. I'm not sure if I did that properly, but from what information I found about the flag, that is appropriate. And I *do* still get the segfault. Should I try a distclean as well? Or should I recompile OpenLDAP first (with or without that flag)? [2006-10-02 09:20:13] [EMAIL PROTECTED] So does it work for you if you add that magical -DLDAP_DEPRECATED=1 ? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/38819 -- Edit this bug report at http://bugs.php.net/?id=38819edit=1
#40641 [Opn-Fbk]: open_basedir crash httpd
ID: 40641 Updated by: [EMAIL PROTECTED] Reported By: jfgingras at cegep-ste-foy dot qc dot ca -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: FreeBSD 6.1-RELEASE PHP Version: 5.2.1 New Comment: Try rebuilding PHP with --disable-debug and CFLAGS=-O0 -g. Btw, what GCC version do you use? Previous Comments: [2007-02-28 14:53:57] jfgingras at cegep-ste-foy dot qc dot ca I should I have read more before posting my last comment, seems like the FreeBSD port only support i386 and the amd64 support is only for Linux right now. Guess I'll have to forget about open_basedir for now :( [2007-02-28 14:32:39] jfgingras at cegep-ste-foy dot qc dot ca Well, the portage of Valgrind under FreeBSD 6.1 is only for i386 and it complains because I'm on a amd64. So I can't get valgrind to compile. I'll try the source directly from http://valgrind.org/, they saids it support amd64. Stay tune! [2007-02-26 20:25:26] [EMAIL PROTECTED] Please check if valgrind is able to find something there. [2007-02-26 20:14:31] jfgingras at cegep-ste-foy dot qc dot ca Ok, I wasn't able to generate a backtrace even if I rebuild Apache and PHP with debug option, I can't get a core file. Anyway, like I said earlier, PHP without extionsion doesn't crash if open_basedir is defined, but as soon as I build the following extentions, I receive a Bus error from httpd: php5-bcmath-5.2.1_2 The bcmath shared extension for php php5-bz2-5.2.1_2The bz2 shared extension for php php5-calendar-5.2.1_2 The calendar shared extension for php php5-ctype-5.2.1_2 The ctype shared extension for php php5-dom-5.2.1_2The dom shared extension for php php5-extensions-1.1 A meta-port to install PHP extensions php5-gd-5.2.1_2 The gd shared extension for php php5-gettext-5.2.1_2 The gettext shared extension for php php5-iconv-5.2.1_2 The iconv shared extension for php php5-imap-5.2.1_2 The imap shared extension for php php5-mbstring-5.2.1_2 The mbstring shared extension for php php5-mcrypt-5.2.1_2 The mcrypt shared extension for php php5-mhash-5.2.1_2 The mhash shared extension for php php5-mysql-5.2.1_2 The mysql shared extension for php php5-mysqli-5.2.1_2 The mysqli shared extension for php php5-odbc-5.2.1_2 The odbc shared extension for php php5-pcre-5.2.1_2 The pcre shared extension for php php5-pdo-5.2.1_2The pdo shared extension for php php5-pdo_sqlite-5.2.1_2 The pdo_sqlite shared extension for php php5-posix-5.2.1_3 The posix shared extension for php php5-session-5.2.1_2 The session shared extension for php php5-simplexml-5.2.1_2 The simplexml shared extension for php php5-spl-5.2.1_2The spl shared extension for php php5-sqlite-5.2.1_2 The sqlite shared extension for php php5-tidy-5.2.1_2 The tidy shared extension for php php5-tokenizer-5.2.1_2 The tokenizer shared extension for php php5-xml-5.2.1_2The xml shared extension for php php5-xmlreader-5.2.1_2 The xmlreader shared extension for php php5-xmlwriter-5.2.1_2 The xmlwriter shared extension for php php5-zlib-5.2.1_2 The zlib shared extension for php phpMyAdmin-2.9.0.1 A set of PHP-scripts to manage MySQL over the web pecl-filter-0.11.0 PHP extension for safely dealing with input parameters pecl-hash-1.3 HASH Message Digest Framework for PHP pecl-json-1.2.1 PHP extension for JSON (JavaScript Object Notation) seriali pecl-pdflib-2.1.2 A PECL extension to create PDF on the fly I did exactly what was written on this page, http://bugs.php.net/bugs-generating-backtrace.php, but no core file and gdb can't stand httpd so no backtrace. Any help will be most welcome. Thx [2007-02-26 19:12:42] jfgingras at cegep-ste-foy dot qc dot ca Well, if that can help.. PHP with --enable-debug and no extension doesn't crash if open_basedir is defined. I'll have to test this with --disable-debug. I'm buidling the extensions we use for the debug version and see if I can reproduce the crash. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/40641 -- Edit this bug report at http://bugs.php.net/?id=40641edit=1
#38819 [NoF-Csd]: segfault in ldap_get_entries()
ID: 38819 Updated by: [EMAIL PROTECTED] Reported By: madcoder at gmail dot com -Status: No Feedback +Status: Closed Bug Type: LDAP related Operating System: 2.6.17-gentoo linux amd64 PHP Version: 5.1.6 New Comment: The patch adding -DLDAP_DEPRECATED=1 has been committed 18 Oct 2006. Previous Comments: [2007-02-28 14:56:26] cardoe at gentoo dot org Several other Gentoo users are experiencing this issue as well. The issue is still an opened one with no fixes having occurred in PHP. You can see the Gentoo bug @ http://bugs.gentoo.org/show_bug.cgi?id=133467 [2006-10-10 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2006-10-02 11:42:02] [EMAIL PROTECTED] works *without* any segfaults. Ok, great. Please don't close the report until the issue is resolved in PHP. Could you please also ask OpenLDAP developers if this flag would affect anything else? I.e. if it didn't segfault before, could this flag add any problems? If no, I'll add it to the config.m4, so it'll be defined in all builds. But wouldn't it be beneficial to take the OpenLDAP developers' advice, and rewrite this so-called deprecated use of OpenLDAP? Sure it would be. And we would gladly accept their help. But the current situation is that ext/ldap maintainer is not active for a long time and nobody really interested in ldap. If you can help us with that - you're welcome. Also, it would be good if OpenLDAP developers keep the backward compatibility, since we cannot rely on users using the most latest-and-greatest OpenLDAP version and rewrite ext/ldap each time they change the API. [2006-10-02 11:32:34] madcoder at gmail dot com Sorry, it appears I added that in the wrong place. I added it to the Makefile for ext/ldap, and it compiled, and works *without* any segfaults. I don't want to sound rude, so please don't take this the wrong way, ... But wouldn't it be beneficial to take the OpenLDAP developers' advice, and rewrite this so-called deprecated use of OpenLDAP? It appears to only occur on certain machines, perhaps even only on certain amd64 machines, but it is still rather annoying if no one is sure what causes it, and it takes 2 weeks (or longer, in my case, since I've been having this problem long before I posted to any trackers) to get an answer from someone. Thanks again for your help, and patience while working through this problem. [2006-10-02 11:20:50] madcoder at gmail dot com In ext/ldap/config.m4, I changed the following to add the flag you mentioned: CPPFLAGS=$CPPFLAGS -I$LDAP_INCDIR -DLDAP_DEPRECATED=1 Then reconfigured and rebuilt php. I'm not sure if I did that properly, but from what information I found about the flag, that is appropriate. And I *do* still get the segfault. Should I try a distclean as well? Or should I recompile OpenLDAP first (with or without that flag)? 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/38819 -- Edit this bug report at http://bugs.php.net/?id=38819edit=1
#40668 [NEW]: Add of resource for module_registry (Zend API)
From: mv at binarysec dot com Operating system: All PHP version: 5CVS-2007-02-28 (CVS) PHP Bug Type: Feature/Change Request Bug description: Add of resource for module_registry (Zend API) Description: Is it possible to add a new TS resource for : - static int module_count=0 (Zend/zend_API.c) - ZEND_API HashTable module_registry (Zend/zend_API.c) I got some problems when i try to load a new module in a thread. Thanks Expected result: br / bWarning/b: Module 'X7V3' already loaded in bUnknown/b on line b0/bbr / br / bWarning/b: Function registration failed - duplicate name - XX in bUnknown/b on line b0/bbr / br / bWarning/b: X7V3: Unable to register functions, unable to load in bUnknown/b on line b0/bbr / -- Edit bug report at http://bugs.php.net/?id=40668edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40668r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40668r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40668r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40668r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40668r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40668r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40668r=needscript Try newer version:http://bugs.php.net/fix.php?id=40668r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40668r=support Expected behavior:http://bugs.php.net/fix.php?id=40668r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40668r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40668r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40668r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40668r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40668r=dst IIS Stability:http://bugs.php.net/fix.php?id=40668r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40668r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40668r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40668r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40668r=mysqlcfg
#40669 [NEW]: problem with ternary operateor
From: milman at gmx dot de Operating system: PHP version: 5.2.1 PHP Bug Type: Scripting Engine problem Bug description: problem with ternary operateor Description: $a = 1 + (1) ? 2 : 5 ; should be the same as $a = 1 + ((1) ? 2 : 5); as $a = 3 ; Reproduce code: --- ?php echo bodyxmp\n ; $a = 1 + (1) ? 2 : 5 ; echo wrong: $a\n ; $a = 1 + ((1) ? 2 : 5); echo right: $a\n ; echo /xmp/body\n ; ? Expected result: wrong: 3 right: 3 Actual result: -- wrong: 2 right: 3 -- Edit bug report at http://bugs.php.net/?id=40669edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40669r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40669r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40669r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40669r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40669r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40669r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40669r=needscript Try newer version:http://bugs.php.net/fix.php?id=40669r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40669r=support Expected behavior:http://bugs.php.net/fix.php?id=40669r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40669r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40669r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40669r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40669r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40669r=dst IIS Stability:http://bugs.php.net/fix.php?id=40669r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40669r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40669r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40669r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40669r=mysqlcfg
#40669 [Opn-Bgs]: problem with ternary operateor
ID: 40669 Updated by: [EMAIL PROTECTED] Reported By: milman at gmx dot de -Status: Open +Status: Bogus Bug Type:Scripting Engine problem PHP Version: 5.2.1 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php http://www.php.net/manual/en/language.operators.php Previous Comments: [2007-02-28 18:36:03] milman at gmx dot de Description: $a = 1 + (1) ? 2 : 5 ; should be the same as $a = 1 + ((1) ? 2 : 5); as $a = 3 ; Reproduce code: --- ?php echo bodyxmp\n ; $a = 1 + (1) ? 2 : 5 ; echo wrong: $a\n ; $a = 1 + ((1) ? 2 : 5); echo right: $a\n ; echo /xmp/body\n ; ? Expected result: wrong: 3 right: 3 Actual result: -- wrong: 2 right: 3 -- Edit this bug report at http://bugs.php.net/?id=40669edit=1
#40668 [Opn-Bgs]: Add of resource for module_registry (Zend API)
ID: 40668 Updated by: [EMAIL PROTECTED] Reported By: mv at binarysec dot com -Status: Open +Status: Bogus Bug Type: Feature/Change Request Operating System: All PHP Version: 5CVS-2007-02-28 (CVS) New Comment: Please use appropriate mailing list for questions and discussions. Everything is possible, but we need to understand what you're talking about first and bug tracking system is wrong place for that. Previous Comments: [2007-02-28 17:12:42] mv at binarysec dot com Description: Is it possible to add a new TS resource for : - static int module_count=0 (Zend/zend_API.c) - ZEND_API HashTable module_registry (Zend/zend_API.c) I got some problems when i try to load a new module in a thread. Thanks Expected result: br / bWarning/b: Module 'X7V3' already loaded in bUnknown/b on line b0/bbr / br / bWarning/b: Function registration failed - duplicate name - XX in bUnknown/b on line b0/bbr / br / bWarning/b: X7V3: Unable to register functions, unable to load in bUnknown/b on line b0/bbr / -- Edit this bug report at http://bugs.php.net/?id=40668edit=1
#40669 [Bgs]: problem with ternary operateor
ID: 40669 User updated by: milman at gmx dot de Reported By: milman at gmx dot de Status: Bogus Bug Type:Scripting Engine problem PHP Version: 5.2.1 New Comment: sorry, but i dosn't understand. why must i write $a = 1 + ((1) ? 2 : 5); and $a = 1 + (1) ? 2 : 5 ; get a wrong result. that is totaly unexpected. i think it is to easy to say in documentation you should use () with ternary operator. than it should get a syntax-error when using without in expressions. but not a wrong result. Previous Comments: [2007-02-28 18:49:56] [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 http://www.php.net/manual/en/language.operators.php [2007-02-28 18:36:03] milman at gmx dot de Description: $a = 1 + (1) ? 2 : 5 ; should be the same as $a = 1 + ((1) ? 2 : 5); as $a = 3 ; Reproduce code: --- ?php echo bodyxmp\n ; $a = 1 + (1) ? 2 : 5 ; echo wrong: $a\n ; $a = 1 + ((1) ? 2 : 5); echo right: $a\n ; echo /xmp/body\n ; ? Expected result: wrong: 3 right: 3 Actual result: -- wrong: 2 right: 3 -- Edit this bug report at http://bugs.php.net/?id=40669edit=1
#40671 [NEW]: segfault in ldap_get_entries() LDAP functions implemented poorly
From: cardoe at gentoo dot org Operating system: Linux PHP version: 5.2.1 PHP Bug Type: LDAP related Bug description: segfault in ldap_get_entries() LDAP functions implemented poorly Description: Referencing Bug #38819 Essentially I looked through the above mentioned bug, the bugs opened with OpenLDAP developers, and then reviewed ext/ldap/ldap.c and it appears the API calls made by PHP are not necessarily the safest ways to write the PHP wrapper functions. Based on [EMAIL PROTECTED]'s comment that the LDAP module is unmaintained I went ahead and made some changes. If you read OpenLDAP's API and comments by OpenLDAP Core Developers, available at: http://www.openldap.org/its/index.cgi/Build?id=4690;selectid=4690 http://www.openldap.org/software/man.cgi?query=ldap_get_valuessektion=3apropos=0manpath=OpenLDAP+2.1-Release (Notice I went with OpenLDAP 2.1 docs to quell PHP's urge for backwards compatibility) The functions char **ldap_get_values(ld, entry, attr) and struct berval **ldap_get_values_len(ld, entry, attr) are essentially inter-changeable. The big difference being that the berval struct provides you with a char * and the size_t of the data. Rather then just a char * that you then have to strlen() which will result in problems if the returned data is not NULL terminated data. PHP's internal functions make the mistake of assuming all data will be string data (NULL terminated char *) data, which is the cause of the crash in bug #38819. The patch attached removes all of those assumptions and uses ldap_get_values_len() and uses the length provided back by the structure to feed add_index_stringl() instead of using add_index_string() which will call it's own strlen() on the provided data. This patch also removes ldap_get_values() as a PHP function and makes it an alias of ldap_get_values_len() since there's no difference and the same data can be returned, it's just a safer version. The attached patch fixes the test case provided in bug #38819. Referencing for my own purposes: http://bugs.gentoo.org/show_bug.cgi?id=133467 Reproduce code: --- For reproducing code refer to bug #38819 Actual result: -- For a backtrace see bug #38819. -- Edit bug report at http://bugs.php.net/?id=40671edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40671r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40671r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40671r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40671r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40671r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40671r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40671r=needscript Try newer version:http://bugs.php.net/fix.php?id=40671r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40671r=support Expected behavior:http://bugs.php.net/fix.php?id=40671r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40671r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40671r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40671r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40671r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40671r=dst IIS Stability:http://bugs.php.net/fix.php?id=40671r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40671r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40671r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40671r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40671r=mysqlcfg
#40671 [Opn]: segfault in ldap_get_entries() LDAP functions implemented poorly
ID: 40671
User updated by: cardoe at gentoo dot org
Reported By: cardoe at gentoo dot org
Status: Open
Bug Type: LDAP related
Operating System: Linux
PHP Version: 5.2.1
New Comment:
diff -Nur php-5.1.6/ext/ldap/ldap.c php-5.1.6-ldap-api/ext/ldap/ldap.c
--- php-5.1.6/ext/ldap/ldap.c 2006-01-01 07:50:08.0 -0500
+++ php-5.1.6-ldap-api/ext/ldap/ldap.c 2007-02-28 11:04:05.0
-0500
@@ -116,7 +116,8 @@
PHP_FE(ldap_first_attribute,third_arg_force_ref)
PHP_FE(ldap_next_attribute, third_arg_force_ref)
PHP_FE(ldap_get_attributes,
NULL)
- PHP_FE(ldap_get_values,
NULL)
+ PHP_FALIAS(ldap_get_values, ldap_get_values_len,
NULL)
+/* PHP_FE(ldap_get_values,
NULL) */
PHP_FE(ldap_get_values_len,
NULL)
PHP_FE(ldap_get_dn,
NULL)
PHP_FE(ldap_explode_dn,
NULL)
@@ -1033,7 +1034,7 @@BerElement *ber;
char *attribute;
size_t attr_len;
- char **ldap_value;
+ struct berval **ldap_value;
char *dn;
if (ZEND_NUM_ARGS() != 2 || zend_get_parameters_ex(2, link,
result) == FAILURE) {
@@ -1064,16 +1065,16 @@
attribute = ldap_first_attribute(ldap,
ldap_result_entry, ber);
while (attribute != NULL) {
- ldap_value = ldap_get_values(ldap,
ldap_result_entry, attribute);
- num_values = ldap_count_values(ldap_value);
+ ldap_value = ldap_get_values_len(ldap,
ldap_result_entry, attribute);
+ num_values =
ldap_count_values_len(ldap_value);
MAKE_STD_ZVAL(tmp2);
array_init(tmp2);
add_assoc_long(tmp2, count, num_values);
for (i = 0; i num_values; i++) {
- add_index_string(tmp2, i,
ldap_value[i], 1);
+ add_index_stringl(tmp2, i,
ldap_value[i]-bv_val, ldap_value[i]-bv_len, 1);
}
- ldap_value_free(ldap_value);
+ ldap_value_free_len(ldap_value);
attr_len = strlen(attribute);
zend_hash_update(Z_ARRVAL_P(tmp1),
php_strtolower(attribute, attr_len), attr_len+1, (void *) tmp2,
sizeof(zval *), NULL);
@@ -1180,7 +1181,7 @@
ldap_linkdata *ld;
ldap_resultentry *resultentry;
char *attribute;
- char **ldap_value;
+ struct berval **ldap_value;
int i, num_values, num_attrib;
BerElement *ber;
@@ -1196,16 +1197,16 @@
attribute = ldap_first_attribute(ld-link, resultentry-data,
ber);
while (attribute != NULL) {
- ldap_value = ldap_get_values(ld-link,
resultentry-data, attribute);
- num_values = ldap_count_values(ldap_value);
+ ldap_value = ldap_get_values_len(ld-link,
resultentry-data, attribute);
+ num_values = ldap_count_values_len(ldap_value);
MAKE_STD_ZVAL(tmp);
array_init(tmp);
add_assoc_long(tmp, count, num_values);
for (i = 0; i num_values; i++) {
- add_index_string(tmp, i, ldap_value[i], 1);
+ add_index_stringl(tmp, i,
ldap_value[i]-bv_val, ldap_value[i]-bv_len, 1);
}
- ldap_value_free(ldap_value);
+ ldap_value_free_len(ldap_value);
zend_hash_update(Z_ARRVAL_P(return_value), attribute,
strlen(attribute)+1, (void *) tmp, sizeof(zval *), NULL);
add_index_string(return_value, num_attrib, attribute,
1);
@@ -1226,46 +1227,6 @@
}
/* }}} */
-/* {{{ proto array ldap_get_values(resource link, resource
result_entry, string attribute)
- Get all values from a result entry */
-PHP_FUNCTION(ldap_get_values)
-{
- zval **link, **result_entry, **attr;
- ldap_linkdata *ld;
- ldap_resultentry *resultentry;
- char *attribute;
- char **ldap_value;
- int i, num_values;
-
- if (ZEND_NUM_ARGS() != 3 || zend_get_parameters_ex(3, link,
result_entry, attr) == FAILURE) {
- WRONG_PARAM_COUNT;
- }
-
- ZEND_FETCH_RESOURCE(ld, ldap_linkdata *, link, -1, ldap link,
le_link);
- ZEND_FETCH_RESOURCE(resultentry, ldap_resultentry *,
result_entry, -1, ldap result entry, le_result_entry);
-
- convert_to_string_ex(attr);
- attribute = Z_STRVAL_PP(attr);
-
- if ((ldap_value = ldap_get_values(ld-link, resultentry-data,
attribute)) == NULL) {
-
#40671 [Opn-Fbk]: segfault in ldap_get_entries() LDAP functions implemented poorly
ID: 40671
Updated by: [EMAIL PROTECTED]
Reported By: cardoe at gentoo dot org
-Status: Open
+Status: Feedback
Bug Type: LDAP related
Operating System: Linux
PHP Version: 5.2.1
New Comment:
Could you please post the same patch in internals@lists.php.net, so we
can discuss it there, not in the bug tracking system?
Thanks.
Previous Comments:
[2007-02-28 19:49:22] cardoe at gentoo dot org
diff -Nur php-5.1.6/ext/ldap/ldap.c php-5.1.6-ldap-api/ext/ldap/ldap.c
--- php-5.1.6/ext/ldap/ldap.c 2006-01-01 07:50:08.0 -0500
+++ php-5.1.6-ldap-api/ext/ldap/ldap.c 2007-02-28 11:04:05.0
-0500
@@ -116,7 +116,8 @@
PHP_FE(ldap_first_attribute,third_arg_force_ref)
PHP_FE(ldap_next_attribute, third_arg_force_ref)
PHP_FE(ldap_get_attributes,
NULL)
- PHP_FE(ldap_get_values,
NULL)
+ PHP_FALIAS(ldap_get_values, ldap_get_values_len,
NULL)
+/* PHP_FE(ldap_get_values,
NULL) */
PHP_FE(ldap_get_values_len,
NULL)
PHP_FE(ldap_get_dn,
NULL)
PHP_FE(ldap_explode_dn,
NULL)
@@ -1033,7 +1034,7 @@BerElement *ber;
char *attribute;
size_t attr_len;
- char **ldap_value;
+ struct berval **ldap_value;
char *dn;
if (ZEND_NUM_ARGS() != 2 || zend_get_parameters_ex(2, link,
result) == FAILURE) {
@@ -1064,16 +1065,16 @@
attribute = ldap_first_attribute(ldap,
ldap_result_entry, ber);
while (attribute != NULL) {
- ldap_value = ldap_get_values(ldap,
ldap_result_entry, attribute);
- num_values = ldap_count_values(ldap_value);
+ ldap_value = ldap_get_values_len(ldap,
ldap_result_entry, attribute);
+ num_values =
ldap_count_values_len(ldap_value);
MAKE_STD_ZVAL(tmp2);
array_init(tmp2);
add_assoc_long(tmp2, count, num_values);
for (i = 0; i num_values; i++) {
- add_index_string(tmp2, i,
ldap_value[i], 1);
+ add_index_stringl(tmp2, i,
ldap_value[i]-bv_val, ldap_value[i]-bv_len, 1);
}
- ldap_value_free(ldap_value);
+ ldap_value_free_len(ldap_value);
attr_len = strlen(attribute);
zend_hash_update(Z_ARRVAL_P(tmp1),
php_strtolower(attribute, attr_len), attr_len+1, (void *) tmp2,
sizeof(zval *), NULL);
@@ -1180,7 +1181,7 @@
ldap_linkdata *ld;
ldap_resultentry *resultentry;
char *attribute;
- char **ldap_value;
+ struct berval **ldap_value;
int i, num_values, num_attrib;
BerElement *ber;
@@ -1196,16 +1197,16 @@
attribute = ldap_first_attribute(ld-link, resultentry-data,
ber);
while (attribute != NULL) {
- ldap_value = ldap_get_values(ld-link,
resultentry-data, attribute);
- num_values = ldap_count_values(ldap_value);
+ ldap_value = ldap_get_values_len(ld-link,
resultentry-data, attribute);
+ num_values = ldap_count_values_len(ldap_value);
MAKE_STD_ZVAL(tmp);
array_init(tmp);
add_assoc_long(tmp, count, num_values);
for (i = 0; i num_values; i++) {
- add_index_string(tmp, i, ldap_value[i], 1);
+ add_index_stringl(tmp, i,
ldap_value[i]-bv_val, ldap_value[i]-bv_len, 1);
}
- ldap_value_free(ldap_value);
+ ldap_value_free_len(ldap_value);
zend_hash_update(Z_ARRVAL_P(return_value), attribute,
strlen(attribute)+1, (void *) tmp, sizeof(zval *), NULL);
add_index_string(return_value, num_attrib, attribute,
1);
@@ -1226,46 +1227,6 @@
}
/* }}} */
-/* {{{ proto array ldap_get_values(resource link, resource
result_entry, string attribute)
- Get all values from a result entry */
-PHP_FUNCTION(ldap_get_values)
-{
- zval **link, **result_entry, **attr;
- ldap_linkdata *ld;
- ldap_resultentry *resultentry;
- char *attribute;
- char **ldap_value;
- int i, num_values;
-
- if (ZEND_NUM_ARGS() != 3 || zend_get_parameters_ex(3, link,
result_entry, attr) == FAILURE) {
- WRONG_PARAM_COUNT;
- }
-
- ZEND_FETCH_RESOURCE(ld, ldap_linkdata *, link, -1, ldap link,
#40647 [Bgs-Opn]: ldap_connect() fails when restarting Apache 2.0.55 via restart or graceful
ID: 40647 User updated by: csi92 at yahoo dot com Reported By: csi92 at yahoo dot com -Status: Bogus +Status: Open Bug Type: LDAP related Operating System: Red Hat Enterprise Linux AS rele PHP Version: 4.4.5 New Comment: Can you explain what exactly indicates to you that the Oracle instant client is the problem? Previous Comments: [2007-02-27 16:34:26] [EMAIL PROTECTED] Ok, feel free to reopen the report when/if you have any additional information. [2007-02-27 16:06:46] csi92 at yahoo dot com I've rebuilt php without the Oracle component and the problem indeed has gone away. I will follow up with Oracle. Thanks for the help. [2007-02-26 20:06:48] [EMAIL PROTECTED] A segfault somewhere deep inside the Oracle Instant Client doesn't seem PHP related to me. Did you try reporting this to Oracle developers? [2007-02-26 20:03:38] csi92 at yahoo dot com (gdb) frame 8 #8 0x0118a192 in execute (op_array=0xb73c283c) at /opt/12345/software/php-4.4.5/Zend/zend_execute.c:1681 1681 ((zend_internal_function *) EX(function_state).function)-handler(EX(opline)-extended_value, EX(Ts)[EX(opline)-result.u.var].var.ptr, EX(object).ptr, return_value_used TSRMLS_CC); (gdb) [2007-02-26 19:58:44] csi92 at yahoo dot com (gdb) bt #0 0x04bcf104 in ?? () #1 0x06046e48 in nzdst_terminate () from /usr/lib/oracle/10.2.0.3/client/lib/libnnz10.so #2 0x06046b48 in nzdsi_initialize () from /usr/lib/oracle/10.2.0.3/client/lib/libnnz10.so #3 0x03af45c1 in gsluinit () from /usr/lib/oracle/10.2.0.3/client/lib/libclntsh.so.10.1 #4 0x03af4920 in gsluizgcGetContext () from /usr/lib/oracle/10.2.0.3/client/lib/libclntsh.so.10.1 #5 0x03af84e3 in gslutcTraceWithCtx () from /usr/lib/oracle/10.2.0.3/client/lib/libclntsh.so.10.1 #6 0x03ac4520 in ldap_init () from /usr/lib/oracle/10.2.0.3/client/lib/libclntsh.so.10.1 #7 0x0108ac16 in zif_ldap_connect (ht=1, return_value=0xb73c752c, this_ptr=0x0, return_value_used=1) at /opt/12345/software/php-4.4.5/ext/ldap/ldap.c:389 #8 0x0118a192 in execute (op_array=0xb73c283c) at /opt/12345/software/php-4.4.5/Zend/zend_execute.c:1681 #9 0x0117803d in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /opt/12345/software/php-4.4.5/Zend/zend.c:935 #10 0x011464ed in php_execute_script (primary_file=0xbfffc570) at /opt/12345/software/php-4.4.5/main/main.c:1757 #11 0x0118ff99 in php_handler (r=0xb72f7c50) at /opt/12345/software/php-4.4.5/sapi/apache2handler/sapi_apache2.c:581 ---Type return to continue, or q return to quit--- #12 0x08088b7b in ap_run_handler () #13 0xb72f8ff8 in ?? () #14 0x in ?? () (gdb) 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/40647 -- Edit this bug report at http://bugs.php.net/?id=40647edit=1
#40647 [Opn-Bgs]: ldap_connect() fails when restarting Apache 2.0.55 via restart or graceful
ID: 40647 Updated by: [EMAIL PROTECTED] Reported By: csi92 at yahoo dot com -Status: Open +Status: Bogus Bug Type: LDAP related Operating System: Red Hat Enterprise Linux AS rele PHP Version: 4.4.5 New Comment: Sure. Just look at your backtrace, everything there points to the Oracle Instant Client. #0 0x04bcf104 in ?? () #1 0x06046e48 in nzdst_terminate () from /usr/lib/oracle/10.2.0.3/client/lib/libnnz10.so #2 0x06046b48 in nzdsi_initialize () from /usr/lib/oracle/10.2.0.3/client/lib/libnnz10.so #3 0x03af45c1 in gsluinit () from /usr/lib/oracle/10.2.0.3/client/lib/libclntsh.so.10.1 #4 0x03af4920 in gsluizgcGetContext () from /usr/lib/oracle/10.2.0.3/client/lib/libclntsh.so.10.1 #5 0x03af84e3 in gslutcTraceWithCtx () from /usr/lib/oracle/10.2.0.3/client/lib/libclntsh.so.10.1 #6 0x03ac4520 in ldap_init () from /usr/lib/oracle/10.2.0.3/client/lib/libclntsh.so.10.1 #7 0x0108ac16 in zif_ldap_connect (ht=1, return_value=0xb73c752c, this_ptr=0x0, return_value_used=1) Previous Comments: [2007-02-28 20:25:34] csi92 at yahoo dot com Can you explain what exactly indicates to you that the Oracle instant client is the problem? [2007-02-27 16:34:26] [EMAIL PROTECTED] Ok, feel free to reopen the report when/if you have any additional information. [2007-02-27 16:06:46] csi92 at yahoo dot com I've rebuilt php without the Oracle component and the problem indeed has gone away. I will follow up with Oracle. Thanks for the help. [2007-02-26 20:06:48] [EMAIL PROTECTED] A segfault somewhere deep inside the Oracle Instant Client doesn't seem PHP related to me. Did you try reporting this to Oracle developers? [2007-02-26 20:03:38] csi92 at yahoo dot com (gdb) frame 8 #8 0x0118a192 in execute (op_array=0xb73c283c) at /opt/12345/software/php-4.4.5/Zend/zend_execute.c:1681 1681 ((zend_internal_function *) EX(function_state).function)-handler(EX(opline)-extended_value, EX(Ts)[EX(opline)-result.u.var].var.ptr, EX(object).ptr, return_value_used TSRMLS_CC); (gdb) 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/40647 -- Edit this bug report at http://bugs.php.net/?id=40647edit=1
#40641 [Fbk-Opn]: open_basedir crash httpd
ID: 40641 User updated by: jfgingras at cegep-ste-foy dot qc dot ca Reported By: jfgingras at cegep-ste-foy dot qc dot ca -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: FreeBSD 6.1-RELEASE PHP Version: 5.2.1 New Comment: We finaly found a machine on which we can reproduce the error. I'll compile PHP as you recommened. Three servers running FreeBSD 6.1, with the lastest patchs an all, all running on 64bits CPU. Two servers are running with 2x AMD64 Opteron Processor 248 (both crash with open_basedir) and one running with AMD64 Athlon Dual Core (doesn't crash with open_basedir). I'll try to run httpd under gdb again, I want that backtrace ;) Previous Comments: [2007-02-28 15:00:00] [EMAIL PROTECTED] Try rebuilding PHP with --disable-debug and CFLAGS=-O0 -g. Btw, what GCC version do you use? [2007-02-28 14:53:57] jfgingras at cegep-ste-foy dot qc dot ca I should I have read more before posting my last comment, seems like the FreeBSD port only support i386 and the amd64 support is only for Linux right now. Guess I'll have to forget about open_basedir for now :( [2007-02-28 14:32:39] jfgingras at cegep-ste-foy dot qc dot ca Well, the portage of Valgrind under FreeBSD 6.1 is only for i386 and it complains because I'm on a amd64. So I can't get valgrind to compile. I'll try the source directly from http://valgrind.org/, they saids it support amd64. Stay tune! [2007-02-26 20:25:26] [EMAIL PROTECTED] Please check if valgrind is able to find something there. [2007-02-26 20:14:31] jfgingras at cegep-ste-foy dot qc dot ca Ok, I wasn't able to generate a backtrace even if I rebuild Apache and PHP with debug option, I can't get a core file. Anyway, like I said earlier, PHP without extionsion doesn't crash if open_basedir is defined, but as soon as I build the following extentions, I receive a Bus error from httpd: php5-bcmath-5.2.1_2 The bcmath shared extension for php php5-bz2-5.2.1_2The bz2 shared extension for php php5-calendar-5.2.1_2 The calendar shared extension for php php5-ctype-5.2.1_2 The ctype shared extension for php php5-dom-5.2.1_2The dom shared extension for php php5-extensions-1.1 A meta-port to install PHP extensions php5-gd-5.2.1_2 The gd shared extension for php php5-gettext-5.2.1_2 The gettext shared extension for php php5-iconv-5.2.1_2 The iconv shared extension for php php5-imap-5.2.1_2 The imap shared extension for php php5-mbstring-5.2.1_2 The mbstring shared extension for php php5-mcrypt-5.2.1_2 The mcrypt shared extension for php php5-mhash-5.2.1_2 The mhash shared extension for php php5-mysql-5.2.1_2 The mysql shared extension for php php5-mysqli-5.2.1_2 The mysqli shared extension for php php5-odbc-5.2.1_2 The odbc shared extension for php php5-pcre-5.2.1_2 The pcre shared extension for php php5-pdo-5.2.1_2The pdo shared extension for php php5-pdo_sqlite-5.2.1_2 The pdo_sqlite shared extension for php php5-posix-5.2.1_3 The posix shared extension for php php5-session-5.2.1_2 The session shared extension for php php5-simplexml-5.2.1_2 The simplexml shared extension for php php5-spl-5.2.1_2The spl shared extension for php php5-sqlite-5.2.1_2 The sqlite shared extension for php php5-tidy-5.2.1_2 The tidy shared extension for php php5-tokenizer-5.2.1_2 The tokenizer shared extension for php php5-xml-5.2.1_2The xml shared extension for php php5-xmlreader-5.2.1_2 The xmlreader shared extension for php php5-xmlwriter-5.2.1_2 The xmlwriter shared extension for php php5-zlib-5.2.1_2 The zlib shared extension for php phpMyAdmin-2.9.0.1 A set of PHP-scripts to manage MySQL over the web pecl-filter-0.11.0 PHP extension for safely dealing with input parameters pecl-hash-1.3 HASH Message Digest Framework for PHP pecl-json-1.2.1 PHP extension for JSON (JavaScript Object Notation) seriali pecl-pdflib-2.1.2 A PECL extension to create PDF on the fly I did exactly what was written on this page, http://bugs.php.net/bugs-generating-backtrace.php, but no core file and gdb can't stand httpd so no backtrace. Any help will be most welcome. Thx 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/40641 -- Edit this bug report at http://bugs.php.net/?id=40641edit=1
#39199 [Com]: Cannot load Lob data with more than 4000 bytes on ORACLE 10
ID: 39199
Comment by: spatar at mail dot nnov dot ru
Reported By: jarismar_silva at adplabs dot com dot br
Status: Assigned
Bug Type: PDO related
Operating System: SuSE, WinXP
PHP Version: 5.2.0
Assigned To: wez
New Comment:
A quote from OCILobRead() documentation:
If the callback function is not defined, then the OCI_NEED_DATA error
code will be returned. The application must call OCILobRead() over and
over again to read more pieces of the LOB until the OCI_NEED_DATA error
code is not returned.
A quote from OCILobWrite() documentation:
If no callback function is defined, then OCILobWrite() returns the
OCI_NEED_DATA error code. The application must call OCILobWrite() again
to write more pieces of the LOB.
I propose the patch for php-5.2.1/ext/pdo_oci/oci_statement.c:
614c614
if (r != OCI_SUCCESS) {
---
if ((r != OCI_SUCCESS) (r != OCI_NEED_DATA)) {
633c633
if (r != OCI_SUCCESS) {
---
if ((r != OCI_SUCCESS) (r != OCI_NEED_DATA)) {
Previous Comments:
[2007-02-27 13:09:31] spatar at mail dot nnov dot ru
Forgot to paste table creation in my previous post:
create table TEST_LOB
(
COL_LOB CLOB
);
insert into TEST_LOB values (NULL);
commit;
Also I've tested with PHP 5.2.1 and result is the same.
[2007-02-27 12:42:22] spatar at mail dot nnov dot ru
I have the similar problem.
My database has charset AL32UTF8. If a CLOB column's length is 2730
characters, then PDO returns empty stream for such CLOB.
With single-byte charset US7ASCII I can easily get CLOB of length
100 characters.
PHP: PHP 5.2.1RC3-dev (cli) (built: Feb 7 2007 16:57:25)
Oracle: 10.2.0.1.0
OS: SuSE Linux 9.2 (i586)
Reproduce code:
---
?php
mb_internal_encoding(utf-8);
mb_http_output(utf-8);
ob_start(mb_output_handler);
try
{
$dbh = new PDO(oci:dbname=ORCL;charset=UTF8, scott, tiger);
// It seems that UTF8 is only correct value for charset in PDO
constructor
// because with UTF8 it can read CLOB up to 2730 characters,
// and with UTF-8 or AL32UTF8 it can read CLOB only up to 2048
characters.
// Am I wrong?
$dbh-setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$test_lengths = array(2000, 2730, 2731, 4000);
foreach ($test_lengths as $test_length)
{
$dbh-beginTransaction();
$stmt = $dbh-prepare(update test_lob set col_lob = ?);
$stmt-bindValue(1, str_repeat(X, $test_length));
$stmt-execute();
$dbh-commit();
echo Column updated to $test_length characters\n;
$stmt = $dbh-prepare(select * from test_lob);
$stmt-execute();
$stmt-setFetchMode(PDO::FETCH_NUM);
$result = $stmt-fetchAll();
echo Read .strlen(stream_get_contents($result[0][0])).
characters\n\n;
}
}
catch (PDOException $e)
{
echo $e-getMessage().\n;
print_r($e-errorInfo);
}
?
Expected result:
Column updated to 2000 characters
Read 2000 characters
Column updated to 2730 characters
Read 2730 characters
Column updated to 2731 characters
Read 2731 characters
Column updated to 4000 characters
Read 4000 characters
Actual result:
--
Column updated to 2000 characters
Read 2000 characters
Column updated to 2730 characters
Read 2730 characters
Column updated to 2731 characters
Read 0 characters
SQLSTATE[HY000]: General error: 3127 OCIStmtExecute: ORA-03127: no new
operations allowed until the active operation ends
(/home/spatar/mvtm/www/php5.2-200701101130/ext/pdo_oci/oci_statement.c:142)
Array
(
[0] = HY000
[1] = 3127
[2] = OCIStmtExecute: ORA-03127: no new operations allowed until
the active operation ends
(/home/spatar/mvtm/www/php5.2-200701101130/ext/pdo_oci/oci_statement.c:142)
)
Segmentation fault
GDB backtrace:
--
#0 0x086ac65a in ?? ()
#1 0x0008 in ?? ()
#2 0xb728a73e in kpulbcr () from
/u01/app/oracle/OraHome1/lib/libclntsh.so.10.1
#3 0xb75bec0c in ttcdrv () from
/u01/app/oracle/OraHome1/lib/libclntsh.so.10.1
#4 0xb74b3f11 in nioqwa () from
/u01/app/oracle/OraHome1/lib/libclntsh.so.10.1
#5 0xb7318327 in upirtrc () from
/u01/app/oracle/OraHome1/lib/libclntsh.so.10.1
#6 0xb728dfc6 in kpurcsc () from
/u01/app/oracle/OraHome1/lib/libclntsh.so.10.1
#7 0xb727c634 in kpulcls () from
/u01/app/oracle/OraHome1/lib/libclntsh.so.10.1
#8 0xb731dac2 in OCILobClose () from
/u01/app/oracle/OraHome1/lib/libclntsh.so.10.1
#9 0x08166de0 in oci_blob_close ()
#10 0x0828c66c in _php_stream_free ()
#11 0x0828c8c3 in stream_resource_regular_dtor ()
#12 0x082bf15e in list_entry_destructor ()
#13 0x082bd65b in zend_hash_del_key_or_index ()
#14 0x082bf31d in _zend_list_delete ()
#15 0x082aa669 in _zval_ptr_dtor ()
#16 0x082bd3e9 in zend_hash_destroy ()
#17 0x082b41c3 in _zval_dtor_func ()
#18 0x082aa669 in _zval_ptr_dtor ()
#19
#40673 [NEW]: Downloads
From: peter at advancedwebdb dot com Operating system: Server 2003 PHP version: 5.2.1 PHP Bug Type: Unknown/Other Function Bug description: Downloads Description: The download speed from the slected site is terrible . it is 3.33 kbs/sec I have an OS4 connection ... Is this speed normal -- Edit bug report at http://bugs.php.net/?id=40673edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40673r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40673r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40673r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40673r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40673r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40673r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40673r=needscript Try newer version:http://bugs.php.net/fix.php?id=40673r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40673r=support Expected behavior:http://bugs.php.net/fix.php?id=40673r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40673r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40673r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40673r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40673r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40673r=dst IIS Stability:http://bugs.php.net/fix.php?id=40673r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40673r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40673r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40673r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40673r=mysqlcfg
#40673 [Opn-Bgs]: Downloads
ID: 40673 Updated by: [EMAIL PROTECTED] Reported By: peter at advancedwebdb dot com -Status: Open +Status: Bogus Bug Type: Unknown/Other Function Operating System: Server 2003 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. That mirror maybe slow, just use another mirror. Previous Comments: [2007-02-28 23:34:51] peter at advancedwebdb dot com Description: The download speed from the slected site is terrible . it is 3.33 kbs/sec I have an OS4 connection ... Is this speed normal -- Edit this bug report at http://bugs.php.net/?id=40673edit=1
#40464 [Asn-Csd]: Session.save_path wont use default-value
ID: 40464 Updated by: [EMAIL PROTECTED] Reported By: benni at gniza dot org -Status: Assigned +Status: Closed Bug Type: *Configuration Issues Operating System: SuSE 9.3 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-02-13 15:39:01] benni at gniza dot org Description: I can approve the behavior of BUG-ID 40434 Sessions won't work without setting a session.save_path explicitly! If you just comment the session.save_path-line you get the error: SAFE MODE Restriction in effect. The script whose uid is XZY is not allowed to access owned by uid 0 in [Scriptname:Line of session_start()] This behavior is either a bug or the manual is wrong. Quote from the manual: == session.save_path defines [...]. Defaults to /tmp. == If I explicitly set the save_path (to /tmp or somewhere else) all is okay! Greetings Benjamin -- Edit this bug report at http://bugs.php.net/?id=40464edit=1
#37730 [NoF]: ImageTTFText ImageTTFBBox don't give accurate rectangle with angle
ID: 37730 Updated by: [EMAIL PROTECTED] Reported By: marc dot lazzaro at st dot com Status: No Feedback Bug Type: GD related Operating System: Win XP PHP Version: 5.1.4 Assigned To: pajoye New Comment: I made a little demonstration script (includes source + phpinfo): http://hopka.net/imagettfbbox.php5; Your script is wrong, you forgot that each position is relative to the origin of the text. Adding 100 to each of them is not correct. You have to rotate the offset. Previous Comments: [2007-02-27 15:10:59] hopka at hopka dot net I have the same problem with PHP 5.1.2 on Linux and 5.2.0 on Windows XP. I use imagepolygon to render the bounding box and with a rotation of 0 degrees (or 360, 720, etc) it fits around the text perfectly. As soon as I set a different angle, the bounding box is too large and at the wrong position. I made a little demonstration script (includes source + phpinfo): http://hopka.net/imagettfbbox.php5 [2007-01-23 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2007-01-15 12:45:28] [EMAIL PROTECTED] mail to pierre[at]libgd.org. [2006-06-08 06:57:29] marc dot lazzaro at st dot com My company policy forbides external access. If you could provide an email address I will send you the font file. But I have to say that the behavior remains the same whatever the font is. Also pls note that I got no errors when the @ is removed. [2006-06-07 16:44:58] [EMAIL PROTECTED] Please provide a link to the font you use. Don't use '@' to hide possible errors or notices. 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/37730 -- Edit this bug report at http://bugs.php.net/?id=37730edit=1
#40676 [NEW]: Add FILTER_VALIDATE_URI (replacing FILTER_VALIDATE_URL)?
From: walter dot tom+php at gmail dot com Operating system: PHP version: 5.2.1 PHP Bug Type: Feature/Change Request Bug description: Add FILTER_VALIDATE_URI (replacing FILTER_VALIDATE_URL)? Description: It appears as of the fix for #39898 that support for validating relative URLs and URLs without a schema has been removed, without any option to allow them. I understand the reasoning is that the RFC specifies that a URL must include a schema and a host, which is fair enough. But it leaves the user with no simple way to validate domain names or relative URLs. So can I suggest that we add a FILTER_VALIDATE_URI type that would allow domains, relative paths, or full URLs? -- Edit bug report at http://bugs.php.net/?id=40676edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40676r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40676r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40676r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40676r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40676r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40676r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40676r=needscript Try newer version:http://bugs.php.net/fix.php?id=40676r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40676r=support Expected behavior:http://bugs.php.net/fix.php?id=40676r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40676r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40676r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40676r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40676r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40676r=dst IIS Stability:http://bugs.php.net/fix.php?id=40676r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40676r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40676r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40676r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40676r=mysqlcfg
#22055 [Com]: Memory leak with references in objects
ID: 22055
Comment by: matthieu dot aubry at gmail dot com
Reported By: jparneodo at yahoo dot fr
Status: No Feedback
Bug Type: Scripting Engine problem
Operating System: RedHat 7.2
PHP Version: 4.3.1-dev
New Comment:
I also have the same problem using
PHP Version = 5.1.2
Build Date = Nov 2 2006 12:28:13
Server API = Command Line Interface
This bug is really annoying.
I'm working on a project which loads thousands of files parsed into
objects.
I use the technic
$this-myObjectMember-register($this);
which creates cross references.
Calling unset() doesn't change anything, as seen in the examples
provided above.
I would love to see this bug fixed! Thank you.
Previous Comments:
[2005-06-17 16:25:54] apinstein at mac dot com
I have experienced this problem on PHP5 as well... here's a
test script:
echo memory_get_usage() . (initial)\n;
$t = new test;
echo memory_get_usage() . (after: \$t = new test();)\n;
unset($t);
echo memory_get_usage() . (after: unset(\$t);)\n;
echo done\n;
class test
{
protected $str;
protected $t2;
function __construct()
{
print construct test\n;
$this-str = str_repeat('1234567890', 1000);
$this-t2 = new test2($this);
}
function __destruct()
{
print destruct test\n;
}
}
class test2
{
protected $str;
protected $t1;
function __construct($t1)
{
print construct test2\n;
$this-str = str_repeat('1234567890', 1000);
$this-t1 = $t1;
}
function __destruct()
{
print destruct test2\n;
unset($this-str);
}
}
And the output of this script:
51416 (initial)
construct test
construct test2
72000 (after: $t = new test();)
72000 (after: unset($t);)
done
destruct test
destruct test2
It's definitely a real problem. Simply removing the cross-
referenced instance vars will remove the problem. However,
as you can see, even explicitly calling unset() still
doesn't release the objects or call destructors until the
script EXITS.
This is a *MAJOR* problem for anyone using OO to process
large amounts of information.
[2004-03-01 05:07:55] tom at scl dot co dot uk
Is anyone looking into this?
I've found any method of releasing the objects fails, no just using the
unset() function, if the object just go out of scope they aren't
released, for ezample, if you do something like
function MyFunc() {
$x = new C;
$y = new C;
$x-ref = $y;
$y-ref = $x;
}
Then after the function has finished then the memory allocated for the
local variables $x and $y is not freed up.
[2004-02-23 11:21:41] tom at scl dot co dot uk
I had this problem with PHP4.3.3. I then found this bug report and
upgraded to PHP5.0.0b4 to try and fix this problem and I still get the
memory leak problem, there is some demo code below, you need to change
/path/to/large/file. I've been using a file which is about 1.5mb and
when PHP is set to stop when it reaches 8mb then it only makes it
through the loop twice.
I'm 1.5 years into a project and I could really do with knowing if this
is going to be fixed anytime soon so I can either wait for the fix or
try and find a work around. Thanks for your time,
Tom
---
?php
class C {
var $ref;
var $val;
function C() {
$this-val = file('/path/to/large/file');
}
}
while (1) {
$x = new C;
$y = new C;
$x-ref = $y;
$y-ref = $x;
unset($y);
unset($x);
echo .;
}
?
[2003-02-25 02:03:00] [EMAIL PROTECTED]
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to Open. Thank you.
[2003-02-17 04:51:30] [EMAIL PROTECTED]
Test with the php5 snapshot please:
http://snaps.php.net/php5-latest.tar.gz
It won't be fixed in PHP 4 anyway as it has to do with the way objects
work there.
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/22055
--
Edit this bug report at http://bugs.php.net/?id=22055edit=1
#40677 [NEW]: PHP crash when calling Java
From: poon dot fung at comcast dot net
Operating system: windows xp
PHP version: 5.2.1
PHP Bug Type: Java related
Bug description: PHP crash when calling Java
Description:
Running the sample code in Java integration page causes PHP crash.
Reproduce code:
---
?php
// get instance of Java class java.lang.System in PHP
$system = new Java('java.lang.System');
// demonstrate property access
echo 'Java version=' . $system-getProperty('java.version') . 'br /';
echo 'Java vendor=' . $system-getProperty('java.vendor') . 'br /';
echo 'OS=' . $system-getProperty('os.name') . ' ' .
$system-getProperty('os.version') . ' on ' .
$system-getProperty('os.arch') . ' br /';
// java.util.Date example
$formatter = new Java('java.text.SimpleDateFormat',
, dd, 'at' h:mm:ss a );
echo $formatter-format(new Java('java.util.Date'));
?
Expected result:
This result is produced by PHP v4.4.5.
D:\test-php2Java.php
can't open C:\j2sdk1.4.1_01\lib\tzmappings.
ZoneInfo: C:\j2sdk1.4.1_01\lib\zi\ZoneInfoMappings (The system cannot find
the path specified)
ZoneInfo: C:\j2sdk1.4.1_01\lib\zi\ZoneInfoMappings (The system cannot find
the path specified)
X-Powered-By: PHP/4.4.5
Content-type: text/html
Java version=1.4.1_01br /Java vendor=Sun Microsystems Inc.br
/OS=Windows XP
5.1 on x86 br /Thursday, March 01, 2007 at 5:57:08 AM Greenwich Mean
Time
Actual result:
--
CLI has encountered a problem and needs to close. We are sorry for the
inconvenience.
AppName: php.exe AppVer: 5.2.0.0 ModName: unknown
ModVer: 0.0.0.0 Offset: 011edf24
--
Edit bug report at http://bugs.php.net/?id=40677edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=40677r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=40677r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=40677r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=40677r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=40677r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=40677r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=40677r=needscript
Try newer version:http://bugs.php.net/fix.php?id=40677r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=40677r=support
Expected behavior:http://bugs.php.net/fix.php?id=40677r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=40677r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=40677r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=40677r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40677r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=40677r=dst
IIS Stability:http://bugs.php.net/fix.php?id=40677r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=40677r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=40677r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=40677r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=40677r=mysqlcfg
#40507 [Com]: php install probem
ID: 40507 Comment by: luc at suryo dot com Reported By: armin at xos dot net Status: Suspended Bug Type: Unknown/Other Function Operating System: solaris 2.9 64 bit PHP Version: 5.2.1 New Comment: Hello, exact same problem (errors), unable to unpack. OS: Solaris 10 Platform: Sparc Compiler: Sun Studio 11 C[XX]FLAGS: -xO5 -xarch=v9 -KPIC (so compiling 64 bits) I needed the -KPIC since I was compiling a httpd module.. it does not happens on a Solaris x86 compiled 32bits -ls Previous Comments: [2007-02-16 20:38:30] armin at xos dot net well the gcc people told me so - sorry. -fno-strict-aliasing seems to be enough to not segfault. this workaround id not magical. please read the gcc bug report above. i tried the ltrim patch. it's the same with or without. thanks for trying to reproduce it. [2007-02-16 13:00:28] [EMAIL PROTECTED] i used the suggested compile flags and no segmentation fault anymore, which shows it's a php bug It doesn't sound too convincing. And the fact that the problem is reproducible ONLY on Sparc and ONLY using GCC 4.x makes me wonder what made you think so. please add -fno-strict-aliasing and/or -fwrapv to the c-flags for solaris 2.9 64bit I would prefer to find the roots of the problem instead of applying some magical workaround. however: how to fix the Phar archive problem? Let me see if I can reproduce it with working GCC. [2007-02-16 12:22:06] armin at xos dot net Description: related to: http://bugs.php.net/bug.php?id=39418 i had the same problem and submitted a bug report with gcc. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30819 i used the suggested compile flags and no segmentation fault anymore, which shows it's a php bug - probably since i get following during make install: /usr/local/src/apache_etc/php-5.2.1_error/sapi/cli/php -n -dshort_open_tag=0 -dsafe_mode=0 -dopen_basedir= -derror_reporting=E_ALL -dmemory_limit=-1 -ddetect_unicode=0 pear/install-pear-nozlib.phar -d /usr/local/lib/php -b /usr/local/bin Warning: unpack(): Type V: not enough input, need 4, have 0 in /usr/local/src/apache_etc/php-5.2.1_error/pear/install-pear-nozlib.phar on line 339 Notice: Uninitialized string offset: 0 in /usr/local/src/apache_etc/php-5.2.1_error/pear/install-pear-nozlib.phar on line 342 Notice: Uninitialized string offset: 1 in /usr/local/src/apache_etc/php-5.2.1_error/pear/install-pear-nozlib.phar on line 342 Notice: Uninitialized string offset: 2 in /usr/local/src/apache_etc/php-5.2.1_error/pear/install-pear-nozlib.phar on line 342 Notice: Uninitialized string offset: 0 in /usr/local/src/apache_etc/php-5.2.1_error/pear/install-pear-nozlib.phar on line 343 Fatal error: Phar is API version 0.0.0, but PHP_Archive is API version 0.8.0 in /usr/local/src/apache_etc/php-5.2.1_error/pear/install-pear-nozlib.phar on line 353 please add -fno-strict-aliasing and/or -fwrapv to the c-flags for solaris 2.9 64bit however: how to fix the Phar archive problem? -- Edit this bug report at http://bugs.php.net/?id=40507edit=1
