#43766 [Opn]: Arrays and inverted commas
ID: 43766
Updated by: [EMAIL PROTECTED]
Reported By: quick dot webmaster at gmail dot com
Status: Open
Bug Type: Arrays related
Operating System: Linux
PHP Version: 5.2.5
New Comment:
Your code is wrong, it is attempt to pass array as first argument.
I'm using PHP5.3, and the code below works fine. So, try:
?php
$image = 'img src=http://bugs.php.net/gifs/logo-bug.gif; /';
$trans4 = array('img src=' = '', ' /' = '');
var_dump(strtr($image, $trans4));
// string(37) http://bugs.php.net/gifs/logo-bug.gif;
?
Previous Comments:
[2008-01-06 06:38:13] quick dot webmaster at gmail dot com
Description:
Hello, if you try to insert a immediately before a ' in an array then
it will return strange results results.
Reproduce code:
---
?php
$image[0] = array('img src=http://bugs.php.net/gifs/logo-bug.gif;
/');
$trans4 = array('img src=' = '', ' /' = '');
$image2 = strtr($image[0], $trans4);
?
Expected result:
http://bugs.php.net/gifs/logo-bug.gif
Actual result:
--
http://bugs.php.net/gifs/logo-bug.gif;
--
Edit this bug report at http://bugs.php.net/?id=43766edit=1
#43762 [Opn-Bgs]: Boolean FALSE not handled correctly
ID: 43762 Updated by: [EMAIL PROTECTED] Reported By: scratch65535 at att dot net -Status: Open +Status: Bogus Bug Type: Scripting Engine problem Operating System: v2ksp4 PHP Version: 5.2.5 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 false castet to string is . Previous Comments: [2008-01-06 03:13:56] scratch65535 at att dot net Description: The constant isn't translated when alone. It's translated only when part of an arithmetic expression, or when passed to intval(). This bug appears on two different boxes, both running w2ksp4. One box is running 4.4.7 (the bug has persisted across upgrades since 4.2), the other 5.2.5. Reproduce code: --- ?php echo false ; echo (false) ; echo false+false ; echo intval(false) ; echo ''.false.'' ; ? Expected result: 0 Actual result: -- 00 -- Edit this bug report at http://bugs.php.net/?id=43762edit=1
#43639 [Com]: php-5.2.5-win32-installer.msi stops before it is finished.
ID: 43639 Comment by: sean dot mccleary at gmail dot com Reported By: erik dot kullberg at telia dot com Status: No Feedback Bug Type: *General Issues Operating System: Windows Vista PHP Version: 5.2.5 New Comment: Same problem here. More info from the Windows event viewer: Product: PHP 5.2.5 -- Error 1720. There is a problem with this Windows Installer package. A script required for this install to complete could not be run. Contact your support personnel or package vendor. Custom action unconfigApache script error -2146828218, Microsoft VBScript runtime error: Permission denied Line 142, Column 5, Previous Comments: [2007-12-30 01:00:02] 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-12-24 13:31:07] lehelkovach at hotmail dot com I also have the same problem having Vista Home Premium 32bit. I tried the installer provided in the reply but i got the same problem of the script not being able to run. [2007-12-22 17:12:48] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi [2007-12-19 21:17:52] erik dot kullberg at telia dot com Description: I try to install PHP_5.2.5 by use of php-5.2.5-win32-installer.msi, but it stops before it is finished and delivers the following message: There is a problem with this Windows Installer Package. A script required for this install to complete could not be run. Contact your support personnel or package vendor. I tried to run the installation with the wanted additions (MySQL and GD) and without any additions at all - the result is the same. System: Windows Vista, version 6.0 Home Premium. Server: Apache 2.2.6 I cannot extract a cure from the answers to those similar questions in the database. Is there one? Or maybe a prognosis for a solution? -- Edit this bug report at http://bugs.php.net/?id=43639edit=1
#43639 [Com]: php-5.2.5-win32-installer.msi stops before it is finished.
ID: 43639 Comment by: sean dot mccleary at gmail dot com Reported By: erik dot kullberg at telia dot com Status: No Feedback Bug Type: *General Issues Operating System: Windows Vista PHP Version: 5.2.5 New Comment: Same problem with 5.2.6-dev, by the way. Previous Comments: [2008-01-06 12:49:30] sean dot mccleary at gmail dot com Same problem here. More info from the Windows event viewer: Product: PHP 5.2.5 -- Error 1720. There is a problem with this Windows Installer package. A script required for this install to complete could not be run. Contact your support personnel or package vendor. Custom action unconfigApache script error -2146828218, Microsoft VBScript runtime error: Permission denied Line 142, Column 5, [2007-12-30 01:00:02] 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-12-24 13:31:07] lehelkovach at hotmail dot com I also have the same problem having Vista Home Premium 32bit. I tried the installer provided in the reply but i got the same problem of the script not being able to run. [2007-12-22 17:12:48] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi [2007-12-19 21:17:52] erik dot kullberg at telia dot com Description: I try to install PHP_5.2.5 by use of php-5.2.5-win32-installer.msi, but it stops before it is finished and delivers the following message: There is a problem with this Windows Installer Package. A script required for this install to complete could not be run. Contact your support personnel or package vendor. I tried to run the installation with the wanted additions (MySQL and GD) and without any additions at all - the result is the same. System: Windows Vista, version 6.0 Home Premium. Server: Apache 2.2.6 I cannot extract a cure from the answers to those similar questions in the database. Is there one? Or maybe a prognosis for a solution? -- Edit this bug report at http://bugs.php.net/?id=43639edit=1
#43639 [Com]: php-5.2.5-win32-installer.msi stops before it is finished.
ID: 43639 Comment by: sean dot mccleary at gmail dot com Reported By: erik dot kullberg at telia dot com Status: No Feedback Bug Type: *General Issues Operating System: Windows Vista PHP Version: 5.2.5 New Comment: Found a work-around. Create a batch file to run the installer, and run the batch file as administrator. Batch file should contain the single line: msiexec /i C:\php-5.2.5-win32-installer.msi Save it, right-click on it, run as administrator. Previous Comments: [2008-01-06 12:53:48] sean dot mccleary at gmail dot com Same problem with 5.2.6-dev, by the way. [2008-01-06 12:49:30] sean dot mccleary at gmail dot com Same problem here. More info from the Windows event viewer: Product: PHP 5.2.5 -- Error 1720. There is a problem with this Windows Installer package. A script required for this install to complete could not be run. Contact your support personnel or package vendor. Custom action unconfigApache script error -2146828218, Microsoft VBScript runtime error: Permission denied Line 142, Column 5, [2007-12-30 01:00:02] 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-12-24 13:31:07] lehelkovach at hotmail dot com I also have the same problem having Vista Home Premium 32bit. I tried the installer provided in the reply but i got the same problem of the script not being able to run. [2007-12-22 17:12:48] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi 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/43639 -- Edit this bug report at http://bugs.php.net/?id=43639edit=1
#43767 [NEW]: Symbolic constant FALSE handled differently to TRUE
From: scratch65535 at att dot net Operating system: w2ksp4 PHP version: 5.2.5 PHP Bug Type: Scripting Engine problem Bug description: Symbolic constant FALSE handled differently to TRUE Description: The symbolic constants FALSE and TRUE are treated differently, but should be treated the same. The principle of symbolic constants is that, during translation, the value for which they stand is substituted everywhere they appear. This principle is universally taught in texts, and I cannot think of a single language, from various assembly languages on up, where it is not true. The PHP documentation has nothing to say that would lead anyone to think that PHP is intended to work differently. What would be the advantage in making it work so differently? Reproduce code: --- echo false ; echo (false) ; echo false+false ; echo (false+false) ; echo intval(false) ; echo ''.false.'' ; echo true ; echo (true) ; echo true+true ; echo (true+true) ; echo intval(true) ; echo ''.true.'' ; Expected result: 00112211 Actual result: -- 000112211 -- Edit bug report at http://bugs.php.net/?id=43767edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43767r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43767r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43767r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43767r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43767r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43767r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43767r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43767r=needscript Try newer version:http://bugs.php.net/fix.php?id=43767r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43767r=support Expected behavior:http://bugs.php.net/fix.php?id=43767r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43767r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43767r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43767r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43767r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43767r=dst IIS Stability:http://bugs.php.net/fix.php?id=43767r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43767r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43767r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43767r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43767r=mysqlcfg
#43767 [Opn-Bgs]: Symbolic constant FALSE handled differently to TRUE
ID: 43767 Updated by: [EMAIL PROTECTED] Reported By: scratch65535 at att dot net -Status: Open +Status: Bogus Bug Type: Scripting Engine problem Operating System: w2ksp4 PHP Version: 5.2.5 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 Please read about the PHP type system. http://de.php.net/manual/en/language.types.type-juggling.php And please don't open yet another bug but check other _support_ channels (like the php generals list) if you have further questions. Previous Comments: [2008-01-06 14:15:52] scratch65535 at att dot net Description: The symbolic constants FALSE and TRUE are treated differently, but should be treated the same. The principle of symbolic constants is that, during translation, the value for which they stand is substituted everywhere they appear. This principle is universally taught in texts, and I cannot think of a single language, from various assembly languages on up, where it is not true. The PHP documentation has nothing to say that would lead anyone to think that PHP is intended to work differently. What would be the advantage in making it work so differently? Reproduce code: --- echo false ; echo (false) ; echo false+false ; echo (false+false) ; echo intval(false) ; echo ''.false.'' ; echo true ; echo (true) ; echo true+true ; echo (true+true) ; echo intval(true) ; echo ''.true.'' ; Expected result: 00112211 Actual result: -- 000112211 -- Edit this bug report at http://bugs.php.net/?id=43767edit=1
#43769 [NEW]: Comparison wrong
From: hardisc15 at gmail dot com
Operating system: Windows XP
PHP version: 5.2.5
PHP Bug Type: Scripting Engine problem
Bug description: Comparison wrong
Description:
Floating point should have equal treatment of whole number in this
example?
Sorry, I am using translator.
Reproduce code:
---
$teste=4.1;//$teste='4.1';
$confere=array(4='');
if(isset($confere[$teste])){echo 'BUG';}else{echo 'NO BUG';}
Expected result:
NO BUG
Actual result:
--
BUG
--
Edit bug report at http://bugs.php.net/?id=43769edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=43769r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=43769r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=43769r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=43769r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=43769r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=43769r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=43769r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=43769r=needscript
Try newer version:http://bugs.php.net/fix.php?id=43769r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=43769r=support
Expected behavior:http://bugs.php.net/fix.php?id=43769r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=43769r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=43769r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=43769r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43769r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=43769r=dst
IIS Stability:http://bugs.php.net/fix.php?id=43769r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=43769r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=43769r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=43769r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=43769r=mysqlcfg
#43768 [NEW]: Using [] operator on an array returned by a function call throws fatal error
From: roan dot kattouw at home dot nl
Operating system: any
PHP version: 5.2.5
PHP Bug Type: Scripting Engine problem
Bug description: Using [] operator on an array returned by a function call
throws fatal error
Description:
Any construct of the form myFunc()[x] or $object-myFunc()[x] results in a
fatal error, even if myFunc() returns an array. Putting the expression in
parentheses (like (myFunc())[x]) doesn't help. The only remedy seems to be
using an intermediate variable.
Reproduce code:
---
?php
function getArray() { return array(1, 2, 3); }
echo getArray()[1];
?
Expected result:
2 being output
Actual result:
--
Parse error: syntax error, unexpected '[', expecting ',' or ';' in
test.php on line 4
--
Edit bug report at http://bugs.php.net/?id=43768edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=43768r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=43768r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=43768r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=43768r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=43768r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=43768r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=43768r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=43768r=needscript
Try newer version:http://bugs.php.net/fix.php?id=43768r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=43768r=support
Expected behavior:http://bugs.php.net/fix.php?id=43768r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=43768r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=43768r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=43768r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43768r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=43768r=dst
IIS Stability:http://bugs.php.net/fix.php?id=43768r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=43768r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=43768r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=43768r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=43768r=mysqlcfg
#43770 [NEW]: docblock templates with getDocComment()
From: maikelvm at hotmail dot com
Operating system: windows
PHP version: 5.2.5
PHP Bug Type: Feature/Change Request
Bug description: docblock templates with getDocComment()
Description:
Can the use of docBlock templates be included when the getDocComment() is
called?
Reproduce code:
---
class SomeClass {
/[EMAIL PROTECTED]
* @access public
*/
/**
* @return string
*/
public function someMethod() { return }
/[EMAIL PROTECTED]/
}
$o = new ReflectionMethod(SomeClass,someMethod);
echo $o-getDocComment();
Expected result:
/**
* Comments...
* @access public
* @return string
*/
Actual result:
--
/**
* Comments...
* @return string
*/
--
Edit bug report at http://bugs.php.net/?id=43770edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=43770r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=43770r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=43770r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=43770r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=43770r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=43770r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=43770r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=43770r=needscript
Try newer version:http://bugs.php.net/fix.php?id=43770r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=43770r=support
Expected behavior:http://bugs.php.net/fix.php?id=43770r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=43770r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=43770r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=43770r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43770r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=43770r=dst
IIS Stability:http://bugs.php.net/fix.php?id=43770r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=43770r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=43770r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=43770r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=43770r=mysqlcfg
#43771 [NEW]: validateOnParse validate() give difference results
From: missingno at ifrance dot com
Operating system: Ubuntu 7.10
PHP version: 5.3CVS-2008-01-06 (snap)
PHP Bug Type: DOM XML related
Bug description: validateOnParse validate() give difference results
Description:
From what I understand, DOMDocument::validateOnParse() = TRUE
DOMDocument::validate() should return the same list of errors for a given
document.
But when dealing with HTML code, validate() seems to fail to deal with the
DTD correctly.
Therefore, using validate() validateOnParse gives different results.
I think that in the case of validate(), PHP calls libxml with options that
make it think it will be dealing with XML code and thus, an XML DTD. So,
once libxml loads the HTML DTD, it fails to parse it correctly and returns
a bunch of errors.
(HTML XML DTDs are similar, except that HTML ones allow for some more
constructs like the '' operator in ELEMENT declarations)
Reproduce code:
---
?php
/* Note: removing the system identifier doesn't change the result,
* except that errors in the DTD are caught immediately.
* (My guess would be that libxml tries to fetch the DTD from the
* system identifier instead of using a catalog for resolution) */
$markup = HTML
!DOCTYPE HTML PUBLIC
-//W3C//DTD HTML 4.0 Transitional//EN
http://www.w3.org/TR/html4/loose.dtd;
html
headtitleFoo/title/head
bodypBar/p/body
/html
HTML;
header('Content-Type: text/plain');
libxml_use_internal_errors(TRUE);
// First, using DOMDocument::validateOnParse.
libxml_clear_errors();
$dd1 = new DOMDocument();
$dd1-validateOnParse = TRUE;
echo Using validateOnParse:\n;
$dd1-loadHTML($markup);
var_dump(libxml_get_errors());
echo \n\n;
// Now, using DOMDocument::validate() instead.
libxml_clear_errors();
$dd2 = new DOMDocument();
$dd2-validateOnParse = FALSE;
echo Using validate():\n;
$dd2-loadHTML($markup);
$dd2-validate();
var_dump(libxml_get_errors());
?
Expected result:
Using validateOnParse:
array(0) {
}
Using validate():
array(0) {
}
Actual result:
--
Using validateOnParse:
array(0) {
}
Using validate():
array(3) {
[0]=
object(LibXMLError)#3 (6) {
[level]=
int(3)
[code]=
int(37)
[column]=
int(1)
[message]=
string(55) xmlParseEntityDecl: entity HTML.Version not terminated
[file]=
string(36) http://www.w3.org/TR/html4/loose.dtd;
[line]=
int(31)
}
[1]=
object(LibXMLError)#4 (6) {
[level]=
int(3)
[code]=
int(60)
[column]=
int(1)
[message]=
string(37) Content error in the external subset
[file]=
string(36) http://www.w3.org/TR/html4/loose.dtd;
[line]=
int(31)
}
[2]=
object(LibXMLError)#5 (6) {
[level]=
int(2)
[code]=
int(517)
[column]=
int(0)
[message]=
string(74) Could not load the external subset
http://www.w3.org/TR/html4/loose.dtd;
[file]=
string(0)
[line]=
int(0)
}
}
--
Edit bug report at http://bugs.php.net/?id=43771edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=43771r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=43771r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=43771r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=43771r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=43771r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=43771r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=43771r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=43771r=needscript
Try newer version:http://bugs.php.net/fix.php?id=43771r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=43771r=support
Expected behavior:http://bugs.php.net/fix.php?id=43771r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=43771r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=43771r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=43771r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43771r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=43771r=dst
IIS Stability:http://bugs.php.net/fix.php?id=43771r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=43771r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=43771r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=43771r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=43771r=mysqlcfg
#43751 [Com]: unpack test case fails
ID: 43751 Comment by: missingno at ifrance dot com Reported By: wdierkes at 5dollarwhitebox dot org Status: Open Bug Type: Compile Failure Operating System: Redhat EL 4 i386 PHP Version: 4.4.8 New Comment: Not really a bug, but the test engine should unset the docref_root docref_ext directives in php.ini indeed before proceeding with the tests. Previous Comments: [2008-01-04 18:08:15] wdierkes at 5dollarwhitebox dot org Description: I understand that PHP 4.4.8 was the last release for the 4 branch, so it isn't likely that any bug reports will catch attention. That said, I still wanted to report the bug in case others have the same issue. = FAILED TEST SUMMARY - Invalid format type validation [ext/standard/tests/strings/unpack.phpt] = make: *** [test] Error 1 + set +x TEST FAILURE: ../ext/standard/tests/strings/unpack.diff -- 001- Warning: unpack(): Invalid format type - in %s/unpack.php on line %d 001+ Warning: unpack() [/phpmanual/function.unpack.html]: Invalid format type - in /builddir/build/BUILD/php-4.4.8/ext/standard/tests/strings/unpack.php on line 2 ../ext/standard/tests/strings/unpack.diff result ends. Reproduce code: --- ext/standard/tests/strings/unpack.phpt Expected result: test case should pass. Actual result: -- Test case fails. -- Edit this bug report at http://bugs.php.net/?id=43751edit=1
#43759 [Com]: info.php with apache2.2.5 can be resolved in firefox ,but not in opera9.25
ID: 43759 Comment by: missingno at ifrance dot com Reported By: kulingkwi at sina dot com Status: Open Bug Type: Apache2 related Operating System: ubuntu 7.10 PHP Version: 5.2.5 New Comment: The problem seems to be related to Opera or (most probably) Apache. I don't think PHP has anything to do with this. Check your Apache configuration again. Also, make sure you used the exact same URL in both browsers. For example: http://localhost/test http://localhost/test/ may be treated differently by the server depending on its configuration. Previous Comments: [2008-01-05 15:28:14] kulingkwi at sina dot com Description: i install configure apache2.2.5 and php5.2.5 step by step with the INSTALL file,and write and info.php page to test,however the page can be resolved in firefox but not in opera9.25 Reproduce code: --- ?php phpinfo( ); ? Expected result: show the informatino page Actual result: -- the page can be resolved in firefox but not in opera9.25 -- Edit this bug report at http://bugs.php.net/?id=43759edit=1
#43769 [Opn-Bgs]: Comparison wrong
ID: 43769
Updated by: [EMAIL PROTECTED]
Reported By: hardisc15 at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Windows XP
PHP Version: 5.2.5
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
Says the documentation:
A key may be either an integer or a string.
Therefore, the float value is converted to integer.
?php
var_dump(array(1.4 = 'foobar'));
/*
array(1) {
[1]=
string(6) foobar
}
*/
Previous Comments:
[2008-01-06 15:16:05] hardisc15 at gmail dot com
Description:
Floating point should have equal treatment of whole number in this
example?
Sorry, I am using translator.
Reproduce code:
---
$teste=4.1;//$teste='4.1';
$confere=array(4='');
if(isset($confere[$teste])){echo 'BUG';}else{echo 'NO BUG';}
Expected result:
NO BUG
Actual result:
--
BUG
--
Edit this bug report at http://bugs.php.net/?id=43769edit=1
#43768 [Opn-Bgs]: Using [] operator on an array returned by a function call throws fatal error
ID: 43768
Updated by: [EMAIL PROTECTED]
Reported By: roan dot kattouw at home dot nl
-Status: Open
+Status: Bogus
Bug Type: Scripting Engine problem
Operating System: any
PHP Version: 5.2.5
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
See http://bugs.php.net/bug.php?id=43577
Previous Comments:
[2008-01-06 15:10:47] roan dot kattouw at home dot nl
Description:
Any construct of the form myFunc()[x] or $object-myFunc()[x] results
in a fatal error, even if myFunc() returns an array. Putting the
expression in parentheses (like (myFunc())[x]) doesn't help. The only
remedy seems to be using an intermediate variable.
Reproduce code:
---
?php
function getArray() { return array(1, 2, 3); }
echo getArray()[1];
?
Expected result:
2 being output
Actual result:
--
Parse error: syntax error, unexpected '[', expecting ',' or ';' in
test.php on line 4
--
Edit this bug report at http://bugs.php.net/?id=43768edit=1
#43772 [NEW]: the pcre (preg_*) functions should be able to pre-compile regexps
From: php at linuxhosted dot net Operating system: n/a PHP version: 5.2.5 PHP Bug Type: Feature/Change Request Bug description: the pcre (preg_*) functions should be able to pre-compile regexps Description: what I'm proposing is, adding a function (perhaps named preg_compile) that would accept 1 string parameter $pattern. the function would return a resource with the compiled pcre code which could be used anywhere in the other preg_* functions where a string for the pattern would be accepted. this way if you need to do 1000s of pcre matches of the same pattern(s) on different data, it would not require internally doing pcre_compile() over and over, saving very valuable cpu time. Reproduce code: --- ?php $pattern = preg_compile(/s[i1]mpl[e3] pattern here/i); // returns a new type of resource if (preg_match($pattern, simple pattern here)) // which can then be used anywhere the normal string pattern could be echo pattern matches\n; ? Expected result: well, obviously if this feature was added i'd expect to see: pattern matches Actual result: -- since this is not actually implemented i'd just get a fatal error :P -- Edit bug report at http://bugs.php.net/?id=43772edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43772r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43772r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43772r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43772r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43772r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43772r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43772r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43772r=needscript Try newer version:http://bugs.php.net/fix.php?id=43772r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43772r=support Expected behavior:http://bugs.php.net/fix.php?id=43772r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43772r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43772r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43772r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43772r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43772r=dst IIS Stability:http://bugs.php.net/fix.php?id=43772r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43772r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43772r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43772r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43772r=mysqlcfg
#43772 [Opn-Bgs]: the pcre (preg_*) functions should be able to pre-compile regexps
ID: 43772 Updated by: [EMAIL PROTECTED] Reported By: php at linuxhosted dot net -Status: Open +Status: Bogus Bug Type: Feature/Change Request Operating System: n/a PHP Version: 5.2.5 New Comment: The compiled regexp is cached after the first use, no need to compile it manually. Previous Comments: [2008-01-06 19:41:16] php at linuxhosted dot net Description: what I'm proposing is, adding a function (perhaps named preg_compile) that would accept 1 string parameter $pattern. the function would return a resource with the compiled pcre code which could be used anywhere in the other preg_* functions where a string for the pattern would be accepted. this way if you need to do 1000s of pcre matches of the same pattern(s) on different data, it would not require internally doing pcre_compile() over and over, saving very valuable cpu time. Reproduce code: --- ?php $pattern = preg_compile(/s[i1]mpl[e3] pattern here/i); // returns a new type of resource if (preg_match($pattern, simple pattern here)) // which can then be used anywhere the normal string pattern could be echo pattern matches\n; ? Expected result: well, obviously if this feature was added i'd expect to see: pattern matches Actual result: -- since this is not actually implemented i'd just get a fatal error :P -- Edit this bug report at http://bugs.php.net/?id=43772edit=1
#43497 [Opn-Asn]: OCI8 XML/getClobVal leaks UGA memory
ID: 43497
Updated by: [EMAIL PROTECTED]
Reported By: ghosh at q-one dot com
-Status: Open
+Status: Assigned
Bug Type: OCI8 related
Operating System: Linux 2.6.22-14-server
PHP Version: 5.2.5
-Assigned To:
+Assigned To: sixd
New Comment:
What I don't understand: I thought OCI_RETURN_LOBS is just a short-
cut for those who don't want to write:
That's what I don't understand either: does the leak appear only on
per-session basis or Oracle doesn't free those LOBs at all?
If the leak is only per-session, then users are not supposed even to
notice it, since PHP requests are not supposed to take more than several
seconds.
Previous Comments:
[2007-12-29 22:37:21] ghosh at q-one dot com
Really great! Thanks a lot!! This patch works. What I don't understand:
I thought OCI_RETURN_LOBS is just a short-cut for those who don't want
to write:
$s=$result[0]-load();
$result[0]-free();
$result[0]=$s;
If you use OCI_RETURN_LOBS you dont want to care about lobs but get the
result as a string and forget about lobs altogether. So IMHO this should
work as well. My specific problem is solved though.
[2007-12-27 21:44:07] [EMAIL PROTECTED]
This is really an issue with temporary LOBS since getClobVal()
returns a temporary LOB.
There are two parts to the fix: changing the script and patching
the OCI8 extension. Also don't forget to apply the patch for
http://bugs.php.net/bug.php?id=42496
Please test this suggestion and report any issues.
Thanks to Krishna Shankar for the solution.
1. Change the test to get the results as LOBs, not as
strings. This allows the script to free temporary LOBs.
In the supplied testcase change:
$query = select extract(xml, '/').getclobval() from ugatest;
$stmt = oci_parse($conn, $query);
if (oci_execute($stmt))
while ($result = oci_fetch_array($stmt,
OCI_NUM+OCI_RETURN_LOBS))
;
to:
$query = select extract(xml, '/').getclobval() from ugatest;
$stmt = oci_parse($conn, $query);
if (oci_execute($stmt))
while ($result = oci_fetch_array($stmt, OCI_NUM)) {
// echo $result[0]-load(), \n; // do something with the
XML
$result[0]-free(); // free the temporary LOB
}
The connection must be open when LOB-free() is called, as the
underlying OCILobFreeTemporary() call does a roundtrip to the
database.
2. Patch oci8_lob.c. The change copies some LOB freeing code
from php_oci_lob_close() into php_oci_lob_free():
--- oci8_lob.c.orig2007-07-31 12:21:08.0 -0700
+++ oci8_lob.c2007-12-27 12:33:19.0 -0800
@@ -647,6 +647,9 @@
Close LOB descriptor and free associated resources */
void php_oci_lob_free (php_oci_descriptor *descriptor TSRMLS_DC)
{
+#ifdef HAVE_OCI8_TEMP_LOB
+int is_temporary;
+#endif
if (!descriptor || !descriptor-connection) {
return;
@@ -662,6 +665,40 @@
php_oci_lob_flush(descriptor, OCI_LOB_BUFFER_FREE TSRMLS_CC);
}
+#ifdef HAVE_OCI8_TEMP_LOB
+if (descriptor-type == OCI_DTYPE_LOB) {
+PHP_OCI_CALL_RETURN(descriptor-connection-errcode,
+OCILobIsTemporary,
+(
+descriptor-connection-env,
+descriptor-connection-err,
+descriptor-descriptor,
+is_temporary
+ )
+);
+if (descriptor-connection-errcode != OCI_SUCCESS) {
+php_oci_error(descriptor-connection-err,
descriptor-connection-errcode TSRMLS_CC);
+PHP_OCI_HANDLE_ERROR(descriptor-connection,
descriptor-connection-errcode);
+return 1;
+}
+if (is_temporary) {
+PHP_OCI_CALL_RETURN(descriptor-connection-errcode,
+OCILobFreeTemporary,
+(
+descriptor-connection-svc,
+descriptor-connection-err,
+descriptor-descriptor
+ )
+);
+if (descriptor-connection-errcode != OCI_SUCCESS) {
+php_oci_error(descriptor-connection-err,
descriptor-connection-errcode TSRMLS_CC);
+PHP_OCI_HANDLE_ERROR(descriptor-connection,
descriptor-connection-errcode);
+return 1;
+}
+}
+}
+#endif
+
PHP_OCI_CALL(OCIDescriptorFree, (descriptor-descriptor,
descriptor-type));
zend_list_delete(descriptor-connection-rsrc_id);
[2007-12-20 18:04:32] ghosh at q-one dot com
Would pay someone who resolves this bug. Feel free to contact me if you
are interested.
[2007-12-05 23:18:05] [EMAIL PROTECTED]
Confirmed.
#43773 [NEW]: extensions can't find libucb.so.1
From: selsky at columbia dot edu Operating system: Solaris 9 PHP version: 5.2.5 PHP Bug Type: Compile Failure Bug description: extensions can't find libucb.so.1 Description: I am building php 5.2.5 on Solaris 9 using Sun Studio 11. Even if I explicitly set LDFLAGS='-R/usr/ucblib', the entensions cannot find libucb.so.1 Reproduce code: --- CC=cc CXX=CC LDFLAGS='-R/opt/local/lib -L/opt/local/lib -R/usr/ucblib' ../../src/configure \ --prefix=/opt/php-5.2.5 \ --sysconfdir=/etc/php \ --with-config-file-path=/etc/php \ --with-apxs2 \ --with-libxml-dir=/opt/local \ --with-openssl=/opt/openssl-0.9.8g \ --with-curl=/opt/curl-7.16.1 \ --with-mysql=shared,/opt/local Expected result: $ ldd /opt/php-5.2.5/lib/php/extensions/no-debug-non-zts- 20060613/mysql.so /opt/php-5.2.5/bin/php /opt/php-5.2.5/lib/php/extensions/no-debug-non-zts-20060613/mysql.so: libmysqlclient.so.14 = /opt/mysql- 4.1.22/lib/mysql/libmysqlclient.so.14 libc.so.1 = /usr/lib/libc.so.1 libucb.so.1 = (file not found) libresolv.so.2 =/usr/lib/libresolv.so.2 libsocket.so.1 =/usr/lib/libsocket.so.1 libnsl.so.1 = /usr/lib/libnsl.so.1 libelf.so.1 = /usr/lib/libelf.so.1 librt.so.1 =/usr/lib/librt.so.1 libgen.so.1 = /usr/lib/libgen.so.1 libm.so.1 = /usr/lib/libm.so.1 libz.so.1 = /usr/lib/libz.so.1 libdl.so.1 =/usr/lib/libdl.so.1 libmp.so.2 =/usr/lib/libmp.so.2 libaio.so.1 = /usr/lib/libaio.so.1 libmd5.so.1 = /usr/lib/libmd5.so.1 /usr/platform/SUNW,UltraAX-i2/lib/libc_psr.so.1 /usr/platform/SUNW,UltraAX-i2/lib/libmd5_psr.so.1 /opt/php-5.2.5/bin/php: libcrypt_i.so.1 = /usr/lib/libcrypt_i.so.1 librt.so.1 =/usr/lib/librt.so.1 libintl.so.3 = /opt/gettext-0.14.5/lib/libintl.so.3 libc.so.1 = /usr/lib/libc.so.1 libssl.so.0.9.8 = /opt/openssl- 0.9.8g/lib/libssl.so.0.9.8 libcrypto.so.0.9.8 =/opt/openssl- 0.9.8g/lib/libcrypto.so.0.9.8 libresolv.so.2 =/usr/lib/libresolv.so.2 libm.so.1 = /usr/lib/libm.so.1 libdl.so.1 =/usr/lib/libdl.so.1 libnsl.so.1 = /usr/lib/libnsl.so.1 libsocket.so.1 =/usr/lib/libsocket.so.1 libz.so.1 = /usr/lib/libz.so.1 libcurl.so.4 = /opt/curl-7.16.1/lib/libcurl.so.4 libxml2.so.2 = /opt/libxml2-2.6.22/lib/libxml2.so.2 libpthread.so.1 = /usr/lib/libpthread.so.1 libgen.so.1 = /usr/lib/libgen.so.1 libaio.so.1 = /usr/lib/libaio.so.1 libmd5.so.1 = /usr/lib/libmd5.so.1 libmp.so.2 =/usr/lib/libmp.so.2 /usr/platform/SUNW,UltraAX-i2/lib/libc_psr.so.1 libthread.so.1 =/usr/lib/libthread.so.1 /usr/platform/SUNW,UltraAX-i2/lib/libmd5_psr.so.1 -R/usr/ucblib seems to be missing in the extension link command... Actual result: -- By the way, my php 5.2.1 build didn't link against libucb at all. Why is this library now needed? -- Edit bug report at http://bugs.php.net/?id=43773edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43773r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43773r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43773r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43773r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43773r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43773r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43773r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43773r=needscript Try newer version:http://bugs.php.net/fix.php?id=43773r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43773r=support Expected behavior:http://bugs.php.net/fix.php?id=43773r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43773r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43773r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43773r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43773r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43773r=dst IIS Stability:http://bugs.php.net/fix.php?id=43773r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43773r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43773r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43773r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43773r=mysqlcfg
#43677 [Com]: Inconsistent behaviour of include_path set with php_value
ID: 43677 Comment by: d at tpyo dot net Reported By: root at net1 dot cc Status: Open Bug Type: Safe Mode/open_basedir Operating System: FreeBSD 6.2 PHP Version: 5.2.5 New Comment: Noticed the same thing with 5.2.5 on Linux w/ Apache 2. I'm aware this is supposed to be the intended behaviour as of 5.2.5 but something is definitely breaking. It seems the include_path is being unset or ignored at some point. Haven't experienced this at random as described - once it breaks it doesn't correct itself until restarting Apache. Could be linked to the fix for bug #41561? Previous Comments: [2007-12-26 01:47:49] root at net1 dot cc Description: PHP randomly assigns for the local include_path value the global one, not the one set with php_value, and, when it does assign the global value, it does not allow to use ini_set() to modify it (behaves like it was set with php_admin_value). Reproduce code: --- My default include path is .:/usr/local/share/pear. In the httpd.conf (btw, this is Apache 2.2.x), I have: php_value include_path .:/blabla There's a file 'test.php' which contains the following: ?php phpinfo(); ? Expected result: I open the test.php in a web browser and keep refreshing it. I expect it to show: include_path .:/blabla each time i refresh it Actual result: -- The results are random, once it shows: include_path .:/blabla once it shows: include_path .:/usr/local/share/pear -- Edit this bug report at http://bugs.php.net/?id=43677edit=1
#36561 [Com]: PDO_ODBC/MSSQL does not work with bound params in subquery
ID: 36561
Comment by: emil at troxy dot net
Reported By: travis at raybold dot com
Status: Assigned
Bug Type: PDO related
Operating System: Windows XP
PHP Version: 5.2.4
Assigned To: fmk
New Comment:
I was able to reproduce this error using the 2008-01-05 snapshot of
PDO_ODBC.
Reproduce code:
---
?php
$db = new PDO('odbc:Driver={SQL Server}; Server=localhost; Uid=test;
Pwd=test; Database=test;');
$db-setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$db-exec('CREATE TABLE #foo (id INT NOT NULL)');
$db-exec('INSERT INTO #foo VALUES(1)');
$stmt = $db-prepare('SELECT id FROM #foo WHERE id IN (SELECT id FROM
#foo WHERE id = ?)');
$stmt-bindValue(1, 1, PDO::PARAM_INT);
$stmt-execute();
var_dump($stmt-fetch(PDO::FETCH_ASSOC));
?
Expected result:
array(1) { [id]= string(1) 1 }
Actual result:
--
PHP Fatal error: Uncaught exception 'PDOException' with message
'SQLSTATE[42000]: Syntax error or access violation: 306 [Microsoft][ODBC
SQL Server Driver][SQL Server]The text, ntext, and image data types
cannot be compared or sorted, except when using IS NULL or LIKE
operator. (SQLExecute[306] at ..\pecl_5_2\pdo_odbc\odbc_stmt.c:133)'
A trace using the Profiler tool shows that the bound integer value is
incorrectly interpreted as text:
CREATE TABLE #foo (id INT NOT NULL)
go
INSERT INTO #foo VALUES(1)
go
declare @P1 int
set @P1=NULL
exec sp_prepare @P1 output, N'@P1 text', N'SELECT id FROM #foo WHERE id
IN (SELECT id FROM #foo WHERE id = @P1)', 1
select @P1
go
Incorrect: N'@P1 text'
It should be: N'@P1 int'
Previous Comments:
[2007-08-31 07:35:18] [EMAIL PROTECTED]
Assigned to the maintainer.
[2007-08-31 07:33:12] [EMAIL PROTECTED]
Very nice that you didn't bother trying with the RCs..
[2007-08-30 16:20:54] travis at raybold dot com
the problem still occurs on:
PHP 5.2.4 (cli) (built: Aug 30 2007 07:06:31)
[2007-06-22 17:50:11] blohr at triad dot rr dot com
This bug affects my app, too. I'm using PHP 5.2.3 on Windows XP Pro
SP2, under both IIS 5.1 and Apache 2.2, with SQL Server 2005 Express.
I don't know if it'll help or not, but here's some more reproduce code.
Just fix the PDO DSN string to something valid.
?php
$db = new PDO(odbc:dsn=$odbcDsn;uid=$user;pwd=$pass);
$createTable =
'CREATE TABLE ##test (
intCol int,
textCol varchar(20)
)';
$createTable2 =
'CREATE TABLE ##test2 (
intCol2 int,
textCol2 varchar(20)
)';
$db-exec($createTable);
$db-exec($createTable2);
$ins = $db-prepare('INSERT INTO ##test (intCol, textCol) VALUES (:i,
:t)');
$ins-execute(array('i'=1, 't'='A String'));
$ins2 = $db-prepare('INSERT INTO ##test2 (intCol2, textCol2) VALUES
(:i, :t)');
$ins2-execute(array('i'=1, 't'='Another String'));
$sel = $db-prepare('SELECT * FROM ##test WHERE intCol = (SELECT
intCol2 FROM ##test2 WHERE textCol2 = :t)');
$sel-execute(array('t'='Another String')) or
var_dump($sel-errorInfo());
$sel = $db-prepare('SELECT * FROM ##test WHERE intCol = (SELECT
intCol2 FROM ##test2 WHERE intCol2 = :i)');
$sel-execute(array('i'=1)) or var_dump($sel-errorInfo());
$sel = $db-prepare('SELECT * FROM ##test WHERE intCol = (SELECT
intCol2 FROM ##test2 WHERE textCol2 = :t)');
$sel-bindValue('t', 'Another String');
$sel-execute() or var_dump($sel-errorInfo());
$sel = $db-prepare('SELECT * FROM ##test WHERE intCol = (SELECT
intCol2 FROM ##test2 WHERE intCol2 = :i)');
$sel-bindValue('i', 1);
$sel-execute() or var_dump($sel-errorInfo());
$sel = $db-prepare('SELECT * FROM ##test WHERE intCol = (SELECT
intCol2 FROM ##test2 WHERE textCol2 = :t)');
$sel-bindValue('t', 'Another String', PDO::PARAM_STR);
$sel-execute() or var_dump($sel-errorInfo());
$sel = $db-prepare('SELECT * FROM ##test WHERE intCol = (SELECT
intCol2 FROM ##test2 WHERE intCol2 = :i)');
$sel-bindValue('i', 1, PDO::PARAM_INT);
$sel-execute() or var_dump($sel-errorInfo());
$sel = $db-prepare('SELECT * FROM ##test WHERE intCol = (SELECT
intCol2 FROM ##test2 WHERE textCol2 = :t)');
$t = 'Another String';
$sel-bindParam('t', $t, PDO::PARAM_STR);
$sel-execute() or var_dump($sel-errorInfo());
$sel = $db-prepare('SELECT * FROM ##test WHERE intCol = (SELECT
intCol2 FROM ##test2 WHERE intCol2 = :i)');
$i = 1;
$sel-bindParam('i', $i, PDO::PARAM_INT);
$sel-execute() or var_dump($sel-errorInfo());
?
[2007-05-24 20:50:41] travis at raybold dot com
Hey Wez, I never saw the feedback til I stumbled on it today, and
clearly have been able to work around this, but it does keep stopping
me.
It happens exactly the same if I omit the PDO::PARAM_INT as
#43497 [Asn]: OCI8 XML/getClobVal leaks UGA memory
ID: 43497
User updated by: ghosh at q-one dot com
Reported By: ghosh at q-one dot com
Status: Assigned
Bug Type: OCI8 related
Operating System: Linux 2.6.22-14-server
PHP Version: 5.2.5
Assigned To: sixd
New Comment:
Temporary LOBs are created in UGA memory. This is per-session, so
the leak appears on a per-session basis. Nevertheless this is a
problem, because PHP scripts dont necessarily have to run for a few
seconds. PHP is a full-featured scripting language and can also be
used from the command-line or to implement longer-running
import-scripts. Even if not, the limit is quickly reached, when
reading many rows like in my example.
Previous Comments:
[2008-01-06 20:42:52] [EMAIL PROTECTED]
What I don't understand: I thought OCI_RETURN_LOBS is just a short-
cut for those who don't want to write:
That's what I don't understand either: does the leak appear only on
per-session basis or Oracle doesn't free those LOBs at all?
If the leak is only per-session, then users are not supposed even to
notice it, since PHP requests are not supposed to take more than several
seconds.
[2007-12-29 22:37:21] ghosh at q-one dot com
Really great! Thanks a lot!! This patch works. What I don't understand:
I thought OCI_RETURN_LOBS is just a short-cut for those who don't want
to write:
$s=$result[0]-load();
$result[0]-free();
$result[0]=$s;
If you use OCI_RETURN_LOBS you dont want to care about lobs but get the
result as a string and forget about lobs altogether. So IMHO this should
work as well. My specific problem is solved though.
[2007-12-27 21:44:07] [EMAIL PROTECTED]
This is really an issue with temporary LOBS since getClobVal()
returns a temporary LOB.
There are two parts to the fix: changing the script and patching
the OCI8 extension. Also don't forget to apply the patch for
http://bugs.php.net/bug.php?id=42496
Please test this suggestion and report any issues.
Thanks to Krishna Shankar for the solution.
1. Change the test to get the results as LOBs, not as
strings. This allows the script to free temporary LOBs.
In the supplied testcase change:
$query = select extract(xml, '/').getclobval() from ugatest;
$stmt = oci_parse($conn, $query);
if (oci_execute($stmt))
while ($result = oci_fetch_array($stmt,
OCI_NUM+OCI_RETURN_LOBS))
;
to:
$query = select extract(xml, '/').getclobval() from ugatest;
$stmt = oci_parse($conn, $query);
if (oci_execute($stmt))
while ($result = oci_fetch_array($stmt, OCI_NUM)) {
// echo $result[0]-load(), \n; // do something with the
XML
$result[0]-free(); // free the temporary LOB
}
The connection must be open when LOB-free() is called, as the
underlying OCILobFreeTemporary() call does a roundtrip to the
database.
2. Patch oci8_lob.c. The change copies some LOB freeing code
from php_oci_lob_close() into php_oci_lob_free():
--- oci8_lob.c.orig2007-07-31 12:21:08.0 -0700
+++ oci8_lob.c2007-12-27 12:33:19.0 -0800
@@ -647,6 +647,9 @@
Close LOB descriptor and free associated resources */
void php_oci_lob_free (php_oci_descriptor *descriptor TSRMLS_DC)
{
+#ifdef HAVE_OCI8_TEMP_LOB
+int is_temporary;
+#endif
if (!descriptor || !descriptor-connection) {
return;
@@ -662,6 +665,40 @@
php_oci_lob_flush(descriptor, OCI_LOB_BUFFER_FREE TSRMLS_CC);
}
+#ifdef HAVE_OCI8_TEMP_LOB
+if (descriptor-type == OCI_DTYPE_LOB) {
+PHP_OCI_CALL_RETURN(descriptor-connection-errcode,
+OCILobIsTemporary,
+(
+descriptor-connection-env,
+descriptor-connection-err,
+descriptor-descriptor,
+is_temporary
+ )
+);
+if (descriptor-connection-errcode != OCI_SUCCESS) {
+php_oci_error(descriptor-connection-err,
descriptor-connection-errcode TSRMLS_CC);
+PHP_OCI_HANDLE_ERROR(descriptor-connection,
descriptor-connection-errcode);
+return 1;
+}
+if (is_temporary) {
+PHP_OCI_CALL_RETURN(descriptor-connection-errcode,
+OCILobFreeTemporary,
+(
+descriptor-connection-svc,
+descriptor-connection-err,
+descriptor-descriptor
+ )
+);
+if (descriptor-connection-errcode != OCI_SUCCESS) {
+php_oci_error(descriptor-connection-err,
descriptor-connection-errcode TSRMLS_CC);
+PHP_OCI_HANDLE_ERROR(descriptor-connection,
descriptor-connection-errcode);
+return 1;
+}
+}
+
#43774 [NEW]: json_decode cause notices when called with non json data
From: marcin dot krzyzanowski at gmail dot com Operating system: Windows PHP version: 5.2.5 PHP Bug Type: JSON related Bug description: json_decode cause notices when called with non json data Description: I think that json_decode have problem with incorrect data passed as parameter; Reproduce code: --- $post = ; $data = json_decode($post); some other code here Expected result: empty $data or similar Actual result: -- for every line of code below (even if it's commented out) will show Notice: Trying to get property of non-object in file.php on line 54 Notice: Trying to get property of non-object in file.php on line 55 etc.. -- Edit bug report at http://bugs.php.net/?id=43774edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43774r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43774r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43774r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43774r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43774r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43774r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43774r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43774r=needscript Try newer version:http://bugs.php.net/fix.php?id=43774r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43774r=support Expected behavior:http://bugs.php.net/fix.php?id=43774r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43774r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43774r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43774r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43774r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43774r=dst IIS Stability:http://bugs.php.net/fix.php?id=43774r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43774r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43774r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43774r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43774r=mysqlcfg
#43775 [NEW]: PDO can't handle prepared SHOW TABLES statements
From: adrianamustdie at yahoo dot com Operating system: openSuSE 10.3 PHP version: 5.2.5 PHP Bug Type: PDO related Bug description: PDO can't handle prepared SHOW TABLES statements Description: a prepared statement used in a class. $this-mysql == mysql connection $database == name of the database Reproduce code: --- example #1 (work): $stmt = $this-mysql-prepare(SHOW TABLES FROM .$database); $stmt-execute(); example #2 (don't work): $stmt = $this-mysql-prepare(SHOW TABLES FROM ?); $stmt-execute(array($database)); Expected result: both examples should work! Actual result: -- error: 42000 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ''databasename'' at line 1 -- Edit bug report at http://bugs.php.net/?id=43775edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43775r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43775r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43775r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43775r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43775r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43775r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43775r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43775r=needscript Try newer version:http://bugs.php.net/fix.php?id=43775r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43775r=support Expected behavior:http://bugs.php.net/fix.php?id=43775r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43775r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43775r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43775r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43775r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43775r=dst IIS Stability:http://bugs.php.net/fix.php?id=43775r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43775r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43775r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43775r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43775r=mysqlcfg
#42625 [Com]: When mysql and mysqli enabled both together, php CLI hangs when ZTS is enabled
ID: 42625
Comment by: s dot s at terra dot com dot br
Reported By: jama at mk dot cvut dot cz
Status: Assigned
Bug Type: MySQL related
Operating System: Gentoo/Linux
PHP Version: 5.2.4
Assigned To: andrey
New Comment:
Same problem since PHP 5.2.3.
My site configuration:
Distro: Slackware Linux 11.0 (will upgrade to 12.0 soon)
# httpd -v
Server version: Apache/2.2.6 (Unix)
Server built: Dec 9 2007 18:54:29
# php -v
PHP 5.2.5 (cli) (built: Dec 9 2007 21:25:26)
Copyright (c) 1997-2007 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies
# /usr/local/mysql/bin/mysql_config --version
5.0.41
---
PHP and Apache was compiled by me.
MySQL is the default pre-compiled distribution from MySQL.com web
site.
Strace output on cli mode:
lstat64(/root, {st_mode=S_IFDIR|0710, st_size=1176, ...}) = 0
lstat64(/root/-, 0xbfcb65fc) = -1 ENOENT (No such file or
directory)
ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo
...}) = 0
fstat64(0, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb7fbe000
read(0, , 1024) = 0
close(0)= 0
munmap(0xb7fbe000, 4096)= 0
munmap(0xb7599000, 266240) = 0
mmap2(NULL, 266240, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0xb7599000
setitimer(ITIMER_PROF, {it_interval={0, 0}, it_value={0, 0}}, NULL) =
0
gettimeofday({1199684414, 364083}, NULL) = 0
gettimeofday({1199684414, 365349}, NULL) = 0
futex(0xb7f655c0, FUTEX_WAIT, 2, NULL unfinished ...
p.s. Why it searches for a file called - on the current directory???
(see second lstat64)
Previous Comments:
[2007-11-27 12:29:45] dirk at bean-it dot nl
Here I am again... :-)
Debian posted updated for mysql-5 and it libs today. Installing this
resolves my issue, I have a working php 5.2.5 now.
Non working debian mysql-5 version:
ii libmysqlclient15-dev 5.0.32-7etch1
ii libmysqlclient15off 5.0.32-7etch1
Working:
ii libmysqlclient15-dev5.0.32-7etch3
ii libmysqlclient15off 5.0.32-7etch3
Cheers,
Dirk
[2007-11-26 15:53:00] dirk at bean-it dot nl
I'll have to get back on my previous post, it also happens on i686 :-(
So, when I enable mysql mysqli, this results in a non working php.
(./configure --with-mysqli=/usr/bin/mysql_config --with-mysql=/usr)
Just enabling mysql or mysqli works fine.
(./configure --with-mysqli=/usr/bin/mysql_config) or (./configure
--with-mysql=/usr)
I've compared the mysql libs version on the i686 machines (one does
compile a good php, one doesn't) and they are the same.
[2007-11-21 19:47:12] dirk at bean-it dot nl
I'm experiencing the same problem, but my 2 cents tell me this is only
happening on amd64 + mysql + mysqli. My various i386 systems, build with
the same configure options have no problems at all. Leaving mysql or
mysqli option out results in a fine working php. Enabling them both
results in a broken php (ie, no prompt is returned in the cli, and the
apache modules works extremely crappy, since tons of new apaches are
started and they all hang).
The problem still exists in 5.2.5 and was not in there 5.2.3.
I run Debian 4.0 (x86_64 GNU/Linux) on all systems, with stock kernels
(2.6.18)
I'm happy to provide more info, if necessary. Or to post a new bug, if
you think this is more appropriate...
[2007-10-05 12:22:29] jama at mk dot cvut dot cz
I have updated mysql to:
mysql_config --version
5.1.22-rc
Downloaded new snapshots and new report seems OK for php..
./test.report.sh
php-5.2.4.log
OK php-5.2.4-mysqli ./configure --disable-all --enable-maintainer-zts
--with-mysqli=/usr/bin/mysql_config
OK php-5.2.4-mysqli-mysql ./configure --disable-all
--enable-maintainer-zts --with-mysql=/usr
--with-mysqli=/usr/bin/mysql_config
php5.2-200710051030.log
OK php5.2-200710051030-mysqli ./configure --disable-all
--enable-maintainer-zts --with-mysqli=/usr/bin/mysql_config
OK php5.2-200710051030-mysqli-mysql ./configure --disable-all
--enable-maintainer-zts --with-mysql=/usr
--with-mysqli=/usr/bin/mysql_config
php6.0-200710051030.log
OK php6.0-200710051030-mysqli ./configure --disable-all
--enable-maintainer-zts --with-mysqli=/usr/bin/mysql_config
OK php6.0-200710051030-mysqli-mysql ./configure --disable-all
--enable-maintainer-zts --with-mysql=/usr
--with-mysqli=/usr/bin/mysql_config
OK php6.0-200710051030-mysqli-mysqlng ./configure --disable-all
--enable-maintainer-zts --with-mysql=mysql --with-mysqli=mysqlnd
#42625 [Com]: When mysql and mysqli enabled both together, php CLI hangs when ZTS is enabled
ID: 42625
Comment by: s dot s at terra dot com dot br
Reported By: jama at mk dot cvut dot cz
Status: Assigned
Bug Type: MySQL related
Operating System: Gentoo/Linux
PHP Version: 5.2.4
Assigned To: andrey
New Comment:
It seems a pthread version bug. Checking with gdb the result is:
Starting program: /usr/bin/php
[Thread debugging using libthread_db enabled]
[New Thread -1218722112 (LWP 24212)]
[New Thread -1219249232 (LWP 24215)]
[Thread -1219249232 (zombie) exited]
Program received signal SIGINT, Interrupt.
[Switching to Thread -1218722112 (LWP 24212)]
0xb7708fd9 in __lll_mutex_lock_wait () from /lib/tls/libpthread.so.0
And a backtrace:
(gdb) bt
#0 0xb7708fd9 in __lll_mutex_lock_wait () from
/lib/tls/libpthread.so.0
#1 0xb7706a64 in _L_mutex_lock_22 () from /lib/tls/libpthread.so.0
#2 0xb7fadaa0 in _dl_runtime_resolve () from /lib/ld-linux.so.2
#3 0xb7da51a1 in my_thread_global_end ()
from /usr/local/mysql/lib/libmysqlclient_r.so.15
#4 0xb7da51a1 in my_thread_global_end ()
from /usr/local/mysql/lib/libmysqlclient_r.so.15
#5 0xb7da10b5 in my_end () from
/usr/local/mysql/lib/libmysqlclient_r.so.15
#6 0xb7d9a27e in mysql_server_end ()
from /usr/local/mysql/lib/libmysqlclient_r.so.15
#7 0x081817eb in zm_shutdown_mysqli (type=1, module_number=23,
tsrm_ls=0x8600050)
at /usr/src/network/web/php-5.2.5/ext/mysqli/mysqli.c:676
#8 0x083236fe in module_destructor (module=0x863e220)
at /usr/src/network/web/php-5.2.5/Zend/zend_API.c:1916
#9 0x08329519 in zend_hash_apply_deleter (ht=0x85ffb80, p=0x863e1f0)
at /usr/src/network/web/php-5.2.5/Zend/zend_hash.c:611
#10 0x083295d7 in zend_hash_graceful_reverse_destroy (ht=0x85ffb80)
at /usr/src/network/web/php-5.2.5/Zend/zend_hash.c:646
#11 0x0831e4dd in zend_shutdown (tsrm_ls=0x8600050)
at /usr/src/network/web/php-5.2.5/Zend/zend.c:733
#12 0x082db92e in php_module_shutdown (tsrm_ls=0x8600050)
at /usr/src/network/web/php-5.2.5/main/main.c:1887
---Type return to continue, or q return to quit---
#13 0x083986b9 in main (argc=1, argv=0xbfc5d364)
at /usr/src/network/web/php-5.2.5/sapi/cli/php_cli.c:1335
Previous Comments:
[2008-01-07 05:43:48] s dot s at terra dot com dot br
Same problem since PHP 5.2.3.
My site configuration:
Distro: Slackware Linux 11.0 (will upgrade to 12.0 soon)
# httpd -v
Server version: Apache/2.2.6 (Unix)
Server built: Dec 9 2007 18:54:29
# php -v
PHP 5.2.5 (cli) (built: Dec 9 2007 21:25:26)
Copyright (c) 1997-2007 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies
# /usr/local/mysql/bin/mysql_config --version
5.0.41
---
PHP and Apache was compiled by me.
MySQL is the default pre-compiled distribution from MySQL.com web
site.
Strace output on cli mode:
lstat64(/root, {st_mode=S_IFDIR|0710, st_size=1176, ...}) = 0
lstat64(/root/-, 0xbfcb65fc) = -1 ENOENT (No such file or
directory)
ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo
...}) = 0
fstat64(0, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb7fbe000
read(0, , 1024) = 0
close(0)= 0
munmap(0xb7fbe000, 4096)= 0
munmap(0xb7599000, 266240) = 0
mmap2(NULL, 266240, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0xb7599000
setitimer(ITIMER_PROF, {it_interval={0, 0}, it_value={0, 0}}, NULL) =
0
gettimeofday({1199684414, 364083}, NULL) = 0
gettimeofday({1199684414, 365349}, NULL) = 0
futex(0xb7f655c0, FUTEX_WAIT, 2, NULL unfinished ...
p.s. Why it searches for a file called - on the current directory???
(see second lstat64)
[2007-11-27 12:29:45] dirk at bean-it dot nl
Here I am again... :-)
Debian posted updated for mysql-5 and it libs today. Installing this
resolves my issue, I have a working php 5.2.5 now.
Non working debian mysql-5 version:
ii libmysqlclient15-dev 5.0.32-7etch1
ii libmysqlclient15off 5.0.32-7etch1
Working:
ii libmysqlclient15-dev5.0.32-7etch3
ii libmysqlclient15off 5.0.32-7etch3
Cheers,
Dirk
[2007-11-26 15:53:00] dirk at bean-it dot nl
I'll have to get back on my previous post, it also happens on i686 :-(
So, when I enable mysql mysqli, this results in a non working php.
(./configure --with-mysqli=/usr/bin/mysql_config --with-mysql=/usr)
Just enabling mysql or mysqli works fine.
(./configure --with-mysqli=/usr/bin/mysql_config) or (./configure
--with-mysql=/usr)
I've compared the mysql libs version on the i686 machines (one does
compile a good php, one doesn't) and they are the same.
#37201 [Com]: *** glibc detected *** corrupted double-linked list: 0x08fe6750 ***
ID: 37201 Comment by: jinglerobs at yahoo dot com Reported By: pascal at tweakers dot net Status: No Feedback Bug Type: *Compile Issues Operating System: Fedora 3 PHP Version: 4.4.2 New Comment: Trying to install Sun Java App Server on Fedora 6 drove me crazy with glibc error, the installation used to abort with glibc detected doubly linked list corruption. After much research and trying out all sorts of glibc packages, I read on google about heap correction checking through variable environment variable MALLOC_CHECK_ Its value should be one of 0 to ignore corruptions 1 to print to stderr(3) 2 to abort immediately What I immediately did is $ export MALLOC_CHECK_=0 and the installation of Sun Java App Server did not abort nxt time. Hope this work around has sme benefits !! Previous Comments: [2007-03-20 11:06:58] reasonably at gmx dot net Forgot to mention: I use Fedora Core 4, trying to compile PHP-4.4.6, have the --with-dom option in my configure.php The command I run is: pear upgrade --force PEAR-1.3.6 Archive_Tar-1.3.1 Console_Getopt-1.2 Running the command again, I now have: *** glibc detected *** /usr/local/bin/php: corrupted double-linked list: 0x0899d758 *** === Backtrace: = /lib/libc.so.6[0x25330c] /lib/libc.so.6(__libc_free+0x77)[0x25372b] /usr/local/bin/php(zend_hash_destroy+0x8a)[0x8198f86] /usr/local/bin/php(destroy_zend_class+0x77)[0x818f4cb] /usr/local/bin/php(zend_hash_destroy+0x3c)[0x8198f38] /usr/local/bin/php(zend_shutdown+0x51)[0x8195581] /usr/local/bin/php(php_module_shutdown+0x23)[0x816d717] /usr/local/bin/php(main+0x158)[0x81b0014] /lib/libc.so.6(__libc_start_main+0xdf)[0x204d7f] /usr/local/bin/php[0x807c631] [2007-03-20 10:56:59] reasonably at gmx dot net Hi, I received a similar error: *** glibc detected *** /usr/local/bin/php: corrupted double-linked list: 0x0a2cf758 *** Below the backtrace - hopefully this helps... === Backtrace: = /lib/libc.so.6[0x3d930c] /lib/libc.so.6(__libc_free+0x77)[0x3d972b] /usr/local/bin/php(zend_hash_destroy+0x8a)[0x8198f86] /usr/local/bin/php(destroy_zend_class+0x77)[0x818f4cb] /usr/local/bin/php(zend_hash_destroy+0x3c)[0x8198f38] /usr/local/bin/php(zend_shutdown+0x51)[0x8195581] /usr/local/bin/php(php_module_shutdown+0x23)[0x816d717] /usr/local/bin/php(main+0x158)[0x81b0014] /lib/libc.so.6(__libc_start_main+0xdf)[0x38ad7f] /usr/local/bin/php[0x807c631] === Memory map: 00111000-00112000 rwxp 00111000 00:00 0 00112000-0011b000 r-xp 09:01 108199 /lib/libnss_files-2.3.6.so 0011b000-0011c000 r-xp 8000 09:01 108199 /lib/libnss_files-2.3.6.so 0011c000-0011d000 rwxp 9000 09:01 108199 /lib/libnss_files-2.3.6.so 0011d000-00121000 r-xp 09:01 108275 /lib/libnss_dns-2.3.6.so 00121000-00122000 r-xp 3000 09:01 108275 /lib/libnss_dns-2.3.6.so 00122000-00123000 rwxp 4000 09:01 108275 /lib/libnss_dns-2.3.6.so 00123000-0015a000 r-xp 09:04 260176 /usr/local/lib/libpng.so.0.1.2.10 0015a000-0015b000 rwxp 00037000 09:04 260176 /usr/local/lib/libpng.so.0.1.2.10 0015b000-0015c000 rwxp 0015b000 00:00 0 0015c000-001a3000 r-xp 09:04 585173 /usr/lib/libgcrypt.so.11.2.0 001a3000-001a8000 rwxp 00047000 09:04 585173 /usr/lib/libgcrypt.so.11.2.0 001a8000-001ab000 r-xp 09:04 585414 /usr/lib/libgpg-error.so.0.1.3 001ab000-001ac000 rwxp 2000 09:04 585414 /usr/lib/libgpg-error.so.0.1.3 001ac000-001ba000 r-xp 09:01 108140 /lib/libpthread-2.3.6.so 001ba000-001bb000 r-xp d000 09:01 108140 /lib/libpthread-2.3.6.so 001bb000-001bc000 rwxp e000 09:01 108140 /lib/libpthread-2.3.6.so 001bc000-001be000 rwxp 001bc000 00:00 0 001be000-001d r-xp 09:04 260391 /usr/local/lib/libz.so.1.2.3 001d-001d1000 rwxp 00012000 09:04 260391 /usr/local/lib/libz.so.1.2.3 001d1000-001d2000 rwxp 001d1000 00:00 0 001d2000-001ec000 r-xp 09:01 108130 /lib/ld-2.3.6.so 001ec000-001ed000 r-xp 00019000 09:01 108130 /lib/ld-2.3.6.so 001ed000-001ee000 rwxp 0001a000 09:01 108130 /lib/ld-2.3.6.so 001ee000-00223000 r-xp 09:01 108227 /lib/libssl.so.0.9.7f 00223000-00226000 rwxp 00035000 09:01 108227 /lib/libssl.so.0.9.7f 00229000-0023 r-xs 09:04 647244 /usr/lib/gconv/gconv-modules.cache 00231000-00232000 rwxp 00231000 00:00 0 00242000-00253000 r-xp 09:01 108159 /lib/libnsl-2.3.6.so 00253000-00254000 r-xp 0001 09:01 108159 /lib/libnsl-2.3.6.so 00254000-00255000 rwxp 00011000 09:01 108159 /lib/libnsl-2.3.6.so 00255000-00257000 rwxp 00255000 00:00 0 0026-00298000 r-xp 09:04 260394 /usr/local/lib/libmhash.so.2.0.0 00298000-00299000 rwxp 00037000 09:04 260394 /usr/local/lib/libmhash.so.2.0.0
