Bug #53811 [Opn-Wfx]: filesize disregards case sensitive file system
Edit report at http://bugs.php.net/bug.php?id=53811edit=1
ID: 53811
Updated by: paj...@php.net
Reported by:jl_ewing at hotmail dot com
Summary:filesize disregards case sensitive file system
-Status: Open
+Status: Wont fix
Type: Bug
Package:Filesystem function related
Operating System: Windows XP
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
No, it should not. Case insensitive NTFS partition support is highly
experimental
and requires special cases and APIs calls. We aren't going to support
that any
time soon.
Previous Comments:
[2011-01-22 06:19:02] jl_ewing at hotmail dot com
Description:
Windows XP with NTFS and Case in-sensitivity is DISABLED (e.g. the file
system is case sensitive). PHP 5.3.5 is VC6 x86 Non Thread Safe ZIP
file extracted \PHP535 directory
HKLM\SYSTEM\CurrentControlSet\Control\Session
Manager\kernel\obcaseinsensitive 0
C:\opt\filesdir
Volume in drive C is Boot
Volume Serial Number is 84D1-331E
Directory of C:\opt\files
01/21/2011 11:03 PMDIR .
01/21/2011 11:03 PMDIR ..
01/21/2011 11:03 PM 3,400 testA.out
01/21/2011 11:03 PM 550 testa.out
2 File(s) 3,950 bytes
2 Dir(s) 65,225,863,168 bytes free
C:\PHP535php -f test.php (see test script)
Array
(
[testA.out] = 550
[testa.out] = 550
)
The file that was created first seems to be the one that it uses. On
NTFS file systems that are case sensitive filesize should pick up the
appropriate file sizes
Test script:
---
$dir = '\\opt\\files';
$index = array();
$files = scandir($dir);
foreach ($files as $file) {
if (is_file($dir . '\\' . $file)) {
$sizeX = filesize($dir. /$file);
$index[$file] = $sizeX;
unset ($file, $sizeX);
}
}
print_r($index);
Expected result:
Array
(
[testA.out] = 3400
[testa.out] = 550
)
Actual result:
--
Array
(
[testA.out] = 550
[testa.out] = 550
)
--
Edit this bug report at http://bugs.php.net/bug.php?id=53811edit=1
Req #53793 [Bgs]: ISAPI SUPPORT FOR PHP5.3
Edit report at http://bugs.php.net/bug.php?id=53793edit=1 ID: 53793 Updated by: paj...@php.net Reported by:chutz747 at gmail dot com Summary:ISAPI SUPPORT FOR PHP5.3 Status: Bogus Type: Feature/Change Request Package:IIS related Operating System: Windows Server 2008 PHP Version:5.3.5 Block user comment: N Private report: N New Comment: The delta you are describing tells me that your config is wrong. You also don't seem to use a opcode cache (try wincache). Have you tried to read the IIS documentation (iis.net or php's manual) to see how to configure it for good performence (or not too slow)? As ISAPI is technically faster than fastcgi, it is far from being stable (even if it works for you, it does not mean it is stable). Previous Comments: [2011-01-21 23:50:08] chut747 at gmail dot com thanks for your response. I have timed socalled fastCGI and Isapi, on 5 differnt servers under differing trafic conditions, including a dual-core, 2 quad-core, and 2 octo-core servers, under light, medium and heavy traffic conditions. Pageloads using ISAPI loaded in on average 2 - 3 secs, on fastCGI it took almost 8-10 secs. Same servers, different config. Ecomerce sites cannot use fastCGI it is just unaccaptable to their customers. PHP is a robust, wonderful, and easy to use language and I am glad to use it for my sites. Please compile an ISAPI module into an upcoming release, let developers choose which meathod they wan't instead of forcing them to use only one. [2011-01-20 05:35:00] ahar...@php.net ISAPI support was removed in PHP 5.3. As the migration guide says [0], the recommendation is to use FastCGI instead. [0] http://au2.php.net/manual/en/migration53.windows.php [2011-01-19 19:36:29] chutz747 at gmail dot com Description: I tried to download all of the zip and install files but can't find the php5isapi.dll file anywhere in PHP 3.5 version, did the extension change? is there any plan in compiling isapi support into 3.5. This is not so much a bug as it is necessary for certain sites. I am running a high-end ecomerce application that supports millions of daily users it runs just fine on a WIMP system with ISAPI with PHP 5.2. However if I try CGI or even Fast-CGI pages don't load fast enough. This is not a server ploblem this is a PHP problem which is why ISAPI support really needs to be added. I really would like to upgrade to 5.3 but without the ISAPI support I'm afraid I can never upgrade. All this talk about ISAPI being unstable in false. I have been running PHP5.2 on multiple servers all runing Windows and IIS for years via ISAPI and have never had a single failure or crash. It is super fast and super stable. Please complie a usable x86 windows build for PHP 5.3.5 with ISAPI. Thanks -- Edit this bug report at http://bugs.php.net/bug.php?id=53793edit=1
Bug #53735 [Fbk-Opn]: NumberFormatter returns NaN when converting float point
Edit report at http://bugs.php.net/bug.php?id=53735edit=1 ID: 53735 User updated by:mortenskyt at gmail dot com Reported by:mortenskyt at gmail dot com Summary:NumberFormatter returns NaN when converting float point -Status: Feedback +Status: Open Type: Bug Package:I18N and L10N related Operating System: MacOS X 10.6.6 PHP Version:5.3.5 Block user comment: N Private report: N New Comment: Hello again, On my Mac with PHP 5.3.5 from Macports: Internationalization support = enabled version = 1.1.0 ICU version = 4.6 (same version on non-working FreeBSD PHP 5.3.4-machine) The FreeBSD-machine with PHP 5.3.3, which works with no issues: Internationalization support = enabled version = 1.0.3 ICU version = 3.8.1 Previous Comments: [2011-01-22 08:41:40] s...@php.net Works for me in 5.3 on Mac OS X. Which ICU version do you have (check phpinfo())? [2011-01-13 14:46:59] mortenskyt at gmail dot com Description: In PHP 5.3.5, giving float point values to numfmt_format doesn't work when setlocale is set to a country using comma instead of dot in floating point. Also does not work in PHP 5.3.4 (FreeBSD) DOES work on 5.3.3 (FreeBSD) Perhaps interesting notes from my configuration: intl Internationalization support = enabled version = 1.1.0 ICU version = 4.6 Directive = Local Value = Master Value intl.default_locale = no value = no value intl.error_level = 0 = 0 Test script: --- ?php $fmt = numfmt_create(da_DK, \NumberFormatter::CURRENCY); echo numfmt_format($fmt, 5.5).\n; setlocale(LC_ALL, da_DK.UTF-8); echo numfmt_format($fmt, 5.5).\n; echo numfmt_format($fmt, 5,5).\n; Expected result: 5,50 kr 5,50 kr 5,00 kr Actual result: -- 5,50 kr NaN 5,00 kr -- Edit this bug report at http://bugs.php.net/bug.php?id=53735edit=1
[PHP-BUG] Bug #53814 [NEW]: angela
From: Operating system: PHP version: 5.3.5 Package: ncurses related Bug Type: Bug Bug description:angela Description: --- From manual page: http://www.php.net/function.mail#Description --- -- Edit bug report at http://bugs.php.net/bug.php?id=53814edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53814r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53814r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53814r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53814r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53814r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53814r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53814r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53814r=needscript Try newer version: http://bugs.php.net/fix.php?id=53814r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53814r=support Expected behavior: http://bugs.php.net/fix.php?id=53814r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53814r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53814r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53814r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53814r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53814r=dst IIS Stability: http://bugs.php.net/fix.php?id=53814r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53814r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53814r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53814r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53814r=mysqlcfg
[PHP-BUG] Bug #53815 [NEW]: angela
From: Operating system: PHP version: 5.3.5 Package: ncurses related Bug Type: Bug Bug description:angela Description: --- From manual page: http://www.php.net/function.mail#Description --- -- Edit bug report at http://bugs.php.net/bug.php?id=53815edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53815r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53815r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53815r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53815r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53815r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53815r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53815r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53815r=needscript Try newer version: http://bugs.php.net/fix.php?id=53815r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53815r=support Expected behavior: http://bugs.php.net/fix.php?id=53815r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53815r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53815r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53815r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53815r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53815r=dst IIS Stability: http://bugs.php.net/fix.php?id=53815r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53815r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53815r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53815r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53815r=mysqlcfg
[PHP-BUG] Bug #53816 [NEW]: htmlspecialchars_decode() only works on lower case stuff
From: Operating system: Windows 7 PHP version: 5.3.5 Package: Unknown/Other Function Bug Type: Bug Bug description:htmlspecialchars_decode() only works on lower case stuff Description: htmlspecialchars_decode() and html_entity_decode() only convert lower case entities. eg. lt;, gt;, etc. Upper case entities - LT;, GT;, etc - are ignored. -- Edit bug report at http://bugs.php.net/bug.php?id=53816edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53816r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53816r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53816r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53816r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53816r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53816r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53816r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53816r=needscript Try newer version: http://bugs.php.net/fix.php?id=53816r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53816r=support Expected behavior: http://bugs.php.net/fix.php?id=53816r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53816r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53816r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53816r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53816r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53816r=dst IIS Stability: http://bugs.php.net/fix.php?id=53816r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53816r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53816r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53816r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53816r=mysqlcfg
Bug #53811 [Wfx]: filesize disregards case sensitive file system
Edit report at http://bugs.php.net/bug.php?id=53811edit=1
ID: 53811
User updated by:jl_ewing at hotmail dot com
Reported by:jl_ewing at hotmail dot com
Summary:filesize disregards case sensitive file system
Status: Wont fix
Type: Bug
Package:Filesystem function related
Operating System: Windows XP
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
You mean case sensitive NTFS partition support is highly experimental?
I'm calling bull on that as the feature has been around since at least
2005 and Microsoft FULLY supports it and if you were to search TechNet
you would find many articles regarding the topic.
Previous Comments:
[2011-01-22 13:16:28] paj...@php.net
No, it should not. Case insensitive NTFS partition support is highly
experimental
and requires special cases and APIs calls. We aren't going to support
that any
time soon.
[2011-01-22 06:19:02] jl_ewing at hotmail dot com
Description:
Windows XP with NTFS and Case in-sensitivity is DISABLED (e.g. the file
system is case sensitive). PHP 5.3.5 is VC6 x86 Non Thread Safe ZIP
file extracted \PHP535 directory
HKLM\SYSTEM\CurrentControlSet\Control\Session
Manager\kernel\obcaseinsensitive 0
C:\opt\filesdir
Volume in drive C is Boot
Volume Serial Number is 84D1-331E
Directory of C:\opt\files
01/21/2011 11:03 PMDIR .
01/21/2011 11:03 PMDIR ..
01/21/2011 11:03 PM 3,400 testA.out
01/21/2011 11:03 PM 550 testa.out
2 File(s) 3,950 bytes
2 Dir(s) 65,225,863,168 bytes free
C:\PHP535php -f test.php (see test script)
Array
(
[testA.out] = 550
[testa.out] = 550
)
The file that was created first seems to be the one that it uses. On
NTFS file systems that are case sensitive filesize should pick up the
appropriate file sizes
Test script:
---
$dir = '\\opt\\files';
$index = array();
$files = scandir($dir);
foreach ($files as $file) {
if (is_file($dir . '\\' . $file)) {
$sizeX = filesize($dir. /$file);
$index[$file] = $sizeX;
unset ($file, $sizeX);
}
}
print_r($index);
Expected result:
Array
(
[testA.out] = 3400
[testa.out] = 550
)
Actual result:
--
Array
(
[testA.out] = 550
[testa.out] = 550
)
--
Edit this bug report at http://bugs.php.net/bug.php?id=53811edit=1
Bug #53811 [Wfx]: filesize disregards case sensitive file system
Edit report at http://bugs.php.net/bug.php?id=53811edit=1
ID: 53811
Updated by: paj...@php.net
Reported by:jl_ewing at hotmail dot com
Summary:filesize disregards case sensitive file system
Status: Wont fix
Type: Bug
Package:Filesystem function related
Operating System: Windows XP
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
Yes, that's what I meant.
Your statement about MSFT fully supporting it with all possible
functions is
wrong, btw.
Previous Comments:
[2011-01-22 18:12:17] jl_ewing at hotmail dot com
You mean case sensitive NTFS partition support is highly experimental?
I'm calling bull on that as the feature has been around since at least
2005 and Microsoft FULLY supports it and if you were to search TechNet
you would find many articles regarding the topic.
[2011-01-22 13:16:28] paj...@php.net
No, it should not. Case insensitive NTFS partition support is highly
experimental
and requires special cases and APIs calls. We aren't going to support
that any
time soon.
[2011-01-22 06:19:02] jl_ewing at hotmail dot com
Description:
Windows XP with NTFS and Case in-sensitivity is DISABLED (e.g. the file
system is case sensitive). PHP 5.3.5 is VC6 x86 Non Thread Safe ZIP
file extracted \PHP535 directory
HKLM\SYSTEM\CurrentControlSet\Control\Session
Manager\kernel\obcaseinsensitive 0
C:\opt\filesdir
Volume in drive C is Boot
Volume Serial Number is 84D1-331E
Directory of C:\opt\files
01/21/2011 11:03 PMDIR .
01/21/2011 11:03 PMDIR ..
01/21/2011 11:03 PM 3,400 testA.out
01/21/2011 11:03 PM 550 testa.out
2 File(s) 3,950 bytes
2 Dir(s) 65,225,863,168 bytes free
C:\PHP535php -f test.php (see test script)
Array
(
[testA.out] = 550
[testa.out] = 550
)
The file that was created first seems to be the one that it uses. On
NTFS file systems that are case sensitive filesize should pick up the
appropriate file sizes
Test script:
---
$dir = '\\opt\\files';
$index = array();
$files = scandir($dir);
foreach ($files as $file) {
if (is_file($dir . '\\' . $file)) {
$sizeX = filesize($dir. /$file);
$index[$file] = $sizeX;
unset ($file, $sizeX);
}
}
print_r($index);
Expected result:
Array
(
[testA.out] = 3400
[testa.out] = 550
)
Actual result:
--
Array
(
[testA.out] = 550
[testa.out] = 550
)
--
Edit this bug report at http://bugs.php.net/bug.php?id=53811edit=1
[PHP-BUG] Bug #53817 [NEW]: Extensions not loading on 64-bit OS
From: Operating system: Windows Server 2008 R2 PHP version: 5.2.17 Package: *General Issues Bug Type: Bug Bug description:Extensions not loading on 64-bit OS Description: Hey guys, I have been trying to install PHP 5.2.17 and 5.3.5 to a 64-bit Windows Server 2008 R2 Using VC6 for Apache and VC9 for IIS and in both cases it fails to load extensions saying they are not win32 valid applications. Not all extensions have this problem, the ones I'm trying to load are: LDAP MySQL PDO_MySQL And a few others I don't remember, but those are the most important to my interests. The closest I got was a MySQLng extension loaded using 5.3.5, but the PHP application I'm using does not recognize this one as MySQL and I get stuck. I don't know if this will involve the refactor of the msi files to 64-bit installation files. I even tried using the ZIP files and even though it works better, it still doesn't load several extensions. Thanks for anything you can do about this. Expected result: Extensions to load on a 64-bit Windows Server 2008 R2 -- Edit bug report at http://bugs.php.net/bug.php?id=53817edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53817r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53817r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53817r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53817r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53817r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53817r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53817r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53817r=needscript Try newer version: http://bugs.php.net/fix.php?id=53817r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53817r=support Expected behavior: http://bugs.php.net/fix.php?id=53817r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53817r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53817r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53817r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53817r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53817r=dst IIS Stability: http://bugs.php.net/fix.php?id=53817r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53817r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53817r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53817r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53817r=mysqlcfg
Bug #53817 [Opn-Bgs]: Extensions not loading on 64-bit OS
Edit report at http://bugs.php.net/bug.php?id=53817edit=1 ID: 53817 Updated by: paj...@php.net Reported by:jfha73 at gmail dot com Summary:Extensions not loading on 64-bit OS -Status: Open +Status: Bogus Type: Bug Package:*General Issues Operating System: Windows Server 2008 R2 PHP Version:5.2.17 Block user comment: N Private report: N New Comment: Try in CLI and double read the error messages. You are certainly missing some DLLs in your PATH. Previous Comments: [2011-01-22 18:28:09] jfha73 at gmail dot com Description: Hey guys, I have been trying to install PHP 5.2.17 and 5.3.5 to a 64-bit Windows Server 2008 R2 Using VC6 for Apache and VC9 for IIS and in both cases it fails to load extensions saying they are not win32 valid applications. Not all extensions have this problem, the ones I'm trying to load are: LDAP MySQL PDO_MySQL And a few others I don't remember, but those are the most important to my interests. The closest I got was a MySQLng extension loaded using 5.3.5, but the PHP application I'm using does not recognize this one as MySQL and I get stuck. I don't know if this will involve the refactor of the msi files to 64-bit installation files. I even tried using the ZIP files and even though it works better, it still doesn't load several extensions. Thanks for anything you can do about this. Expected result: Extensions to load on a 64-bit Windows Server 2008 R2 -- Edit this bug report at http://bugs.php.net/bug.php?id=53817edit=1
Bug #53816 [Opn-Bgs]: htmlspecialchars_decode() only works on lower case stuff
Edit report at http://bugs.php.net/bug.php?id=53816edit=1 ID: 53816 Updated by: scott...@php.net Reported by:zelnaga at gmail dot com Summary:htmlspecialchars_decode() only works on lower case stuff -Status: Open +Status: Bogus Type: Bug Package:Unknown/Other Function Operating System: Windows 7 PHP Version:5.3.5 Block user comment: N Private report: N New Comment: entity names are case sensitive in the spec. Previous Comments: [2011-01-22 16:10:12] zelnaga at gmail dot com Description: htmlspecialchars_decode() and html_entity_decode() only convert lower case entities. eg. lt;, gt;, etc. Upper case entities - LT;, GT;, etc - are ignored. -- Edit this bug report at http://bugs.php.net/bug.php?id=53816edit=1
Bug #53817 [Com]: Extensions not loading on 64-bit OS
Edit report at http://bugs.php.net/bug.php?id=53817edit=1 ID: 53817 Comment by: jfha73 at gmail dot com Reported by:jfha73 at gmail dot com Summary:Extensions not loading on 64-bit OS Status: Bogus Type: Bug Package:*General Issues Operating System: Windows Server 2008 R2 PHP Version:5.2.17 Block user comment: N Private report: N New Comment: I thought of that too, but all the DLLs are in place but when I check the error log for Apache it gives me the error I posted before. Previous Comments: [2011-01-22 18:53:42] paj...@php.net Try in CLI and double read the error messages. You are certainly missing some DLLs in your PATH. [2011-01-22 18:28:09] jfha73 at gmail dot com Description: Hey guys, I have been trying to install PHP 5.2.17 and 5.3.5 to a 64-bit Windows Server 2008 R2 Using VC6 for Apache and VC9 for IIS and in both cases it fails to load extensions saying they are not win32 valid applications. Not all extensions have this problem, the ones I'm trying to load are: LDAP MySQL PDO_MySQL And a few others I don't remember, but those are the most important to my interests. The closest I got was a MySQLng extension loaded using 5.3.5, but the PHP application I'm using does not recognize this one as MySQL and I get stuck. I don't know if this will involve the refactor of the msi files to 64-bit installation files. I even tried using the ZIP files and even though it works better, it still doesn't load several extensions. Thanks for anything you can do about this. Expected result: Extensions to load on a 64-bit Windows Server 2008 R2 -- Edit this bug report at http://bugs.php.net/bug.php?id=53817edit=1
Bug #53817 [Bgs]: Extensions not loading on 64-bit OS
Edit report at http://bugs.php.net/bug.php?id=53817edit=1 ID: 53817 User updated by:jfha73 at gmail dot com Reported by:jfha73 at gmail dot com Summary:Extensions not loading on 64-bit OS Status: Bogus Type: Bug Package:*General Issues Operating System: Windows Server 2008 R2 PHP Version:5.2.17 Block user comment: N Private report: N New Comment: I forgot to say, I also checked using php -m to check for missing dlls but it gave me no errors Previous Comments: [2011-01-22 19:00:00] jfha73 at gmail dot com I thought of that too, but all the DLLs are in place but when I check the error log for Apache it gives me the error I posted before. [2011-01-22 18:53:42] paj...@php.net Try in CLI and double read the error messages. You are certainly missing some DLLs in your PATH. [2011-01-22 18:28:09] jfha73 at gmail dot com Description: Hey guys, I have been trying to install PHP 5.2.17 and 5.3.5 to a 64-bit Windows Server 2008 R2 Using VC6 for Apache and VC9 for IIS and in both cases it fails to load extensions saying they are not win32 valid applications. Not all extensions have this problem, the ones I'm trying to load are: LDAP MySQL PDO_MySQL And a few others I don't remember, but those are the most important to my interests. The closest I got was a MySQLng extension loaded using 5.3.5, but the PHP application I'm using does not recognize this one as MySQL and I get stuck. I don't know if this will involve the refactor of the msi files to 64-bit installation files. I even tried using the ZIP files and even though it works better, it still doesn't load several extensions. Thanks for anything you can do about this. Expected result: Extensions to load on a 64-bit Windows Server 2008 R2 -- Edit this bug report at http://bugs.php.net/bug.php?id=53817edit=1
[PHP-BUG] Bug #53818 [NEW]: Missing info in pg_get_notify function
From: Operating system: Linux PHP version: 5.2.17 Package: PostgreSQL related Bug Type: Bug Bug description:Missing info in pg_get_notify function Description: Since Postgresql 9.0, event notifications fired by the NOTIFY sql command includes a payload (a 8000 bytes max piece of text). As of now, the PHP function pg_get_notify only retrieve the channel (name of the notification) and the backend pid. The attached patch improves this situation by adding the payload to the returned array of the pg_get_notify function, when the connected PG backend version is at least 9.0. Hope it helps... Test script: --- $dbconn = pg_connect(...) ; // To be completed pg_query($dbconn, LISTEN toto); pg_query($dbconn, NOTIFY toto, 'Hello world !'); $notify = pg_get_notify($dbconn, PGSQL_ASSOC) ; print_r($notify) ; Expected result: // Array(message = toto, pid = 12345, payload = Hello world !) Actual result: -- // Array(message = toto, pid = 12345) -- Edit bug report at http://bugs.php.net/bug.php?id=53818edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53818r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53818r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53818r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53818r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53818r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53818r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53818r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53818r=needscript Try newer version: http://bugs.php.net/fix.php?id=53818r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53818r=support Expected behavior: http://bugs.php.net/fix.php?id=53818r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53818r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53818r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53818r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53818r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53818r=dst IIS Stability: http://bugs.php.net/fix.php?id=53818r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53818r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53818r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53818r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53818r=mysqlcfg
Bug #53811 [Wfx]: filesize disregards case sensitive file system
Edit report at http://bugs.php.net/bug.php?id=53811edit=1
ID: 53811
User updated by:jl_ewing at hotmail dot com
Reported by:jl_ewing at hotmail dot com
Summary:filesize disregards case sensitive file system
Status: Wont fix
Type: Bug
Package:Filesystem function related
Operating System: Windows XP
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
I think you misunderstood. I was calling bull on the highly
experimental statement.
Microsoft fully supports the use the
HKLM\SYSTEM\CurrentControlSet\Control\Session
Manager\kernel\obcaseinsensitive registry key and case sensitivity in
the NTFS file system. In fact case sensitive file systems is a POSIX
requirement.
According to Microsoft:
POSIX requires a certain amount of functionality from the file system,
such as the ability for a file to have more than one name (or hard
links) and case-sensitive file naming. Neither FAT nor HPFS supports
these features, which is another reason why a new file system was
required for Windows NT. NTFS supports both hard links and
case-sensitive naming. If you want to run in a POSIX-conforming
environment, you need at least one NTFS disk partition on your
computer.
I don't recall stating anything about all possible functions and
indeed a bulk of the applications (notepad, for example) and utilities
do not understand what it means to have case sensitivity enabled or how
that translates to the file system. Of course I wasn't asking
Microsoft to fix that, I was only asking for PHP to be able to support
what the underlying file system supports.
If there are, in fact, separate API calls required to support
reading/writing to case sensitive files then I understand the task and
respectfully withdraw my request at this time.
Previous Comments:
[2011-01-22 18:22:22] paj...@php.net
Yes, that's what I meant.
Your statement about MSFT fully supporting it with all possible
functions is
wrong, btw.
[2011-01-22 18:12:17] jl_ewing at hotmail dot com
You mean case sensitive NTFS partition support is highly experimental?
I'm calling bull on that as the feature has been around since at least
2005 and Microsoft FULLY supports it and if you were to search TechNet
you would find many articles regarding the topic.
[2011-01-22 13:16:28] paj...@php.net
No, it should not. Case insensitive NTFS partition support is highly
experimental
and requires special cases and APIs calls. We aren't going to support
that any
time soon.
[2011-01-22 06:19:02] jl_ewing at hotmail dot com
Description:
Windows XP with NTFS and Case in-sensitivity is DISABLED (e.g. the file
system is case sensitive). PHP 5.3.5 is VC6 x86 Non Thread Safe ZIP
file extracted \PHP535 directory
HKLM\SYSTEM\CurrentControlSet\Control\Session
Manager\kernel\obcaseinsensitive 0
C:\opt\filesdir
Volume in drive C is Boot
Volume Serial Number is 84D1-331E
Directory of C:\opt\files
01/21/2011 11:03 PMDIR .
01/21/2011 11:03 PMDIR ..
01/21/2011 11:03 PM 3,400 testA.out
01/21/2011 11:03 PM 550 testa.out
2 File(s) 3,950 bytes
2 Dir(s) 65,225,863,168 bytes free
C:\PHP535php -f test.php (see test script)
Array
(
[testA.out] = 550
[testa.out] = 550
)
The file that was created first seems to be the one that it uses. On
NTFS file systems that are case sensitive filesize should pick up the
appropriate file sizes
Test script:
---
$dir = '\\opt\\files';
$index = array();
$files = scandir($dir);
foreach ($files as $file) {
if (is_file($dir . '\\' . $file)) {
$sizeX = filesize($dir. /$file);
$index[$file] = $sizeX;
unset ($file, $sizeX);
}
}
print_r($index);
Expected result:
Array
(
[testA.out] = 3400
[testa.out] = 550
)
Actual result:
--
Array
(
[testA.out] = 550
[testa.out] = 550
)
--
Edit this bug report at http://bugs.php.net/bug.php?id=53811edit=1
Bug #30034 [Com]: date('zS') does not always return the correct value
Edit report at http://bugs.php.net/bug.php?id=30034edit=1
ID: 30034
Comment by: loveme99hebe at yahoo dot com dot tw
Reported by:michael at michaelthompson dot org
Summary:date('zS') does not always return the correct value
Status: Bogus
Type: Bug
Package:Date/time related
Operating System: *
PHP Version:4.3.8
Block user comment: N
Private report: N
New Comment:
home add:443-J JALAN SULTAN KG BARU 34000 TAIPING,PERAK,MALAYSIA
I/C KAD:830617-08-6215
Previous Comments:
[2004-09-09 08:09:57] der...@php.net
But it's not a bug. The S parameter uses the current day-of-the month to
generate the suffix (with the 'j' parameter), and not the
day-of-the-year value.
From http://php.net/date:
S English ordinal suffix for the day of the month, 2 charactersst, nd,
rd or th. Works well with j
[2004-09-09 08:08:00] der...@php.net
Confirmed on Linux too, having a look now.
[2004-09-09 06:37:17] michael at michaelthompson dot org
Description:
date('zS') does not return the correct value on/above(?) day 251
Reproduce code:
---
date('zS'); # on (after ?) day 251
Expected result:
251st
Actual result:
--
251th
--
Edit this bug report at http://bugs.php.net/bug.php?id=30034edit=1
Bug #50675 [Com]: SoapClient can't handle object references correctly.
Edit report at http://bugs.php.net/bug.php?id=50675edit=1 ID: 50675 Comment by: bulk at janoszen dot hu Reported by:margaritisz dot oresztesz at dotroll dot hu Summary:SoapClient can't handle object references correctly. Status: Open Type: Bug Package:SOAP related Operating System: Linux PHP Version:5.2.12 Block user comment: N Private report: N New Comment: Confirmed in PHP 5.3.4, still the same bug. The only fix for us is porting the SOAP library from 5.2.0, which has other, more manageable bugs. Previous Comments: [2010-07-06 07:20:53] bulk at janoszen dot hu Is somebody looking into this? [2010-01-15 12:05:15] margaritisz dot oresztesz at dotroll dot hu Package on the previous link is damaged. Source code can be found at: http://code.dotroll.com/files/bugreports/php-50675-soaprefs/soap.tar.gz [2010-01-13 13:53:38] srina...@php.net the client.php that you attached is tar.gz of the same server side code. pl.attach / provide appropriate client reproduce code [2010-01-06 08:46:33] margaritisz dot oresztesz at dotroll dot hu Description: When sending the same object multiple times in a SOAP call, SoapClient replaces the object with a href='..' object reference. However the client generates the request envelope with an incorrect parameter name, so the server does not get the referenced object. Reproduce code: --- Sources of a simple server and client could be found at the following URL: http://charlie.extra.hu/php-soap/soap.tar.gz If I run client.php, it gets back an object filled with null parameters. It should recieve the first object sent to the server. If I change the reference's parameter name to 'secondUser', the SOAP response includes the correct object. Expected result: Expected the following soap envelope to be sent: SOAP-ENV:test firstUser id=ref1 userId1/userId userNameuser/userName /firstUser secondUser href=#ref1/ /SOAP-ENV:test Actual result: -- Got this request: SOAP-ENV:test firstUser id=ref1 userId1/userId userNameuser/userName /firstUser firstUser href=#ref1/ /SOAP-ENV:test -- Edit this bug report at http://bugs.php.net/bug.php?id=50675edit=1
Bug #53814 [Opn-Bgs]: angela
Edit report at http://bugs.php.net/bug.php?id=53814edit=1 ID: 53814 Updated by: dtajchre...@php.net Reported by:stellaangela at live dot it Summary:angela -Status: Open +Status: Bogus Type: Bug Package:ncurses related PHP Version:5.3.5 Block user comment: N Private report: N New Comment: . Previous Comments: [2011-01-22 15:01:44] stellaangela at live dot it Description: --- From manual page: http://www.php.net/function.mail#Description --- -- Edit this bug report at http://bugs.php.net/bug.php?id=53814edit=1
Bug #53815 [Opn-Bgs]: angela
Edit report at http://bugs.php.net/bug.php?id=53815edit=1 ID: 53815 Updated by: dtajchre...@php.net Reported by:stellaangela at live dot it Summary:angela -Status: Open +Status: Bogus Type: Bug Package:ncurses related PHP Version:5.3.5 Block user comment: N Private report: N New Comment: . Previous Comments: [2011-01-22 15:01:46] stellaangela at live dot it Description: --- From manual page: http://www.php.net/function.mail#Description --- -- Edit this bug report at http://bugs.php.net/bug.php?id=53815edit=1
Req #34570 [Com]: Implement some sort of setproctitle() in cli version
Edit report at http://bugs.php.net/bug.php?id=34570edit=1
ID: 34570
Comment by: matt at mralston dot co dot uk
Reported by:steve-php-dev at spwiz dot com
Summary:Implement some sort of setproctitle() in cli version
Status: Open
Type: Feature/Change Request
Package:Feature/Change Request
Operating System: Linux 2.4 kernel
PHP Version:5.0.5
Block user comment: N
Private report: N
New Comment:
I can't stress how much I'd like to see this feature implemented.
I'm not a C programmer and I haven't got a clue how PHP is structured
behind the
scenes, but I can't
imagine that this feature would be difficult to implement.
I've been through a quite a journey with this conundrum today. I started
out
coding a new daemon
this morning. Began to wish I could change the /usr/bin/php
./caiman.php start
entry in the ps
auxw listing this afternoon. I then spent some time researching how to
do it
(which was fustrating
because I didn't even know how to phrase the question for Google when I
started). I eventually found
some C++ forums talking about modifying argv[0] and was excited and then
disappointed when I found it
didn't work in PHP. I drafted out a long e-mail I intended to send to
the PHP
developers, then figured
I'd better properly RTFM and check out the bug tracker first. That's
when I came
across this feature request
(and an older one from 2002). Unfortunately both appear to have
stalled.
So here I am, adding my voice to this request. I can grovel if you
like!
Please, please, please would somebody have a go at adding this feature
when
they've got some spare
time? Even if the feature is ultimately rejected for inclusion into the
trunk, a
little patch that I
could apply to my own servers would be appreciated so much.
In the meantime, I'm just about to start poking around the PHP sources
on my
development box and see
if I can implement something myself. As I said, I'm not a C programmer
so I
expect to struggle, but
it's worth a shot. I'm thinking of something like:
void pcntl_setproctitle(char *new_title)
{
sprintf(argv[0], new_title);
}
Thanks for listening to me ramble.
- Matt
Previous Comments:
[2005-09-20 23:39:12] steve-php-dev at spwiz dot com
Description:
I'm using the pcntl module in the CLI SAPI to fork off several
processes. I'd like the processes to be able to identify themselves in
ps. In Linux, you can do this by editing argv[0]. On BSD, you use the
setproctitle() function. Other higher level languages support this
feature. A simple perl script to do this on Linux would be:
$0 = bogus;
sleep 10;
I tried modifying $argv[0], but that only modified the PHP scripts copy
of argv, not the real argv. It'd be nice if there was a way to modify
the process title directly. Ideally, it would be cross-platform (for
Unix variants, at least).
This was originally requested in 2002
(http://bugs.php.net/bug.php?id=18400), but was rejected. When using
the pcntl functions in the CLI version, it really would be a useful
feature.
--
Edit this bug report at http://bugs.php.net/bug.php?id=34570edit=1
Bug #49078 [Com]: Make Failed sapi/cli/php Error 1
Edit report at http://bugs.php.net/bug.php?id=49078edit=1 ID: 49078 Comment by: de at engeljournal dot com Reported by:kdprice at baylou dot com Summary:Make Failed sapi/cli/php Error 1 Status: No Feedback Type: Bug Package:Compile Failure Operating System: CentOS 5 PHP Version:5.3SVN-2009-07-27 (snap) Block user comment: N Private report: N New Comment: I get the same problem. I start with ./configure --with-apxs2=/usr/local/apache2/bin/apxs --enable-sockets --enable- soap --with-gd --with-zlib --with-jpeg-dir=/usr --with-curl --with-png-dir=/usr --with-mysql=mysqlnd --with-mysqli=mysqlnd --with-pdo-mysql=mysqlnd make make install Expected result = success - Actual result ext/mysql/.libs/php_mysql.o: In function `_free_mysql_result': php_mysql.c:(.text+0x1c): undefined reference to `mysql_free_result' ext/mysql/.libs/php_mysql.o: In function `php_mysql_select_db': php_mysql.c:(.text+0xb8): undefined reference to `mysql_eof' php_mysql.c:(.text+0xe0): undefined reference to `mysql_fetch_row' php_mysql.c:(.text+0x10c): undefined reference to `mysql_select_db' ext/mysql/.libs/php_mysql.o: In function `_close_mysql_link': php_mysql.c:(.text+0x15b): undefined reference to `mysql_close' ext/mysql/.libs/php_mysql.o: In function `_close_mysql_plink': php_mysql.c:(.text+0x1bc): undefined reference to `mysql_close' ext/mysql/.libs/php_mysql.o: In function `zm_startup_mysql': php_mysql.c:(.text+0x45a): undefined reference to `mysql_server_init' ext/mysql/.libs/php_mysql.o: In function `zm_shutdown_mysql': php_mysql.c:(.text+0x486): undefined reference to `mysql_server_end' ext/mysql/.libs/php_mysql.o: In function `zm_info_mysql': php_mysql.c:(.text+0x5f2): undefined reference to `mysql_get_client_info' ext/mysql/.libs/php_mysql.o: In function `php_mysql_do_connect': php_mysql.c:(.text+0x725): undefined reference to `mysql_get_client_version' php_mysql.c:(.text+0x736): undefined reference to `mysql_get_client_version' php_mysql.c:(.text+0xcd0): undefined reference to `mysql_init' php_mysql.c:(.text+0xcff): undefined reference to `mysql_options' php_mysql.c:(.text+0xd46): undefined reference to `mysql_real_connect' php_mysql.c:(.text+0xd73): undefined reference to `mysql_error' php_mysql.c:(.text+0xdb0): undefined reference to `mysql_errno' php_mysql.c:(.text+0xe10): undefined reference to `mysql_options' php_mysql.c:(.text+0xf4f): undefined reference to `mysql_ping' php_mysql.c:(.text+0xf63): undefined reference to `mysql_errno' php_mysql.c:(.text+0xfb5): undefined reference to `mysql_real_connect' php_mysql.c:(.text+0x104d): undefined reference to `mysql_options' php_mysql.c:(.text+0x1254): undefined reference to `mysql_init' php_mysql.c:(.text+0x12fc): undefined reference to `mysql_options' php_mysql.c:(.text+0x1343): undefined reference to `mysql_real_connect' php_mysql.c:(.text+0x1370): undefined reference to `mysql_error' php_mysql.c:(.text+0x13ad): undefined reference to `mysql_errno' php_mysql.c:(.text+0x140d): undefined reference to `mysql_options' ext/mysql/.libs/php_mysql.o: In function `zif_mysql_close': php_mysql.c:(.text+0x172a): undefined reference to `mysql_eof' php_mysql.c:(.text+0x1752): undefined reference to `mysql_fetch_row' ext/mysql/.libs/php_mysql.o: In function `zif_mysql_get_client_info': php_mysql.c:(.text+0x194a): undefined reference to `mysql_get_client_info' ext/mysql/.libs/php_mysql.o: In function `zif_mysql_get_host_info': php_mysql.c:(.text+0x1aad): undefined reference to `mysql_get_host_info' ext/mysql/.libs/php_mysql.o: In function `zif_mysql_get_proto_info': php_mysql.c:(.text+0x1c15): undefined reference to `mysql_get_proto_info' ext/mysql/.libs/php_mysql.o: In function `zif_mysql_get_server_info': php_mysql.c:(.text+0x1d2b): undefined reference to `mysql_get_server_info' ext/mysql/.libs/php_mysql.o: In function `zif_mysql_info': php_mysql.c:(.text+0x1e8e): undefined reference to `mysql_info' ext/mysql/.libs/php_mysql.o: In function `zif_mysql_thread_id': php_mysql.c:(.text+0x2017): undefined reference to `mysql_thread_id' ext/mysql/.libs/php_mysql.o: In function `zif_mysql_stat': php_mysql.c:(.text+0x215e): undefined reference to `mysql_eof' php_mysql.c:(.text+0x2186): undefined reference to `mysql_fetch_row' php_mysql.c:(.text+0x21ae): undefined reference to `mysql_stat' ext/mysql/.libs/php_mysql.o: In function `zif_mysql_client_encoding': php_mysql.c:(.text+0x2332): undefined reference to `mysql_character_set_name' ext/mysql/.libs/php_mysql.o: In function `zif_mysql_set_charset': php_mysql.c:(.text+0x24a1): undefined reference to `mysql_set_character_set' ext/mysql/.libs/php_mysql.o: In function `php_mysql_do_query_general': php_mysql.c:(.text+0x25b4): undefined reference to `mysql_eof' php_mysql.c:(.text+0x25dc): undefined reference to `mysql_fetch_row'
Req #34570 [Opn]: Implement some sort of setproctitle() in cli version
Edit report at http://bugs.php.net/bug.php?id=34570edit=1
ID: 34570
Updated by: dtajchre...@php.net
Reported by:steve-php-dev at spwiz dot com
Summary:Implement some sort of setproctitle() in cli version
Status: Open
Type: Feature/Change Request
-Package:Feature/Change Request
+Package:*General Issues
Operating System: Linux 2.4 kernel
PHP Version:5.0.5
Block user comment: N
Private report: N
New Comment:
http://pecl.php.net/package/proctitle
Previous Comments:
[2011-01-23 01:48:45] matt at mralston dot co dot uk
I can't stress how much I'd like to see this feature implemented.
I'm not a C programmer and I haven't got a clue how PHP is structured
behind the
scenes, but I can't
imagine that this feature would be difficult to implement.
I've been through a quite a journey with this conundrum today. I started
out
coding a new daemon
this morning. Began to wish I could change the /usr/bin/php
./caiman.php start
entry in the ps
auxw listing this afternoon. I then spent some time researching how to
do it
(which was fustrating
because I didn't even know how to phrase the question for Google when I
started). I eventually found
some C++ forums talking about modifying argv[0] and was excited and then
disappointed when I found it
didn't work in PHP. I drafted out a long e-mail I intended to send to
the PHP
developers, then figured
I'd better properly RTFM and check out the bug tracker first. That's
when I came
across this feature request
(and an older one from 2002). Unfortunately both appear to have
stalled.
So here I am, adding my voice to this request. I can grovel if you
like!
Please, please, please would somebody have a go at adding this feature
when
they've got some spare
time? Even if the feature is ultimately rejected for inclusion into the
trunk, a
little patch that I
could apply to my own servers would be appreciated so much.
In the meantime, I'm just about to start poking around the PHP sources
on my
development box and see
if I can implement something myself. As I said, I'm not a C programmer
so I
expect to struggle, but
it's worth a shot. I'm thinking of something like:
void pcntl_setproctitle(char *new_title)
{
sprintf(argv[0], new_title);
}
Thanks for listening to me ramble.
- Matt
[2005-09-20 23:39:12] steve-php-dev at spwiz dot com
Description:
I'm using the pcntl module in the CLI SAPI to fork off several
processes. I'd like the processes to be able to identify themselves in
ps. In Linux, you can do this by editing argv[0]. On BSD, you use the
setproctitle() function. Other higher level languages support this
feature. A simple perl script to do this on Linux would be:
$0 = bogus;
sleep 10;
I tried modifying $argv[0], but that only modified the PHP scripts copy
of argv, not the real argv. It'd be nice if there was a way to modify
the process title directly. Ideally, it would be cross-platform (for
Unix variants, at least).
This was originally requested in 2002
(http://bugs.php.net/bug.php?id=18400), but was rejected. When using
the pcntl functions in the CLI version, it really would be a useful
feature.
--
Edit this bug report at http://bugs.php.net/bug.php?id=34570edit=1
[PHP-BUG] Bug #53820 [NEW]: segfault in liclntsh.so when using shared oci8 extension
From:
Operating system: Linux
PHP version: 5.3.5
Package: OCI8 related
Bug Type: Bug
Bug description:segfault in liclntsh.so when using shared oci8 extension
Description:
use the latest php 5.3.5, tested in:
gcc 4.4.5, ubuntu 10.10 x86, oracle express;
gcc ???, asia linux 2(same as RHEL5?) x86, oracle 10g R2;
gcc ???, centos 4.5 x86, oracle 10g R1.
./configure --disable-all --disable-cgi --without-pear --with-
oci8=shared,$ORACLE_HOME
make
php.ini:
extension_dir = ./modules
extension = oci8.so
oci8.privileged_connect = On
environment variable ORACLE_HOME and ORACLE_SID are both correct.
when using NULL as connection_string in oci_connect() to connect to
oracle:
sapi/cli/php -c php.ini -r oci_internal_debug(TRUE);
var_dump(oci_connect('sys', 'sys', NULL, NULL, OCI_SYSDBA));
it crashes:
OCI8 DEBUG: OCIHandleAlloc at
(/home/xianda/php-5.3.5.orig/ext/oci8/oci8.c:1067)
OCI8 DEBUG: OCIConnectionPoolCreate at (/home/xianda/php-
5.3.5.orig/ext/oci8/oci8.c:1068)
OCI8 DEBUG: OCIConnectionPoolDestroy at (/home/xianda/php-
5.3.5.orig/ext/oci8/oci8.c:1069)
OCI8 DEBUG: OCIHandleFree at
(/home/xianda/php-5.3.5.orig/ext/oci8/oci8.c:1070)
OCI8 DEBUG: OCINlsEnvironmentVariableGet at (/home/xianda/php-
5.3.5.orig/ext/oci8/oci8.c:1826)
OCI8 DEBUG L1: Got NO cached connection at (/home/xianda/php-
5.3.5.orig/ext/oci8/oci8.c:1871)
OCI8 DEBUG: Bypassing client-side session pool for session create at
(/home/xianda/php-5.3.5.orig/ext/oci8/oci8.c:2833)
OCI8 DEBUG: OCIEnvNlsCreate at (/home/xianda/php-
5.3.5.orig/ext/oci8/oci8.c:2810)
OCI8 DEBUG: OCIHandleAlloc at
(/home/xianda/php-5.3.5.orig/ext/oci8/oci8.c:2842)
OCI8 DEBUG: OCIServerAttach at (/home/xianda/php-
5.3.5.orig/ext/oci8/oci8.c:2850)
Segmentation fault
and the call stack shows that it crashes inside the libclntsh.so.
But if I provide a value for connection_string in oci_connect(), it works
fine,
and the call stack in the libclntsh.so is different.
And I try to build php using oci8 as a static
extension(--oci8=$ORACLE_HOME),
it also works fine when setting connection_string to NULL(this proves that
my
ORACLE_HOME and ORACLE_SID are correct).
And I test this in the previous three platforms, it acts the same. And I
also
try to use the latest instant client 10 and 11, the same results come out.
So I
believe that it can be easily reproduced in most or all platforms.
So is it the bug of php or oracle's client library???
--
Edit bug report at http://bugs.php.net/bug.php?id=53820edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53820r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53820r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53820r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53820r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53820r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53820r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53820r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53820r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53820r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53820r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53820r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53820r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53820r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53820r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53820r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53820r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53820r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53820r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53820r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53820r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53820r=mysqlcfg
