#36256 [Opn->Bgs]: Call to undefined function socket_create()
ID: 36256 Updated by: [EMAIL PROTECTED] Reported By: motuzenko at gmail dot com -Status: Open +Status: Bogus Bug Type: Sockets related Operating System: xp pro PHP Version: 5.1.2 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. . Previous Comments: [2006-02-02 06:41:18] motuzenko at gmail dot com Description: Hello Got a problem with socket_create() function; The error I'm getting is: Call to undefined function socket_create() I've been through a lot of FAQs including php.net, nothing so far. All the solutions mentioned previously didn't help. I'm on PHP 5+Apache 2+MySQL 5 under XP pro. Script is needed to recieve port feed only. Please help. tyvm -- Edit this bug report at http://bugs.php.net/?id=36256&edit=1
#36256 [NEW]: Call to undefined function socket_create()
From: motuzenko at gmail dot com Operating system: xp pro PHP version: 5.1.2 PHP Bug Type: Sockets related Bug description: Call to undefined function socket_create() Description: Hello Got a problem with socket_create() function; The error I'm getting is: Call to undefined function socket_create() I've been through a lot of FAQs including php.net, nothing so far. All the solutions mentioned previously didn't help. I'm on PHP 5+Apache 2+MySQL 5 under XP pro. Script is needed to recieve port feed only. Please help. tyvm -- Edit bug report at http://bugs.php.net/?id=36256&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36256&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36256&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36256&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36256&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36256&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36256&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36256&r=needscript Try newer version:http://bugs.php.net/fix.php?id=36256&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36256&r=support Expected behavior:http://bugs.php.net/fix.php?id=36256&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36256&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36256&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36256&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36256&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36256&r=dst IIS Stability:http://bugs.php.net/fix.php?id=36256&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=36256&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=36256&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=36256&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=36256&r=mysqlcfg
#36255 [NEW]: fopen() does not work with batch files
From: tecklord at argocom dot cv dot ua Operating system: Windows PHP version: 4.4.2 PHP Bug Type: URL related Bug description: fopen() does not work with batch files Description: There is a problem in use of fopen() function in a batch file when requesting remote URI. It`s impossible to fetch any data via HTTP even if allow_url_fopen is set to On in php.ini. With local files fopen() seems to work correctly. Ex. C:\PHP\php.exe -c "F:\php.ini" -f "F:\test.php" C:\PHP>php.exe -v PHP 4.4.2 (cgi-fcgi) (built: Jan 13 2006 13:53:43) Copyright (c) 1997-2006 The PHP Group Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies the same code works correctly with F:\backup_php>php.exe -v PHP 4.4.0 (cgi-fcgi) (built: Jul 11 2005 16:13:04) Copyright (c) 1997-2004 The PHP Group Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies Reproduce code: --- $url = "http://www.google.com";; $fp = fopen($url, 'r'); if ($fp): echo "yes"; fclose($fp); else: echo "No"; endif; Expected result: "Yes" on the screen :) Actual result: -- There is no output at all, even with error_reporting = E_ALL in php.ini -- Edit bug report at http://bugs.php.net/?id=36255&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36255&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36255&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36255&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36255&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36255&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36255&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36255&r=needscript Try newer version:http://bugs.php.net/fix.php?id=36255&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36255&r=support Expected behavior:http://bugs.php.net/fix.php?id=36255&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36255&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36255&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36255&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36255&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36255&r=dst IIS Stability:http://bugs.php.net/fix.php?id=36255&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=36255&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=36255&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=36255&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=36255&r=mysqlcfg
#36158 [Asn]: SIGTERM is not handled correctly when running as a FastCGI server
ID: 36158
User updated by: chris at mysociety dot org
Reported By: chris at mysociety dot org
Status: Assigned
Bug Type: CGI related
Operating System: *
PHP Version: 5.1.2, 4.4.2
Assigned To: dmitry
New Comment:
Yeah, that's a fair point. Matters would be improved by adding the
FCGI_FAIL_ON_INTR flag to the call to FCGX_InitRequest; that's not a
complete solution, since that might cause the server process to quit on
receipt of another signal in the call to FCGX_Accept_r, but that's not a
very serious problem. Here's a patch that includes that change:
http://bitter.ukcod.org.uk/~chris/tmp/20060201/php-4.3.10-fastcgi-sigterm-fix.patch
Previous Comments:
[2006-02-01 18:20:43] stefan at luli dot de
Hi there,
I am struggeling with the described problem for quite some time now. I
have traced the problem now in the code back to
the SIGTERM play between fcgi_pm and php.
The question is if fcgi_pm should send a SIGTERM to the script even
though it processes a request at this momment. One would think that
fcgi_pm should be smart enough to deal with this situation (wait until
request is done/send no more requests/send SIGTERM). But apparently it
isn't.
The patch seams to do the trick, but is also prevents php to terminate
in case it's just idel. So php will sit there until the next request
comes in and terminate once the request is done before waiting for the
next request to come in. This should be solved.
[2006-01-26 08:58:25] [EMAIL PROTECTED]
Dmitry, does the new code fix this problem..?
[2006-01-26 01:55:15] chris at mysociety dot org
That snapshot (a) doesn't fix the problem -- the FastCGI code is
essentially unchanged since 4.x, though with a bunch of whitespace
noise; and (b) wouldn't help us in any case since it's PHP5 and our
applications are written for PHP4.
[2006-01-25 23:51:05] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
[2006-01-25 21:00:06] chris at mysociety dot org
Description:
When php is running as a FastCGI server, it should handle SIGTERM and
execute a graceful shutdown, because the mod_fastcgi process manager
uses this signal to shut down excess dynamic servers. "Graceful" in
this context means that the server must finish handling any outstanding
request and then terminate its connection to the web server. Presently,
PHP does not handle SIGTERM at all in the FastCGI request loop, so that
on receipt of SIGTERM, php aborts, even if half-way through a request.
This typically results in the web server logging "Incomplete headers (0
bytes) received", and returning "500 Internal Server Error" to the
client.
I have prepared a patch for this issue, here:
http://bitter.ukcod.org.uk/~chris/tmp/20060125/php-4.3.10-fastcgi-sigterm-fix.patch
-- this is against 4.3.10, but it applies to 4.4.2 fine.
Reproduce code:
---
Put the following in a .php file:
and set it up to run under FastCGI. Set up a script to request the page
in a loop ("while : ; do wget -O/dev/null -q http://path/to/script ;
done") Then kill the PHP process (pkill php will do this under Linux).
If you catch the script in the sleep, this will result in the client
getting a 500 and the web server logging a message about php failing,
as describe above.
Expected result:
No errors.
Actual result:
--
500 error.
--
Edit this bug report at http://bugs.php.net/?id=36158&edit=1
#36254 [Opn->Bgs]: wrong xor result
ID: 36254 Updated by: [EMAIL PROTECTED] Reported By: mail at young dot org dot ua -Status: Open +Status: Bogus Bug Type: Math related Operating System: 6.0-RELEASE-p4 PHP Version: 5.1.2 New Comment: Because bitwise operators work with integers and you're trying to use float/double values. Previous Comments: [2006-02-01 23:10:17] mail at young dot org dot ua Description: Part of php-code doesnt work correctly on the sigle servers, but working good at ~100 other servers. CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (3000.13-MHz 686-class CPU) Reproduce code: --- Expected result: float(-5883499359) int(177392) int(-1588438959) Actual result: -- float(-5883499359) int(177392) int(-2147306256) -- Edit this bug report at http://bugs.php.net/?id=36254&edit=1
#36254 [NEW]: wrong xor result
From: mail at young dot org dot ua Operating system: 6.0-RELEASE-p4 PHP version: 5.1.2 PHP Bug Type: Math related Bug description: wrong xor result Description: Part of php-code doesnt work correctly on the sigle servers, but working good at ~100 other servers. CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (3000.13-MHz 686-class CPU) Reproduce code: --- Expected result: float(-5883499359) int(177392) int(-1588438959) Actual result: -- float(-5883499359) int(177392) int(-2147306256) -- Edit bug report at http://bugs.php.net/?id=36254&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36254&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36254&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36254&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36254&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36254&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36254&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36254&r=needscript Try newer version:http://bugs.php.net/fix.php?id=36254&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36254&r=support Expected behavior:http://bugs.php.net/fix.php?id=36254&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36254&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36254&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36254&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36254&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36254&r=dst IIS Stability:http://bugs.php.net/fix.php?id=36254&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=36254&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=36254&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=36254&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=36254&r=mysqlcfg
#36251 [Opn->Bgs]: Re: Include not working problem
ID: 36251 Updated by: [EMAIL PROTECTED] Reported By: john at castlecomm dot com -Status: Open +Status: Bogus Bug Type: Unknown/Other Function Operating System: Unix/Linux PHP Version: 4.4.2 New Comment: Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Thank you for your interest in PHP. Duplicate of #36249 Previous Comments: [2006-02-01 20:57:56] john at castlecomm dot com Description: Tony, I tried to reply to the original ticket but your system is not remembering my password, 's00per' correctly. I am certain I used that, because I pasted it in from notepad after saving it in a file with no newlines. Thank you for your help, but if your answer is correct, then my scripts should have worked. You said: "Files for including are first looked in include_path relative to the current working directory and then in include_path relative to the directory of current script." The current working directory and script in my example was (PROTECTED) I appended to the include_path ./ws This means that the include_once '../inc/incfile.php' which happened inside of ws/wsfile.php should have been looked at from the perspective of (PROTECTED)/ws at least once but it wasn't. Did you look at the examples I provided you? --Original Message-- Including a file using a relative path after INI SETTING the include_path does not work. Setting the include_path works, but but PHP does not use it correctly. This is a major flaw in the include logic. A full detailed example is listed under the "Reproduce code" section. Reproduce code: --- [john@(PROTECTED) error]$ cat mainfile.php [john@(PROTECTED) error]$ cat ws/wsfile.php [john@(PROTECTED) error]$ cat inc/incfile.php [john@(PROTECTED) error]$ php mainfile.php Warning: main(../inc/incfile.php): failed to open stream: No such file or directory in /(PROTECTED)/john/error/ws/wsfile.php on line 2 Warning: main(): Failed opening '../inc/incfile.php' for inclusion (include_path='.:/usr/local/lib/php:./ws:') in /(PROTECTED)/john/error/ws/wsfile.php on line 2 Hi! I'm wsfile! Hi! I'm mainfile! Expected result: Tony, Thank you for your help, but if your answer is correct, then my scripts should have worked. You said: "Files for including are first looked in include_path relative to the current working directory and then in include_path relative to the directory of current script." The current working directory and script in my example was (PROTECTED) I appended to the include_path ./ws This means that the include_once '../inc/incfile.php' which happened inside of ws/wsfile.php should have been looked at from the perspective of (PROTECTED)/ws at least once but it wasn't. Did you look at the examples I provided you? --Original Expected Result-- The INI SET works, but include_once, as well as the others, do not work correctly. It can't find the relatively included file...even though the INI include_path is set. The code should work because the include path has been set properly. Even the error output shows the right include path, but the include_once directive just fails. Actual result: -- [john@(PROTECTED) error]$ php mainfile.php Warning: main(../inc/incfile.php): failed to open stream: No such file or directory in /(PROTECTED)/john/error/ws/wsfile.php on line 2 Warning: main(): Failed opening '../inc/incfile.php' for inclusion (include_path='.:/usr/local/lib/php:./ws:') in /(PROTECTED)/john/error/ws/wsfile.php on line 2 Hi! I'm wsfile! Hi! I'm mainfile! -- Edit this bug report at http://bugs.php.net/?id=36251&edit=1
#36253 [Opn->Fbk]: Can't talk to MSSQL2005 database
ID: 36253 Updated by: [EMAIL PROTECTED] Reported By: harry dot hambrick at geac dot com -Status: Open +Status: Feedback Bug Type: MSSQL related Operating System: windows 2000 PHP Version: 4.4.2 New Comment: Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. Previous Comments: [2006-02-01 22:10:22] harry dot hambrick at geac dot com Description: I have a web page that accesses a SQL 2000 database and works fine. If I try to connect to a SQL 2005 database, no data is returned. I can connect but nothing comes back from queries. -- Edit this bug report at http://bugs.php.net/?id=36253&edit=1
#36253 [NEW]: Can't talk to MSSQL2005 database
From: harry dot hambrick at geac dot com Operating system: windows 2000 PHP version: 4.4.2 PHP Bug Type: MSSQL related Bug description: Can't talk to MSSQL2005 database Description: I have a web page that accesses a SQL 2000 database and works fine. If I try to connect to a SQL 2005 database, no data is returned. I can connect but nothing comes back from queries. -- Edit bug report at http://bugs.php.net/?id=36253&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36253&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36253&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36253&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36253&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36253&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36253&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36253&r=needscript Try newer version:http://bugs.php.net/fix.php?id=36253&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36253&r=support Expected behavior:http://bugs.php.net/fix.php?id=36253&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36253&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36253&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36253&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36253&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36253&r=dst IIS Stability:http://bugs.php.net/fix.php?id=36253&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=36253&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=36253&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=36253&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=36253&r=mysqlcfg
#36244 [Opn]: Importing xsl:output breaks encoding attribute value
ID: 36244
User updated by: maximgb at is-a dot ru
Reported By: maximgb at is-a dot ru
Status: Open
Bug Type: XSLT related
Operating System: windows xp sp2
PHP Version: 5.1.2
New Comment:
In the bug2.xsl in bug message attribute should be some text in
windows-1251 encoding. In previous comment it was encoded by bug
tracker posting system.
Previous Comments:
[2006-02-01 21:51:49] maximgb at is-a dot ru
bug.php
---
load("bugsrc.xml");
$transform = new DOMDocument();
$transform->load('bug2.xsl');
$xslt = new XSLTProcessor();
$xslt->importStyleSheet($transform);
file_put_contents("bugdest.xml", $xslt->transformToXML($source));
?>
bugsrc.xml
--
bug1.xsl
http://www.w3.org/1999/XSL/Transform";>
bug2.xsl
http://www.w3.org/1999/XSL/Transform";>
[2006-02-01 11:16:54] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.
[2006-02-01 11:14:41] maximgb at is-a dot ru
Description:
I have two stylesheets first one with xsl:output tag only, where
method="XML" and encoding="windows-1251", second one which imports the
first one and where all other templates are stored. When I use
then all russian characters after
transformation become XML entities, when I use
--
Edit this bug report at http://bugs.php.net/?id=36244&edit=1
#36244 [Fbk->Opn]: Importing xsl:output breaks encoding attribute value
ID: 36244
User updated by: maximgb at is-a dot ru
Reported By: maximgb at is-a dot ru
-Status: Feedback
+Status: Open
Bug Type: XSLT related
Operating System: windows xp sp2
PHP Version: 5.1.2
New Comment:
bug.php
---
load("bugsrc.xml");
$transform = new DOMDocument();
$transform->load('bug2.xsl');
$xslt = new XSLTProcessor();
$xslt->importStyleSheet($transform);
file_put_contents("bugdest.xml", $xslt->transformToXML($source));
?>
bugsrc.xml
--
bug1.xsl
http://www.w3.org/1999/XSL/Transform";>
bug2.xsl
http://www.w3.org/1999/XSL/Transform";>
Previous Comments:
[2006-02-01 11:16:54] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.
[2006-02-01 11:14:41] maximgb at is-a dot ru
Description:
I have two stylesheets first one with xsl:output tag only, where
method="XML" and encoding="windows-1251", second one which imports the
first one and where all other templates are stored. When I use
then all russian characters after
transformation become XML entities, when I use
--
Edit this bug report at http://bugs.php.net/?id=36244&edit=1
#36248 [Opn->Fbk]: CURLOPT_HEADERFUNCTION, couldn't set the function in the class
ID: 36248
Updated by: [EMAIL PROTECTED]
Reported By: Admin at relax-info dot com
-Status: Open
+Status: Feedback
Bug Type: cURL related
Operating System: WIN XP SP2
PHP Version: 4.4.2
New Comment:
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32
Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.
Works perfectly fine here.
Previous Comments:
[2006-02-01 17:55:12] Admin at relax-info dot com
I am truncate all comment from my class and delete other method than
not assign with problem
url = $url;
}
function init()
{
$this->_ch = curl_init();
// ...
}
function execute()
{
// defauukt setup
curl_setopt($this->_ch, CURLOPT_URL, $this->url);
// HEADER
if ($this->header)
{
curl_setopt($this->_ch, CURLOPT_HEADER, true);
curl_setopt($this->_ch, CURLOPT_HEADERFUNCTION,
array($this,
'_header_callback');
}
// exec
$result = curl_exec($this->_ch);
// ..
return $result;
}
function _header_callback($ch, $header)
{
return strlen($header);
}
}
// EXAMPLE -
$url = 'http://www.relax-info.com';
$curl = new CURL($url);
if ($curl->init())
{
$curl->returntransfer = true;
$curl->header = true;
$result = $curl->execute();
print_r($result);
}
else echo $curl->get_error();
?>
[2006-02-01 17:43:05] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.
[2006-02-01 17:40:49] Admin at relax-info dot com
Sorry, callback function example...
function _header_callback($ch, $header)
{
// print_r($header);
}
[2006-02-01 17:39:51] Admin at relax-info dot com
Description:
Couldn't set the name of a callback function where the callback
function exists in a class, array($this, 'callback_function'). Apache
die ...
Reproduce code:
---
class CURL
{
var $_ch;
.
$this->_ch = curl_init();
..
curl_setopt($this->_ch, CURLOPT_HEADERFUNCTION, array($this,
'_header_callback'));
..
}
Expected result:
The name of a callback function can be method of class
array($this, 'callback_function')
Actual result:
--
Apache die ...
--
Edit this bug report at http://bugs.php.net/?id=36248&edit=1
#36251 [NEW]: Re: Include not working problem
From: john at castlecomm dot com Operating system: Unix/Linux PHP version: 4.4.2 PHP Bug Type: Reproducible crash Bug description: Re: Include not working problem Description: Tony, I tried to reply to the original ticket but your system is not remembering my password, 's00per' correctly. I am certain I used that, because I pasted it in from notepad after saving it in a file with no newlines. Thank you for your help, but if your answer is correct, then my scripts should have worked. You said: "Files for including are first looked in include_path relative to the current working directory and then in include_path relative to the directory of current script." The current working directory and script in my example was (PROTECTED) I appended to the include_path ./ws This means that the include_once '../inc/incfile.php' which happened inside of ws/wsfile.php should have been looked at from the perspective of (PROTECTED)/ws at least once but it wasn't. Did you look at the examples I provided you? --Original Message-- Including a file using a relative path after INI SETTING the include_path does not work. Setting the include_path works, but but PHP does not use it correctly. This is a major flaw in the include logic. A full detailed example is listed under the "Reproduce code" section. Reproduce code: --- [john@(PROTECTED) error]$ cat mainfile.php [john@(PROTECTED) error]$ cat ws/wsfile.php [john@(PROTECTED) error]$ cat inc/incfile.php [john@(PROTECTED) error]$ php mainfile.php Warning: main(../inc/incfile.php): failed to open stream: No such file or directory in /(PROTECTED)/john/error/ws/wsfile.php on line 2 Warning: main(): Failed opening '../inc/incfile.php' for inclusion (include_path='.:/usr/local/lib/php:./ws:') in /(PROTECTED)/john/error/ws/wsfile.php on line 2 Hi! I'm wsfile! Hi! I'm mainfile! Expected result: Tony, Thank you for your help, but if your answer is correct, then my scripts should have worked. You said: "Files for including are first looked in include_path relative to the current working directory and then in include_path relative to the directory of current script." The current working directory and script in my example was (PROTECTED) I appended to the include_path ./ws This means that the include_once '../inc/incfile.php' which happened inside of ws/wsfile.php should have been looked at from the perspective of (PROTECTED)/ws at least once but it wasn't. Did you look at the examples I provided you? --Original Expected Result-- The INI SET works, but include_once, as well as the others, do not work correctly. It can't find the relatively included file...even though the INI include_path is set. The code should work because the include path has been set properly. Even the error output shows the right include path, but the include_once directive just fails. Actual result: -- [john@(PROTECTED) error]$ php mainfile.php Warning: main(../inc/incfile.php): failed to open stream: No such file or directory in /(PROTECTED)/john/error/ws/wsfile.php on line 2 Warning: main(): Failed opening '../inc/incfile.php' for inclusion (include_path='.:/usr/local/lib/php:./ws:') in /(PROTECTED)/john/error/ws/wsfile.php on line 2 Hi! I'm wsfile! Hi! I'm mainfile! -- Edit bug report at http://bugs.php.net/?id=36251&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36251&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36251&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36251&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36251&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36251&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36251&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36251&r=needscript Try newer version:http://bugs.php.net/fix.php?id=36251&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36251&r=support Expected behavior:http://bugs.php.net/fix.php?id=36251&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36251&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36251&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36251&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36251&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36251&r=dst IIS Stability:http://bugs.php.net/fix.php?id=36251&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=36251&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=36251&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=36251&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=36251&r=mysql
#36246 [Opn->Fbk]: Memory problem (double free)
ID: 36246 Updated by: [EMAIL PROTECTED] Reported By: eustaquiorangel at yahoo dot com -Status: Open +Status: Feedback Bug Type: XSLT related Operating System: Linux, Slackware 10.2 (current) PHP Version: 5.1.2 New Comment: Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. Previous Comments: [2006-02-01 20:13:01] eustaquiorangel at yahoo dot com > We can't reproduce it, so you tell us. Too many variables there, but definitely something is different from 5.1.1 to 5.1.2. To reproduce it the way we have here you'll need the exactly the same environment, but this is a complicated matter. OS, Apache version, all the scripts needed to run our environment. As I'm trying to make this works since before yesterday, I can't wait more to put the computer to work. I'll stick with 5.1.1 (ooofs, it's working fine) and if on the next upgrade (I'll skip 5.1.2 for sure! ;-) it happens again I'll open a bug report again, hopefuly with more time available to spend to check it. You can close this report. Btw, I understand that reproduce the problem helps a lot, but since it's my first bug report here, I'm curious: thinking about all the scripts installed on all over the world, how can you dig more into this kind of thing without having the same enviroment? [2006-02-01 19:34:47] [EMAIL PROTECTED] >Maybe a problem on the database code and not on XSLT (that >seems to works ok isolated)? We can't reproduce it, so you tell us. [2006-02-01 18:20:49] eustaquiorangel at yahoo dot com On CLI it seems that is not a problem. I run it 10 times and no error message. And using the web server seems that it's not a problem too, *** till *** (and I saw this now) I opened a script which gives me acess to our local intranet and it uses a simple database connection. Then the message is shown! I just saw that because I was testing on the CLI, on the "pure" webserver script and then I connect to get my report, and, voila, the error message is there. Maybe a problem on the database code and not on XSLT (that seems to works ok isolated)? Or maybe both? XSLT could put some junk on the memory and the database stuff just gives the error? Wow. I'm using Oracle Instant Client here. And, again, no error with any of those stuff on 5.1.1. [2006-02-01 17:30:34] [EMAIL PROTECTED] Can you get a backtrace? It's working fine for me on both win and linux boxes. does it crash under cli too? [2006-02-01 17:24:14] eustaquiorangel at yahoo dot com No way to avoid it with 5.1.1 +. :-( I downloaded the snapshot you told me, installed (phpversion() gives me "5.1.3-dev") and when running the sample, it shows me again the error_log message: *** glibc detected *** double free or corruption (fasttop): 0x082392a0 *** [Wed Feb 01 14:10:20 2006] [notice] child pid 11636 exit signal Aborted (6) I'm checking http://www.php.net/ChangeLog-5.php and seems that on the Windows version there were some changes: # Updated to libxml2-2.6.22 and libxslt-1.1.15 in the win32 bundle. (Rob) It's exactly the same versions I'm running here on Linux. And there were some little stuff like # Added constants for libxslt and libexslt versions: LIBXSLT_VERSION, LIBXSLT_DOTTED_VERSION, LIBEXSLT_VERSION and LIBEXSLT_DOTTED_VERSION. (Pierre) that would not affect this way the behaviour. I did some diffs with the ext/xsl 5.1.1 and 5.1.2 files but didn't find some relevant changes, just comment changes. Now I downgraded again to 5.1.1 and it's working fine again, no errors. Could you test the code on a Linux computer? 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/36246 -- Edit this bug report at http://bugs.php.net/?id=36246&edit=1
#36246 [Fbk->Opn]: Memory problem (double free)
ID: 36246 User updated by: eustaquiorangel at yahoo dot com Reported By: eustaquiorangel at yahoo dot com -Status: Feedback +Status: Open Bug Type: XSLT related Operating System: Linux, Slackware 10.2 (current) PHP Version: 5.1.2 New Comment: > We can't reproduce it, so you tell us. Too many variables there, but definitely something is different from 5.1.1 to 5.1.2. To reproduce it the way we have here you'll need the exactly the same environment, but this is a complicated matter. OS, Apache version, all the scripts needed to run our environment. As I'm trying to make this works since before yesterday, I can't wait more to put the computer to work. I'll stick with 5.1.1 (ooofs, it's working fine) and if on the next upgrade (I'll skip 5.1.2 for sure! ;-) it happens again I'll open a bug report again, hopefuly with more time available to spend to check it. You can close this report. Btw, I understand that reproduce the problem helps a lot, but since it's my first bug report here, I'm curious: thinking about all the scripts installed on all over the world, how can you dig more into this kind of thing without having the same enviroment? Previous Comments: [2006-02-01 19:34:47] [EMAIL PROTECTED] >Maybe a problem on the database code and not on XSLT (that >seems to works ok isolated)? We can't reproduce it, so you tell us. [2006-02-01 18:20:49] eustaquiorangel at yahoo dot com On CLI it seems that is not a problem. I run it 10 times and no error message. And using the web server seems that it's not a problem too, *** till *** (and I saw this now) I opened a script which gives me acess to our local intranet and it uses a simple database connection. Then the message is shown! I just saw that because I was testing on the CLI, on the "pure" webserver script and then I connect to get my report, and, voila, the error message is there. Maybe a problem on the database code and not on XSLT (that seems to works ok isolated)? Or maybe both? XSLT could put some junk on the memory and the database stuff just gives the error? Wow. I'm using Oracle Instant Client here. And, again, no error with any of those stuff on 5.1.1. [2006-02-01 17:30:34] [EMAIL PROTECTED] Can you get a backtrace? It's working fine for me on both win and linux boxes. does it crash under cli too? [2006-02-01 17:24:14] eustaquiorangel at yahoo dot com No way to avoid it with 5.1.1 +. :-( I downloaded the snapshot you told me, installed (phpversion() gives me "5.1.3-dev") and when running the sample, it shows me again the error_log message: *** glibc detected *** double free or corruption (fasttop): 0x082392a0 *** [Wed Feb 01 14:10:20 2006] [notice] child pid 11636 exit signal Aborted (6) I'm checking http://www.php.net/ChangeLog-5.php and seems that on the Windows version there were some changes: # Updated to libxml2-2.6.22 and libxslt-1.1.15 in the win32 bundle. (Rob) It's exactly the same versions I'm running here on Linux. And there were some little stuff like # Added constants for libxslt and libexslt versions: LIBXSLT_VERSION, LIBXSLT_DOTTED_VERSION, LIBEXSLT_VERSION and LIBEXSLT_DOTTED_VERSION. (Pierre) that would not affect this way the behaviour. I did some diffs with the ext/xsl 5.1.1 and 5.1.2 files but didn't find some relevant changes, just comment changes. Now I downgraded again to 5.1.1 and it's working fine again, no errors. Could you test the code on a Linux computer? [2006-02-01 16:19:43] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip Works fine here. 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/36246 -- Edit this bug report at http://bugs.php.net/?id=36246&edit=1
#36250 [NEW]: PHP Causes ORA-07445 Core dump in Oracle server 9.2.x
From: fred dot cohen at iridium dot com Operating system: Solaris 9 PHP version: 5.1.2 PHP Bug Type: OCI8 related Bug description: PHP Causes ORA-07445 Core dump in Oracle server 9.2.x Description: This isn't a bug in PHP, but I'm submitting it since Oracle currently has no patch available and it's cause isn't obvious. Using the Instant Client 10.2 and PHP 5.1.2 connecting to Oracle 9.2.0.7 we began seeing ORA-07445 errors immediately after upgrading to the versions listed. They may appear to occur intermittently, but they can happen as frequently as the oci8.ping_interval value. I've traced it down to the OCIPing call in the oci extension. It turns out any calls to OCIPing cause the error in the server. Workaround: In php.ini [oci8] section, set: oci8.ping_interval=-1 I'll provide updates about possible patches from Oracle as soon as they're able to respond. -- Edit bug report at http://bugs.php.net/?id=36250&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36250&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36250&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36250&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36250&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36250&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36250&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36250&r=needscript Try newer version:http://bugs.php.net/fix.php?id=36250&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36250&r=support Expected behavior:http://bugs.php.net/fix.php?id=36250&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36250&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36250&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36250&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36250&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36250&r=dst IIS Stability:http://bugs.php.net/fix.php?id=36250&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=36250&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=36250&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=36250&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=36250&r=mysqlcfg
#36249 [Opn->Bgs]: Include and Require do not work properly after ini_set include_path
ID: 36249 Updated by: [EMAIL PROTECTED] Reported By: john at castlecomm dot com -Status: Open +Status: Bogus Bug Type: Unknown/Other Function Operating System: ALL PHP Version: 4.4.2 New Comment: http://php.net/include "Files for including are first looked in include_path relative to the current working directory and then in include_path relative to the directory of current script. E.g. if your include_path is ., current working directory is /www/, you included include/a.php and there is include "b.php" in that file, b.php is first looked in /www/ and then in /www/include/. If filename begins with ./ or ../, it is looked only in include_path relative to the current working directory." Previous Comments: [2006-02-01 18:13:15] john at castlecomm dot com Description: Including a file using a relative path after INI SETTING the include_path does not work. Setting the include_path works, but but PHP does not use it correctly. This is a major flaw in the include logic. A full detailed example is listed under the "Reproduce code" section. Please fix this as soon as possible, as it is having drastic negative affects on my software with your latest version. Also, your "CAPTCHA" picture needs to be larger...the "R" in my code gets cut off and goes off the screen. I could barely make it out. Reproduce code: --- [john@(PROTECTED) error]$ cat mainfile.php [john@(PROTECTED) error]$ cat ws/wsfile.php [john@(PROTECTED) error]$ cat inc/incfile.php [john@(PROTECTED) error]$ php mainfile.php Warning: main(../inc/incfile.php): failed to open stream: No such file or directory in /(PROTECTED)/john/error/ws/wsfile.php on line 2 Warning: main(): Failed opening '../inc/incfile.php' for inclusion (include_path='.:/usr/local/lib/php:./ws:') in /(PROTECTED)/john/error/ws/wsfile.php on line 2 Hi! I'm wsfile! Hi! I'm mainfile! Expected result: The INI SET works, but include_once, as well as the others, do not work correctly. It can't find the relatively included file...even though the INI include_path is set. The code should work because the include path has been set properly. Even the error output shows the right include path, but the include_once directive just fails. This is a major error and is having really bad results on my software. Please fix this asap! Actual result: -- [john@(PROTECTED) error]$ php mainfile.php Warning: main(../inc/incfile.php): failed to open stream: No such file or directory in /(PROTECTED)/john/error/ws/wsfile.php on line 2 Warning: main(): Failed opening '../inc/incfile.php' for inclusion (include_path='.:/usr/local/lib/php:./ws:') in /(PROTECTED)/john/error/ws/wsfile.php on line 2 Hi! I'm wsfile! Hi! I'm mainfile! -- Edit this bug report at http://bugs.php.net/?id=36249&edit=1
#36246 [Opn->Fbk]: Memory problem (double free)
ID: 36246 Updated by: [EMAIL PROTECTED] Reported By: eustaquiorangel at yahoo dot com -Status: Open +Status: Feedback Bug Type: XSLT related Operating System: Linux, Slackware 10.2 (current) PHP Version: 5.1.2 New Comment: >Maybe a problem on the database code and not on XSLT (that >seems to works ok isolated)? We can't reproduce it, so you tell us. Previous Comments: [2006-02-01 18:20:49] eustaquiorangel at yahoo dot com On CLI it seems that is not a problem. I run it 10 times and no error message. And using the web server seems that it's not a problem too, *** till *** (and I saw this now) I opened a script which gives me acess to our local intranet and it uses a simple database connection. Then the message is shown! I just saw that because I was testing on the CLI, on the "pure" webserver script and then I connect to get my report, and, voila, the error message is there. Maybe a problem on the database code and not on XSLT (that seems to works ok isolated)? Or maybe both? XSLT could put some junk on the memory and the database stuff just gives the error? Wow. I'm using Oracle Instant Client here. And, again, no error with any of those stuff on 5.1.1. [2006-02-01 17:30:34] [EMAIL PROTECTED] Can you get a backtrace? It's working fine for me on both win and linux boxes. does it crash under cli too? [2006-02-01 17:24:14] eustaquiorangel at yahoo dot com No way to avoid it with 5.1.1 +. :-( I downloaded the snapshot you told me, installed (phpversion() gives me "5.1.3-dev") and when running the sample, it shows me again the error_log message: *** glibc detected *** double free or corruption (fasttop): 0x082392a0 *** [Wed Feb 01 14:10:20 2006] [notice] child pid 11636 exit signal Aborted (6) I'm checking http://www.php.net/ChangeLog-5.php and seems that on the Windows version there were some changes: # Updated to libxml2-2.6.22 and libxslt-1.1.15 in the win32 bundle. (Rob) It's exactly the same versions I'm running here on Linux. And there were some little stuff like # Added constants for libxslt and libexslt versions: LIBXSLT_VERSION, LIBXSLT_DOTTED_VERSION, LIBEXSLT_VERSION and LIBEXSLT_DOTTED_VERSION. (Pierre) that would not affect this way the behaviour. I did some diffs with the ext/xsl 5.1.1 and 5.1.2 files but didn't find some relevant changes, just comment changes. Now I downgraded again to 5.1.1 and it's working fine again, no errors. Could you test the code on a Linux computer? [2006-02-01 16:19:43] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip Works fine here. [2006-02-01 14:05:47] eustaquiorangel at yahoo dot com The test.xsl code is also there on the URL, on the end of the PHP code. One interesting thing: I installed right now PHP 5.1.1, and it's working fine! Not so fast as PHP5 (the same speed as PHP4), but no more double frees. 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/36246 -- Edit this bug report at http://bugs.php.net/?id=36246&edit=1
#35737 [Com]: undefined symbol: sqlite3SelectDelete
ID: 35737 Comment by: kpankratz at gmail dot com Reported By: jphml at videotron dot ca Status: No Feedback Bug Type: SQLite related Operating System: Linux PHP Version: 5.1.1 New Comment: installing Tcl-devel package did not solve the problem. Using --with-zlib removed the sqlite errors. The next module in the list now produces the error. ldd -d libphp5.so shows most of the modules as an undefined symbol. PHP 5.1.2 source files, Apache 2.2.0 source files, OS = SLES 9 SP3 Previous Comments: [2006-01-28 23:08:34] vano at kolumbus dot fi Try to install Tcl-devel package, because sqlite needs it. Then recompile php. OR Re-configure pdo_sqlite/sqlite with "--disable-tcl" option (because it is actually not needed for building the lirary). Then recompile php. [2006-01-11 03:54:23] george at gmarcotte dot com http://snaps.php.net/php5.1-latest.tar.gz has no effect still get the error: httpd: Syntax error on line 53 of /usr/local/apache2/conf/httpd.conf: Cannot load /usr/local/apache2/modules/libphp5.so into server: /usr/local/apache2/modules/libphp5.so: undefined symbol: sqlite3SelectDelete when I try to start the webserver. What is sqlite3SelectDelete? is there some header files missing? [2006-01-05 11:23:24] james at e0ts dot com Same with Debian 3.1 [2006-01-04 19:23:21] esesen at o2 dot pl exactly the same problem under slackware 10.2 [2006-01-01 01:00:07] 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". 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/35737 -- Edit this bug report at http://bugs.php.net/?id=35737&edit=1
#36246 [Fbk->Opn]: Memory problem (double free)
ID: 36246 User updated by: eustaquiorangel at yahoo dot com Reported By: eustaquiorangel at yahoo dot com -Status: Feedback +Status: Open Bug Type: XSLT related Operating System: Linux, Slackware 10.2 (current) PHP Version: 5.1.2 New Comment: On CLI it seems that is not a problem. I run it 10 times and no error message. And using the web server seems that it's not a problem too, *** till *** (and I saw this now) I opened a script which gives me acess to our local intranet and it uses a simple database connection. Then the message is shown! I just saw that because I was testing on the CLI, on the "pure" webserver script and then I connect to get my report, and, voila, the error message is there. Maybe a problem on the database code and not on XSLT (that seems to works ok isolated)? Or maybe both? XSLT could put some junk on the memory and the database stuff just gives the error? Wow. I'm using Oracle Instant Client here. And, again, no error with any of those stuff on 5.1.1. Previous Comments: [2006-02-01 17:30:34] [EMAIL PROTECTED] Can you get a backtrace? It's working fine for me on both win and linux boxes. does it crash under cli too? [2006-02-01 17:24:14] eustaquiorangel at yahoo dot com No way to avoid it with 5.1.1 +. :-( I downloaded the snapshot you told me, installed (phpversion() gives me "5.1.3-dev") and when running the sample, it shows me again the error_log message: *** glibc detected *** double free or corruption (fasttop): 0x082392a0 *** [Wed Feb 01 14:10:20 2006] [notice] child pid 11636 exit signal Aborted (6) I'm checking http://www.php.net/ChangeLog-5.php and seems that on the Windows version there were some changes: # Updated to libxml2-2.6.22 and libxslt-1.1.15 in the win32 bundle. (Rob) It's exactly the same versions I'm running here on Linux. And there were some little stuff like # Added constants for libxslt and libexslt versions: LIBXSLT_VERSION, LIBXSLT_DOTTED_VERSION, LIBEXSLT_VERSION and LIBEXSLT_DOTTED_VERSION. (Pierre) that would not affect this way the behaviour. I did some diffs with the ext/xsl 5.1.1 and 5.1.2 files but didn't find some relevant changes, just comment changes. Now I downgraded again to 5.1.1 and it's working fine again, no errors. Could you test the code on a Linux computer? [2006-02-01 16:19:43] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip Works fine here. [2006-02-01 14:05:47] eustaquiorangel at yahoo dot com The test.xsl code is also there on the URL, on the end of the PHP code. One interesting thing: I installed right now PHP 5.1.1, and it's working fine! Not so fast as PHP5 (the same speed as PHP4), but no more double frees. [2006-02-01 13:54:03] [EMAIL PROTECTED] To reproduce it we need test.xsl either. 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/36246 -- Edit this bug report at http://bugs.php.net/?id=36246&edit=1
#36158 [Com]: SIGTERM is not handled correctly when running as a FastCGI server
ID: 36158
Comment by: stefan at luli dot de
Reported By: chris at mysociety dot org
Status: Assigned
Bug Type: CGI related
Operating System: *
PHP Version: 5.1.2, 4.4.2
Assigned To: dmitry
New Comment:
Hi there,
I am struggeling with the described problem for quite some time now. I
have traced the problem now in the code back to
the SIGTERM play between fcgi_pm and php.
The question is if fcgi_pm should send a SIGTERM to the script even
though it processes a request at this momment. One would think that
fcgi_pm should be smart enough to deal with this situation (wait until
request is done/send no more requests/send SIGTERM). But apparently it
isn't.
The patch seams to do the trick, but is also prevents php to terminate
in case it's just idel. So php will sit there until the next request
comes in and terminate once the request is done before waiting for the
next request to come in. This should be solved.
Previous Comments:
[2006-01-26 08:58:25] [EMAIL PROTECTED]
Dmitry, does the new code fix this problem..?
[2006-01-26 01:55:15] chris at mysociety dot org
That snapshot (a) doesn't fix the problem -- the FastCGI code is
essentially unchanged since 4.x, though with a bunch of whitespace
noise; and (b) wouldn't help us in any case since it's PHP5 and our
applications are written for PHP4.
[2006-01-25 23:51:05] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
[2006-01-25 21:00:06] chris at mysociety dot org
Description:
When php is running as a FastCGI server, it should handle SIGTERM and
execute a graceful shutdown, because the mod_fastcgi process manager
uses this signal to shut down excess dynamic servers. "Graceful" in
this context means that the server must finish handling any outstanding
request and then terminate its connection to the web server. Presently,
PHP does not handle SIGTERM at all in the FastCGI request loop, so that
on receipt of SIGTERM, php aborts, even if half-way through a request.
This typically results in the web server logging "Incomplete headers (0
bytes) received", and returning "500 Internal Server Error" to the
client.
I have prepared a patch for this issue, here:
http://bitter.ukcod.org.uk/~chris/tmp/20060125/php-4.3.10-fastcgi-sigterm-fix.patch
-- this is against 4.3.10, but it applies to 4.4.2 fine.
Reproduce code:
---
Put the following in a .php file:
and set it up to run under FastCGI. Set up a script to request the page
in a loop ("while : ; do wget -O/dev/null -q http://path/to/script ;
done") Then kill the PHP process (pkill php will do this under Linux).
If you catch the script in the sleep, this will result in the client
getting a 500 and the web server logging a message about php failing,
as describe above.
Expected result:
No errors.
Actual result:
--
500 error.
--
Edit this bug report at http://bugs.php.net/?id=36158&edit=1
#36249 [NEW]: Include and Require do not work properly after ini_set include_path
From: john at castlecomm dot com Operating system: ALL PHP version: 4.4.2 PHP Bug Type: Reproducible crash Bug description: Include and Require do not work properly after ini_set include_path Description: Including a file using a relative path after INI SETTING the include_path does not work. Setting the include_path works, but but PHP does not use it correctly. This is a major flaw in the include logic. A full detailed example is listed under the "Reproduce code" section. Please fix this as soon as possible, as it is having drastic negative affects on my software with your latest version. Also, your "CAPTCHA" picture needs to be larger...the "R" in my code gets cut off and goes off the screen. I could barely make it out. Reproduce code: --- [john@(PROTECTED) error]$ cat mainfile.php [john@(PROTECTED) error]$ cat ws/wsfile.php [john@(PROTECTED) error]$ cat inc/incfile.php [john@(PROTECTED) error]$ php mainfile.php Warning: main(../inc/incfile.php): failed to open stream: No such file or directory in /(PROTECTED)/john/error/ws/wsfile.php on line 2 Warning: main(): Failed opening '../inc/incfile.php' for inclusion (include_path='.:/usr/local/lib/php:./ws:') in /(PROTECTED)/john/error/ws/wsfile.php on line 2 Hi! I'm wsfile! Hi! I'm mainfile! Expected result: The INI SET works, but include_once, as well as the others, do not work correctly. It can't find the relatively included file...even though the INI include_path is set. The code should work because the include path has been set properly. Even the error output shows the right include path, but the include_once directive just fails. This is a major error and is having really bad results on my software. Please fix this asap! Actual result: -- [john@(PROTECTED) error]$ php mainfile.php Warning: main(../inc/incfile.php): failed to open stream: No such file or directory in /(PROTECTED)/john/error/ws/wsfile.php on line 2 Warning: main(): Failed opening '../inc/incfile.php' for inclusion (include_path='.:/usr/local/lib/php:./ws:') in /(PROTECTED)/john/error/ws/wsfile.php on line 2 Hi! I'm wsfile! Hi! I'm mainfile! -- Edit bug report at http://bugs.php.net/?id=36249&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36249&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36249&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36249&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36249&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36249&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36249&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36249&r=needscript Try newer version:http://bugs.php.net/fix.php?id=36249&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36249&r=support Expected behavior:http://bugs.php.net/fix.php?id=36249&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36249&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36249&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36249&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36249&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36249&r=dst IIS Stability:http://bugs.php.net/fix.php?id=36249&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=36249&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=36249&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=36249&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=36249&r=mysqlcfg
#36159 [Opn->Fbk]: Running simple prepared statement SELECT fails (postgres)
ID: 36159
Updated by: [EMAIL PROTECTED]
Reported By: edrozenberg at pobox dot com
-Status: Open
+Status: Feedback
Bug Type: PDO related
Operating System: Windows XP SP2
PHP Version: 5.1.2
New Comment:
Works fine here, with $values value being either array() or null.
Previous Comments:
[2006-01-30 16:49:32] edrozenberg at pobox dot com
Same problem with latest Windows snap + php_pdo_pgsql.dll php-5.1.2
(5_1).
[2006-01-29 19:33:59] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
Something was just fixed.
[2006-01-26 15:35:36] edrozenberg at pobox dot com
Just tried latest Windows snapshot 5.1.3-dev and have the same problem.
Reverting back to 5.1.1 fixes the problem. I don't know how to trace
the problem further and don't see any errors in any of the Apache logs.
My main server is Linux so this isn't a showstopper right now but there
may be some bug here that needs to be gotten to the bottom of.
[2006-01-26 10:04:03] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
[2006-01-25 22:08:13] edrozenberg at pobox dot com
Description:
Since upgrading PHP from 5.1.1 to 5.1.2, running a simple prepared
statement SELECT fails. Error info from print_r($stmt->errorInfo()):
Array ( [0] => 0 )
I have experienced no such problems on Linux 2.4 with PHP 5.1.2
compiled from source.
Reproduce code:
---
private function dbSel($query, $values)
{
$stmt = $this->dbh->prepare($query);
if ( ! $stmt->execute($values) )
{
print_r($stmt->errorInfo());
$this->dbErrorGet($stmt);
return(0);
}
$this->rows = $stmt->fetchAll(PDO::FETCH_ASSOC);
return(1);
}
--
$query: "SELECT * \n FROM t_workfile"
$values: array of
Expected result:
$stmt->execute($values) should return TRUE and
there should be rows that can be fetched
Actual result:
--
$stmt->execute($values) returns false and the
print_r($stmt->errorInfo()) statement prints "Array ( [0] => 0 )"
--
Edit this bug report at http://bugs.php.net/?id=36159&edit=1
#36248 [Fbk->Opn]: CURLOPT_HEADERFUNCTION, couldn't set the function in the class
ID: 36248
User updated by: Admin at relax-info dot com
Reported By: Admin at relax-info dot com
-Status: Feedback
+Status: Open
Bug Type: cURL related
Operating System: WIN XP SP2
PHP Version: 4.4.2
New Comment:
I am truncate all comment from my class and delete other method than
not assign with problem
url = $url;
}
function init()
{
$this->_ch = curl_init();
// ...
}
function execute()
{
// defauukt setup
curl_setopt($this->_ch, CURLOPT_URL, $this->url);
// HEADER
if ($this->header)
{
curl_setopt($this->_ch, CURLOPT_HEADER, true);
curl_setopt($this->_ch, CURLOPT_HEADERFUNCTION,
array($this,
'_header_callback');
}
// exec
$result = curl_exec($this->_ch);
// ..
return $result;
}
function _header_callback($ch, $header)
{
return strlen($header);
}
}
// EXAMPLE -
$url = 'http://www.relax-info.com';
$curl = new CURL($url);
if ($curl->init())
{
$curl->returntransfer = true;
$curl->header = true;
$result = $curl->execute();
print_r($result);
}
else echo $curl->get_error();
?>
Previous Comments:
[2006-02-01 17:43:05] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.
[2006-02-01 17:40:49] Admin at relax-info dot com
Sorry, callback function example...
function _header_callback($ch, $header)
{
// print_r($header);
}
[2006-02-01 17:39:51] Admin at relax-info dot com
Description:
Couldn't set the name of a callback function where the callback
function exists in a class, array($this, 'callback_function'). Apache
die ...
Reproduce code:
---
class CURL
{
var $_ch;
.
$this->_ch = curl_init();
..
curl_setopt($this->_ch, CURLOPT_HEADERFUNCTION, array($this,
'_header_callback'));
..
}
Expected result:
The name of a callback function can be method of class
array($this, 'callback_function')
Actual result:
--
Apache die ...
--
Edit this bug report at http://bugs.php.net/?id=36248&edit=1
#36247 [Opn->Bgs]: pdflib won't load in sapi, cli is fine
ID: 36247 Updated by: [EMAIL PROTECTED] Reported By: rick at revenew dot nl -Status: Open +Status: Bogus Bug Type: PDF related Operating System: Debian Sarge (pure64) PHP Version: 5.1.2 New Comment: This is a bug with a PDF extension that is found in PECL and appears to be an issue with the extension itself. Please post the bug on PECL's bug system. Previous Comments: [2006-02-01 16:36:34] rick at revenew dot nl Description: When I try to load pdflib in the apache sapi module of php, it fails to load SAPI: [01-Feb-2006 16:32:34] PHP Warning: PHP Startup: Unable to load dynamic library '/usr/local/php5-ext/libpdf_php.so' - /usr/local/php5-ext/libpdf_php.so: undefined symbol: _zval_ptr_dtor in Unknown on line 0 CLI: # echo ''|/usr/local/php5/bin/php|grep -i pdf > pdf > PDF Support => enabled > PDFlib GmbH Binary-Version => 6.0.2p6 The same thing happens with the precompiled pdflib module from pdflib.com and a self-compiled version from PECL. I also tested the latest php cvs snapshot (php5.1-200602011330). The same things happens. Reproduce code: --- none Expected result: pdflib module loaded Actual result: -- pdflib module won't load -- Edit this bug report at http://bugs.php.net/?id=36247&edit=1
#36248 [Opn->Fbk]: CURLOPT_HEADERFUNCTION, couldn't set the function in the class
ID: 36248
Updated by: [EMAIL PROTECTED]
Reported By: Admin at relax-info dot com
-Status: Open
+Status: Feedback
Bug Type: cURL related
Operating System: WIN XP SP2
PHP Version: 4.4.2
New Comment:
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.
Previous Comments:
[2006-02-01 17:40:49] Admin at relax-info dot com
Sorry, callback function example...
function _header_callback($ch, $header)
{
// print_r($header);
}
[2006-02-01 17:39:51] Admin at relax-info dot com
Description:
Couldn't set the name of a callback function where the callback
function exists in a class, array($this, 'callback_function'). Apache
die ...
Reproduce code:
---
class CURL
{
var $_ch;
.
$this->_ch = curl_init();
..
curl_setopt($this->_ch, CURLOPT_HEADERFUNCTION, array($this,
'_header_callback'));
..
}
Expected result:
The name of a callback function can be method of class
array($this, 'callback_function')
Actual result:
--
Apache die ...
--
Edit this bug report at http://bugs.php.net/?id=36248&edit=1
#36248 [NEW]: CURLOPT_HEADERFUNCTION, couldn't set the function in the class
From: Admin at relax-info dot com
Operating system: WIN XP SP2
PHP version: 4.4.2
PHP Bug Type: cURL related
Bug description: CURLOPT_HEADERFUNCTION, couldn't set the function in the class
Description:
Couldn't set the name of a callback function where the callback function
exists in a class, array($this, 'callback_function'). Apache die ...
Reproduce code:
---
class CURL
{
var $_ch;
.
$this->_ch = curl_init();
..
curl_setopt($this->_ch, CURLOPT_HEADERFUNCTION, array($this,
'_header_callback'));
..
}
Expected result:
The name of a callback function can be method of class
array($this, 'callback_function')
Actual result:
--
Apache die ...
--
Edit bug report at http://bugs.php.net/?id=36248&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=36248&r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=36248&r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=36248&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=36248&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=36248&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=36248&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=36248&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=36248&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=36248&r=support
Expected behavior:http://bugs.php.net/fix.php?id=36248&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=36248&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=36248&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=36248&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36248&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=36248&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=36248&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=36248&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=36248&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=36248&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=36248&r=mysqlcfg
#36248 [Opn]: CURLOPT_HEADERFUNCTION, couldn't set the function in the class
ID: 36248
User updated by: Admin at relax-info dot com
Reported By: Admin at relax-info dot com
Status: Open
Bug Type: cURL related
Operating System: WIN XP SP2
PHP Version: 4.4.2
New Comment:
Sorry, callback function example...
function _header_callback($ch, $header)
{
// print_r($header);
}
Previous Comments:
[2006-02-01 17:39:51] Admin at relax-info dot com
Description:
Couldn't set the name of a callback function where the callback
function exists in a class, array($this, 'callback_function'). Apache
die ...
Reproduce code:
---
class CURL
{
var $_ch;
.
$this->_ch = curl_init();
..
curl_setopt($this->_ch, CURLOPT_HEADERFUNCTION, array($this,
'_header_callback'));
..
}
Expected result:
The name of a callback function can be method of class
array($this, 'callback_function')
Actual result:
--
Apache die ...
--
Edit this bug report at http://bugs.php.net/?id=36248&edit=1
#36246 [Opn->Fbk]: Memory problem (double free)
ID: 36246 Updated by: [EMAIL PROTECTED] Reported By: eustaquiorangel at yahoo dot com -Status: Open +Status: Feedback Bug Type: XSLT related Operating System: Linux, Slackware 10.2 (current) PHP Version: 5.1.2 New Comment: Can you get a backtrace? It's working fine for me on both win and linux boxes. does it crash under cli too? Previous Comments: [2006-02-01 17:24:14] eustaquiorangel at yahoo dot com No way to avoid it with 5.1.1 +. :-( I downloaded the snapshot you told me, installed (phpversion() gives me "5.1.3-dev") and when running the sample, it shows me again the error_log message: *** glibc detected *** double free or corruption (fasttop): 0x082392a0 *** [Wed Feb 01 14:10:20 2006] [notice] child pid 11636 exit signal Aborted (6) I'm checking http://www.php.net/ChangeLog-5.php and seems that on the Windows version there were some changes: # Updated to libxml2-2.6.22 and libxslt-1.1.15 in the win32 bundle. (Rob) It's exactly the same versions I'm running here on Linux. And there were some little stuff like # Added constants for libxslt and libexslt versions: LIBXSLT_VERSION, LIBXSLT_DOTTED_VERSION, LIBEXSLT_VERSION and LIBEXSLT_DOTTED_VERSION. (Pierre) that would not affect this way the behaviour. I did some diffs with the ext/xsl 5.1.1 and 5.1.2 files but didn't find some relevant changes, just comment changes. Now I downgraded again to 5.1.1 and it's working fine again, no errors. Could you test the code on a Linux computer? [2006-02-01 16:19:43] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip Works fine here. [2006-02-01 14:05:47] eustaquiorangel at yahoo dot com The test.xsl code is also there on the URL, on the end of the PHP code. One interesting thing: I installed right now PHP 5.1.1, and it's working fine! Not so fast as PHP5 (the same speed as PHP4), but no more double frees. [2006-02-01 13:54:03] [EMAIL PROTECTED] To reproduce it we need test.xsl either. [2006-02-01 13:36:22] eustaquiorangel at yahoo dot com Description: After I use the XSLT extension to process a huge file, I got an error on the Apache error_log and a blank page on the browser. The error is: *** glibc detected *** double free or corruption (fasttop): 0x08236cc8 *** [Wed Feb 01 08:56:12 2006] [notice] child pid 7121 exit signal Aborted (6) Reproduce code: --- http://pastebin.com/533629 Expected result: A regular HTML page and no error on error_log. Actual result: -- Sometimes it becomes blank and after some realoading it works, but *always* with an error message on error_log. I tested the code on all the ways I could but the only solution was downgrade PHP to 4.4.2 with Sablotron support. Then everything run fine (same Apache version, same OS), the only negavite thing is that it takes a lot of time to show the results on the browser, while using PHP 5.1.2 it was very fast. -- Edit this bug report at http://bugs.php.net/?id=36246&edit=1
#36246 [Fbk->Opn]: Memory problem (double free)
ID: 36246 User updated by: eustaquiorangel at yahoo dot com Reported By: eustaquiorangel at yahoo dot com -Status: Feedback +Status: Open Bug Type: XSLT related Operating System: Linux, Slackware 10.2 (current) PHP Version: 5.1.2 New Comment: No way to avoid it with 5.1.1 +. :-( I downloaded the snapshot you told me, installed (phpversion() gives me "5.1.3-dev") and when running the sample, it shows me again the error_log message: *** glibc detected *** double free or corruption (fasttop): 0x082392a0 *** [Wed Feb 01 14:10:20 2006] [notice] child pid 11636 exit signal Aborted (6) I'm checking http://www.php.net/ChangeLog-5.php and seems that on the Windows version there were some changes: # Updated to libxml2-2.6.22 and libxslt-1.1.15 in the win32 bundle. (Rob) It's exactly the same versions I'm running here on Linux. And there were some little stuff like # Added constants for libxslt and libexslt versions: LIBXSLT_VERSION, LIBXSLT_DOTTED_VERSION, LIBEXSLT_VERSION and LIBEXSLT_DOTTED_VERSION. (Pierre) that would not affect this way the behaviour. I did some diffs with the ext/xsl 5.1.1 and 5.1.2 files but didn't find some relevant changes, just comment changes. Now I downgraded again to 5.1.1 and it's working fine again, no errors. Could you test the code on a Linux computer? Previous Comments: [2006-02-01 16:19:43] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip Works fine here. [2006-02-01 14:05:47] eustaquiorangel at yahoo dot com The test.xsl code is also there on the URL, on the end of the PHP code. One interesting thing: I installed right now PHP 5.1.1, and it's working fine! Not so fast as PHP5 (the same speed as PHP4), but no more double frees. [2006-02-01 13:54:03] [EMAIL PROTECTED] To reproduce it we need test.xsl either. [2006-02-01 13:36:22] eustaquiorangel at yahoo dot com Description: After I use the XSLT extension to process a huge file, I got an error on the Apache error_log and a blank page on the browser. The error is: *** glibc detected *** double free or corruption (fasttop): 0x08236cc8 *** [Wed Feb 01 08:56:12 2006] [notice] child pid 7121 exit signal Aborted (6) Reproduce code: --- http://pastebin.com/533629 Expected result: A regular HTML page and no error on error_log. Actual result: -- Sometimes it becomes blank and after some realoading it works, but *always* with an error message on error_log. I tested the code on all the ways I could but the only solution was downgrade PHP to 4.4.2 with Sablotron support. Then everything run fine (same Apache version, same OS), the only negavite thing is that it takes a lot of time to show the results on the browser, while using PHP 5.1.2 it was very fast. -- Edit this bug report at http://bugs.php.net/?id=36246&edit=1
#36206 [Opn->Bgs]: LDAP in nsswitch.conf causes segfault when resolving hostnames in PHP
ID: 36206 Updated by: [EMAIL PROTECTED] Reported By: arnout at argeweb dot nl -Status: Open +Status: Bogus Bug Type: CGI related Operating System: freeBSD 5.4 PHP Version: 5.1.2 New Comment: Working Python doesn't make segfault in system libraries PHP problem. Please report it to FreeBSD developers. Previous Comments: [2006-02-01 16:28:05] arnout at argeweb dot nl No bogus yet :) [2006-02-01 16:27:37] arnout at argeweb dot nl Tried it. Python works great. No segfaults here. We tried python with AND without LDAP. It's a different problem that looks the same. [EMAIL PROTECTED]: ~ # python mysql.py Traceback (most recent call last): File "mysql.py", line 6, in ? db = "test") File "/usr/local/lib/python2.4/site-packages/MySQLdb/__init__.py", line 66, in Connect return Connection(*args, **kwargs) File "/usr/local/lib/python2.4/site-packages/MySQLdb/connections.py", line 134, in __init__ super(Connection, self).__init__(*args, **kwargs2) _mysql_exceptions.OperationalError: (2005, "Unknown MySQL server host 'dfgdfgdfg' (1)") [EMAIL PROTECTED]: ~ # python mysql.py Traceback (most recent call last): File "mysql.py", line 6, in ? db = "test") File "/usr/local/lib/python2.4/site-packages/MySQLdb/__init__.py", line 66, in Connect return Connection(*args, **kwargs) File "/usr/local/lib/python2.4/site-packages/MySQLdb/connections.py", line 134, in __init__ super(Connection, self).__init__(*args, **kwargs2) _mysql_exceptions.OperationalError: (1130, "Host 'nonexistenthost.nl' is not allowed to connect to this MySQL server") [2006-02-01 16:01:47] [EMAIL PROTECTED] Here: http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2005-11/0315.html you can find that this problem also happens with Python on FreeBSD (with the very same backtrace). So it's not PHP problem, but some FreeBSD issue. [2006-02-01 15:34:08] arnout at argeweb dot nl [EMAIL PROTECTED]: ~ $ host example.com example.com has address 192.0.34.166 top works fine ps aux works fine No segfaults there... [2006-02-01 12:33:42] [EMAIL PROTECTED] Please try to run `top`, `ps aux` and `host example.com`. Do they work fine or segfault too? I'm asking because of this: http://lists.freebsd.org/pipermail/freebsd-bugs/2004-April/006201.html 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/36206 -- Edit this bug report at http://bugs.php.net/?id=36206&edit=1
#36247 [NEW]: pdflib won't load in sapi, cli is fine
From: rick at revenew dot nl Operating system: Debian Sarge (pure64) PHP version: 5.1.2 PHP Bug Type: PDF related Bug description: pdflib won't load in sapi, cli is fine Description: When I try to load pdflib in the apache sapi module of php, it fails to load SAPI: [01-Feb-2006 16:32:34] PHP Warning: PHP Startup: Unable to load dynamic library '/usr/local/php5-ext/libpdf_php.so' - /usr/local/php5-ext/libpdf_php.so: undefined symbol: _zval_ptr_dtor in Unknown on line 0 CLI: # echo ''|/usr/local/php5/bin/php|grep -i pdf > pdf > PDF Support => enabled > PDFlib GmbH Binary-Version => 6.0.2p6 The same thing happens with the precompiled pdflib module from pdflib.com and a self-compiled version from PECL. I also tested the latest php cvs snapshot (php5.1-200602011330). The same things happens. Reproduce code: --- none Expected result: pdflib module loaded Actual result: -- pdflib module won't load -- Edit bug report at http://bugs.php.net/?id=36247&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36247&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36247&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36247&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36247&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36247&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36247&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36247&r=needscript Try newer version:http://bugs.php.net/fix.php?id=36247&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36247&r=support Expected behavior:http://bugs.php.net/fix.php?id=36247&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36247&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36247&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36247&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36247&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36247&r=dst IIS Stability:http://bugs.php.net/fix.php?id=36247&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=36247&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=36247&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=36247&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=36247&r=mysqlcfg
#36206 [Bgs->Opn]: LDAP in nsswitch.conf causes segfault when resolving hostnames in PHP
ID: 36206 User updated by: arnout at argeweb dot nl Reported By: arnout at argeweb dot nl -Status: Bogus +Status: Open Bug Type: CGI related Operating System: freeBSD 5.4 PHP Version: 5.1.2 New Comment: No bogus yet :) Previous Comments: [2006-02-01 16:27:37] arnout at argeweb dot nl Tried it. Python works great. No segfaults here. We tried python with AND without LDAP. It's a different problem that looks the same. [EMAIL PROTECTED]: ~ # python mysql.py Traceback (most recent call last): File "mysql.py", line 6, in ? db = "test") File "/usr/local/lib/python2.4/site-packages/MySQLdb/__init__.py", line 66, in Connect return Connection(*args, **kwargs) File "/usr/local/lib/python2.4/site-packages/MySQLdb/connections.py", line 134, in __init__ super(Connection, self).__init__(*args, **kwargs2) _mysql_exceptions.OperationalError: (2005, "Unknown MySQL server host 'dfgdfgdfg' (1)") [EMAIL PROTECTED]: ~ # python mysql.py Traceback (most recent call last): File "mysql.py", line 6, in ? db = "test") File "/usr/local/lib/python2.4/site-packages/MySQLdb/__init__.py", line 66, in Connect return Connection(*args, **kwargs) File "/usr/local/lib/python2.4/site-packages/MySQLdb/connections.py", line 134, in __init__ super(Connection, self).__init__(*args, **kwargs2) _mysql_exceptions.OperationalError: (1130, "Host 'nonexistenthost.nl' is not allowed to connect to this MySQL server") [2006-02-01 16:01:47] [EMAIL PROTECTED] Here: http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2005-11/0315.html you can find that this problem also happens with Python on FreeBSD (with the very same backtrace). So it's not PHP problem, but some FreeBSD issue. [2006-02-01 15:34:08] arnout at argeweb dot nl [EMAIL PROTECTED]: ~ $ host example.com example.com has address 192.0.34.166 top works fine ps aux works fine No segfaults there... [2006-02-01 12:33:42] [EMAIL PROTECTED] Please try to run `top`, `ps aux` and `host example.com`. Do they work fine or segfault too? I'm asking because of this: http://lists.freebsd.org/pipermail/freebsd-bugs/2004-April/006201.html [2006-01-30 12:25:00] arnout at argeweb dot nl This just in: The script does not terminate. It ends like it's supposed to. The segfault is put out when the scripts terminates. I don't know if it's a child process that dies, or that the segfault resides in a buffer untill termination or something. [EMAIL PROTECTED]: / # echo "" | php 64.246.30.37Segmentation fault (core dumped) I seem to have judged to fast before. But still: I can't surpress this error. It's ugly! 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/36206 -- Edit this bug report at http://bugs.php.net/?id=36206&edit=1
#36206 [Bgs]: LDAP in nsswitch.conf causes segfault when resolving hostnames in PHP
ID: 36206 User updated by: arnout at argeweb dot nl Reported By: arnout at argeweb dot nl Status: Bogus Bug Type: CGI related Operating System: freeBSD 5.4 PHP Version: 5.1.2 New Comment: Tried it. Python works great. No segfaults here. We tried python with AND without LDAP. It's a different problem that looks the same. [EMAIL PROTECTED]: ~ # python mysql.py Traceback (most recent call last): File "mysql.py", line 6, in ? db = "test") File "/usr/local/lib/python2.4/site-packages/MySQLdb/__init__.py", line 66, in Connect return Connection(*args, **kwargs) File "/usr/local/lib/python2.4/site-packages/MySQLdb/connections.py", line 134, in __init__ super(Connection, self).__init__(*args, **kwargs2) _mysql_exceptions.OperationalError: (2005, "Unknown MySQL server host 'dfgdfgdfg' (1)") [EMAIL PROTECTED]: ~ # python mysql.py Traceback (most recent call last): File "mysql.py", line 6, in ? db = "test") File "/usr/local/lib/python2.4/site-packages/MySQLdb/__init__.py", line 66, in Connect return Connection(*args, **kwargs) File "/usr/local/lib/python2.4/site-packages/MySQLdb/connections.py", line 134, in __init__ super(Connection, self).__init__(*args, **kwargs2) _mysql_exceptions.OperationalError: (1130, "Host 'nonexistenthost.nl' is not allowed to connect to this MySQL server") Previous Comments: [2006-02-01 16:01:47] [EMAIL PROTECTED] Here: http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2005-11/0315.html you can find that this problem also happens with Python on FreeBSD (with the very same backtrace). So it's not PHP problem, but some FreeBSD issue. [2006-02-01 15:34:08] arnout at argeweb dot nl [EMAIL PROTECTED]: ~ $ host example.com example.com has address 192.0.34.166 top works fine ps aux works fine No segfaults there... [2006-02-01 12:33:42] [EMAIL PROTECTED] Please try to run `top`, `ps aux` and `host example.com`. Do they work fine or segfault too? I'm asking because of this: http://lists.freebsd.org/pipermail/freebsd-bugs/2004-April/006201.html [2006-01-30 12:25:00] arnout at argeweb dot nl This just in: The script does not terminate. It ends like it's supposed to. The segfault is put out when the scripts terminates. I don't know if it's a child process that dies, or that the segfault resides in a buffer untill termination or something. [EMAIL PROTECTED]: / # echo "" | php 64.246.30.37Segmentation fault (core dumped) I seem to have judged to fast before. But still: I can't surpress this error. It's ugly! [2006-01-30 12:01:41] arnout at argeweb dot nl status change 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/36206 -- Edit this bug report at http://bugs.php.net/?id=36206&edit=1
#36246 [Opn->Fbk]: Memory problem (double free)
ID: 36246 Updated by: [EMAIL PROTECTED] Reported By: eustaquiorangel at yahoo dot com -Status: Open +Status: Feedback Bug Type: XSLT related Operating System: Linux, Slackware 10.2 (current) PHP Version: 5.1.2 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip Works fine here. Previous Comments: [2006-02-01 14:05:47] eustaquiorangel at yahoo dot com The test.xsl code is also there on the URL, on the end of the PHP code. One interesting thing: I installed right now PHP 5.1.1, and it's working fine! Not so fast as PHP5 (the same speed as PHP4), but no more double frees. [2006-02-01 13:54:03] [EMAIL PROTECTED] To reproduce it we need test.xsl either. [2006-02-01 13:36:22] eustaquiorangel at yahoo dot com Description: After I use the XSLT extension to process a huge file, I got an error on the Apache error_log and a blank page on the browser. The error is: *** glibc detected *** double free or corruption (fasttop): 0x08236cc8 *** [Wed Feb 01 08:56:12 2006] [notice] child pid 7121 exit signal Aborted (6) Reproduce code: --- http://pastebin.com/533629 Expected result: A regular HTML page and no error on error_log. Actual result: -- Sometimes it becomes blank and after some realoading it works, but *always* with an error message on error_log. I tested the code on all the ways I could but the only solution was downgrade PHP to 4.4.2 with Sablotron support. Then everything run fine (same Apache version, same OS), the only negavite thing is that it takes a lot of time to show the results on the browser, while using PHP 5.1.2 it was very fast. -- Edit this bug report at http://bugs.php.net/?id=36246&edit=1
#36245 [Opn->Asn]: SOAP in WDSL incorrect complex type encoding
ID: 36245
Updated by: [EMAIL PROTECTED]
Reported By: hans at lintoo dot dk
-Status: Open
+Status: Assigned
Bug Type: SOAP related
Operating System: FreeBSD 5.4 + FreeBSD 6 + Win32
PHP Version: 5.1.2 + CVS(200602010930)
-Assigned To:
+Assigned To: dmitry
New Comment:
Assigned to the maintainer.
Previous Comments:
[2006-02-01 14:27:26] hans at lintoo dot dk
Tested on:
PHP 5.1.2 - FreeBSD 5.4
PHP 5.1.2 - FreeBSD 6
PHP 5.1.2 - Win32
PHP CVS(200602010930) - Win32
Same result everywhere... :(
[2006-02-01 13:03:49] hans at lintoo dot dk
switch: Expected result & Actual result... sorry!
[2006-02-01 13:02:32] hans at lintoo dot dk
Description:
Please excuse me if this problem is related to my code, i tried all
combinations of coding methods I could think of, but still it did not
return the code I was expecting.
I get the following exception:
SoapFault exception: [soap:Client] Incorrect format for named street
text line
which i believe is due to incorrect coding of the complex types.
You can find the WSDL at:
http://dev.lintoo.net/findaddressservice.wsdl
Reproduce code:
---
http://dev.lintoo.net/findaddressservice.wsdl', array(
'soap_version' => SOAP_1_1,
"trace" => 1,
"exceptions" => 1
));
class FindAddressAccessRequest {
public $NamedStreetTextInput;
public $StreetBuildingIdentifier;
public $MunicipalitySearch;
public $DistrictSearch;
public $DistrictSubdivisionSearch;
}
$FindAddressAccessRequest = new FindAddressAccessRequest();
$FindAddressAccessRequest->NamedStreetTextInput = "Hjallesevej";
$FindAddressAccessRequest->StreetBuildingIdentifier = "34";
$findAddressParam = array('NamedStreetTextInput' => "Hjallesevej",
'StreetBuildingIdentifier' => '34');
$client->FindAddressAccess($FindAddressAccessRequest);
print($client->__getLastRequest());
?>
Expected result:
Hjallesevej
34
Actual result:
--
Hjallesevej
34
--
Edit this bug report at http://bugs.php.net/?id=36245&edit=1
#36206 [Opn->Bgs]: LDAP in nsswitch.conf causes segfault when resolving hostnames in PHP
ID: 36206 Updated by: [EMAIL PROTECTED] Reported By: arnout at argeweb dot nl -Status: Open +Status: Bogus Bug Type: CGI related Operating System: freeBSD 5.4 PHP Version: 5.1.2 New Comment: Here: http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2005-11/0315.html you can find that this problem also happens with Python on FreeBSD (with the very same backtrace). So it's not PHP problem, but some FreeBSD issue. Previous Comments: [2006-02-01 15:34:08] arnout at argeweb dot nl [EMAIL PROTECTED]: ~ $ host example.com example.com has address 192.0.34.166 top works fine ps aux works fine No segfaults there... [2006-02-01 12:33:42] [EMAIL PROTECTED] Please try to run `top`, `ps aux` and `host example.com`. Do they work fine or segfault too? I'm asking because of this: http://lists.freebsd.org/pipermail/freebsd-bugs/2004-April/006201.html [2006-01-30 12:25:00] arnout at argeweb dot nl This just in: The script does not terminate. It ends like it's supposed to. The segfault is put out when the scripts terminates. I don't know if it's a child process that dies, or that the segfault resides in a buffer untill termination or something. [EMAIL PROTECTED]: / # echo "" | php 64.246.30.37Segmentation fault (core dumped) I seem to have judged to fast before. But still: I can't surpress this error. It's ugly! [2006-01-30 12:01:41] arnout at argeweb dot nl status change [2006-01-30 12:00:33] oersoep at gmail dot com #0 0x in ?? () #1 0x292ff7a5 in ?? () from /usr/local/lib/nss_ldap.so.1 #2 0x2930a4c0 in ?? () from /usr/local/lib/nss_ldap.so.1 #3 0x2817d760 in ?? () from /libexec/ld-elf.so.1 #4 0x2817d5d8 in ?? () from /libexec/ld-elf.so.1 #5 0x292ff740 in ?? () from /usr/local/lib/nss_ldap.so.1 #6 0x28162730 in _rtld_error () from /libexec/ld-elf.so.1 #7 0x293086c9 in _fini () from /usr/local/lib/nss_ldap.so.1 #8 0x2816380b in find_symdef () from /libexec/ld-elf.so.1 #9 0x28163e6a in dlclose () from /libexec/ld-elf.so.1 #10 0x2845b53c in _nsdbtput () from /lib/libc.so.5 #11 0x2845aef0 in endhostent () from /lib/libc.so.5 #12 0x2845b5bb in _nsdbtput () from /lib/libc.so.5 #13 0x2847e1a5 in __cxa_finalize () from /lib/libc.so.5 #14 0x2847dec6 in exit () from /lib/libc.so.5 #15 0x08130cc5 in main () 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/36206 -- Edit this bug report at http://bugs.php.net/?id=36206&edit=1
#36206 [Fbk->Opn]: LDAP in nsswitch.conf causes segfault when resolving hostnames in PHP
ID: 36206 User updated by: arnout at argeweb dot nl Reported By: arnout at argeweb dot nl -Status: Feedback +Status: Open Bug Type: CGI related Operating System: freeBSD 5.4 PHP Version: 5.1.2 New Comment: [EMAIL PROTECTED]: ~ $ host example.com example.com has address 192.0.34.166 top works fine ps aux works fine No segfaults there... Previous Comments: [2006-02-01 12:33:42] [EMAIL PROTECTED] Please try to run `top`, `ps aux` and `host example.com`. Do they work fine or segfault too? I'm asking because of this: http://lists.freebsd.org/pipermail/freebsd-bugs/2004-April/006201.html [2006-01-30 12:25:00] arnout at argeweb dot nl This just in: The script does not terminate. It ends like it's supposed to. The segfault is put out when the scripts terminates. I don't know if it's a child process that dies, or that the segfault resides in a buffer untill termination or something. [EMAIL PROTECTED]: / # echo "" | php 64.246.30.37Segmentation fault (core dumped) I seem to have judged to fast before. But still: I can't surpress this error. It's ugly! [2006-01-30 12:01:41] arnout at argeweb dot nl status change [2006-01-30 12:00:33] oersoep at gmail dot com #0 0x in ?? () #1 0x292ff7a5 in ?? () from /usr/local/lib/nss_ldap.so.1 #2 0x2930a4c0 in ?? () from /usr/local/lib/nss_ldap.so.1 #3 0x2817d760 in ?? () from /libexec/ld-elf.so.1 #4 0x2817d5d8 in ?? () from /libexec/ld-elf.so.1 #5 0x292ff740 in ?? () from /usr/local/lib/nss_ldap.so.1 #6 0x28162730 in _rtld_error () from /libexec/ld-elf.so.1 #7 0x293086c9 in _fini () from /usr/local/lib/nss_ldap.so.1 #8 0x2816380b in find_symdef () from /libexec/ld-elf.so.1 #9 0x28163e6a in dlclose () from /libexec/ld-elf.so.1 #10 0x2845b53c in _nsdbtput () from /lib/libc.so.5 #11 0x2845aef0 in endhostent () from /lib/libc.so.5 #12 0x2845b5bb in _nsdbtput () from /lib/libc.so.5 #13 0x2847e1a5 in __cxa_finalize () from /lib/libc.so.5 #14 0x2847dec6 in exit () from /lib/libc.so.5 #15 0x08130cc5 in main () [2006-01-30 11:55:17] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. 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/36206 -- Edit this bug report at http://bugs.php.net/?id=36206&edit=1
#36245 [Opn]: SOAP in WDSL incorrect complex type encoding
ID: 36245
User updated by: hans at lintoo dot dk
Reported By: hans at lintoo dot dk
Status: Open
Bug Type: SOAP related
-Operating System: FreeBSD 5.4
+Operating System: FreeBSD 5.4 + FreeBSD 6 + Win32
-PHP Version: 5.1.2
+PHP Version: 5.1.2 + CVS(200602010930)
New Comment:
Tested on:
PHP 5.1.2 - FreeBSD 5.4
PHP 5.1.2 - FreeBSD 6
PHP 5.1.2 - Win32
PHP CVS(200602010930) - Win32
Same result everywhere... :(
Previous Comments:
[2006-02-01 13:03:49] hans at lintoo dot dk
switch: Expected result & Actual result... sorry!
[2006-02-01 13:02:32] hans at lintoo dot dk
Description:
Please excuse me if this problem is related to my code, i tried all
combinations of coding methods I could think of, but still it did not
return the code I was expecting.
I get the following exception:
SoapFault exception: [soap:Client] Incorrect format for named street
text line
which i believe is due to incorrect coding of the complex types.
You can find the WSDL at:
http://dev.lintoo.net/findaddressservice.wsdl
Reproduce code:
---
http://dev.lintoo.net/findaddressservice.wsdl', array(
'soap_version' => SOAP_1_1,
"trace" => 1,
"exceptions" => 1
));
class FindAddressAccessRequest {
public $NamedStreetTextInput;
public $StreetBuildingIdentifier;
public $MunicipalitySearch;
public $DistrictSearch;
public $DistrictSubdivisionSearch;
}
$FindAddressAccessRequest = new FindAddressAccessRequest();
$FindAddressAccessRequest->NamedStreetTextInput = "Hjallesevej";
$FindAddressAccessRequest->StreetBuildingIdentifier = "34";
$findAddressParam = array('NamedStreetTextInput' => "Hjallesevej",
'StreetBuildingIdentifier' => '34');
$client->FindAddressAccess($FindAddressAccessRequest);
print($client->__getLastRequest());
?>
Expected result:
Hjallesevej
34
Actual result:
--
Hjallesevej
34
--
Edit this bug report at http://bugs.php.net/?id=36245&edit=1
#36208 [Fbk->Csd]: Symbols in libphp5.so conflict with symbols in libgd.so and cause apache probs
ID: 36208 Updated by: [EMAIL PROTECTED] Reported By: hb at gentoo dot x256 dot org -Status: Feedback +Status: Closed Bug Type: Dynamic loading Operating System: Gentoo Linux x86 PHP Version: 5.1.2 New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Thanks a lot for the patch Jakub, committed to HEAD/5.1. Previous Comments: [2006-02-01 13:16:44] jakub at gentoo dot org patch for 5.0.5: http://bugs.gentoo.org/attachment.cgi?id=78638 patch for 5.1.2, adding 6 additional compatibility symbols exported by libgd: http://bugs.gentoo.org/attachment.cgi?id=78639&action=view Reference Gentoo bug: http://bugs.gentoo.org/show_bug.cgi?id=120908 Should be backported to 4.4.x as well, but that's really upstream job. ;) [2006-02-01 12:05:33] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. [2006-02-01 11:05:01] hb at gentoo dot x256 dot org Sorry, as I said, I spent over a day tracking down this problem. I submitted a bug report to Gentoo and they told me it was not their problem and that it should be fixed in PHP, which seemed somewhat reasonable. Then I was told that it had to be configured differently, which would require a change in Gentoo, but this problem would remain in other distributions. I just want to fix it so that other people don't have to go through what I did. I will try to make a patch. [2006-02-01 09:16:40] [EMAIL PROTECTED] There is no need to use this kind of language, it will not make us help you faster. That said, we actually do namespace protect those symbols in there by prefixing them with php_gd_. It seems however that some of them are not added yet, see the file main/php_compat.h. Feel free to submit a patch for that file. [2006-02-01 05:33:10] hb at gentoo dot x256 dot org This is a problem with PHP. You can't just tell me to compile it differently because in the real world, when actual users compile and install perl and PHP, they won't know this. There's no warning that I ever saw that tells me not to do this, and then my programs randomly crash, and I spent a whole day trying to work out why. This WILL happen to other people unless you fix YOUR bug, which is exporting non-standard GD symbols with standard names into the dynamic linker namespace. They should be renamed or hidden or set to a different version so they won't collide with the real GD. I guess if you're unwilling to fix it I'll have to get the Gentoo people to either patch PHP or change the portage system so it won't install PHP and mod_perl simultaneously with USE=gd. However, this has the possibility of biting people in other circumstances too. I can't understand why you say it's not your problem. You shouldn't export symbols willy-nilly especially when you modify them from the library you pulled them from originally and don't rename them. 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/36208 -- Edit this bug report at http://bugs.php.net/?id=36208&edit=1
#36246 [Fbk->Opn]: Memory problem (double free)
ID: 36246 User updated by: eustaquiorangel at yahoo dot com Reported By: eustaquiorangel at yahoo dot com -Status: Feedback +Status: Open Bug Type: XSLT related Operating System: Linux, Slackware 10.2 (current) PHP Version: 5.1.2 New Comment: The test.xsl code is also there on the URL, on the end of the PHP code. One interesting thing: I installed right now PHP 5.1.1, and it's working fine! Not so fast as PHP5 (the same speed as PHP4), but no more double frees. Previous Comments: [2006-02-01 13:54:03] [EMAIL PROTECTED] To reproduce it we need test.xsl either. [2006-02-01 13:36:22] eustaquiorangel at yahoo dot com Description: After I use the XSLT extension to process a huge file, I got an error on the Apache error_log and a blank page on the browser. The error is: *** glibc detected *** double free or corruption (fasttop): 0x08236cc8 *** [Wed Feb 01 08:56:12 2006] [notice] child pid 7121 exit signal Aborted (6) Reproduce code: --- http://pastebin.com/533629 Expected result: A regular HTML page and no error on error_log. Actual result: -- Sometimes it becomes blank and after some realoading it works, but *always* with an error message on error_log. I tested the code on all the ways I could but the only solution was downgrade PHP to 4.4.2 with Sablotron support. Then everything run fine (same Apache version, same OS), the only negavite thing is that it takes a lot of time to show the results on the browser, while using PHP 5.1.2 it was very fast. -- Edit this bug report at http://bugs.php.net/?id=36246&edit=1
#36242 [Csd]: Weak type checking on stream_select() allows stack corruption
ID: 36242
User updated by: cyberleo at cyberleo dot net
Reported By: cyberleo at cyberleo dot net
Status: Closed
Bug Type: Streams related
Operating System: FreeBSD 4.10-REL
PHP Version: 4CVS-2006-02-01 (snap)
New Comment:
Verified fixed in php4 and php5 CVS.
Thanks!
Previous Comments:
[2006-02-01 11:32:42] [EMAIL PROTECTED]
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
[2006-02-01 10:41:29] cyberleo at cyberleo dot net
Description:
Weak type checking on stream_select() allows stack corruption.
Passing a value that is not an integer to stream_select()'s fourth
parameter, tv_sec, appears to overwrite stack data, eventually
resulting in a program crash, corruption of function parameters or
corruption of function frame and return pointer. This can occur if a
script uses math functions to compute a delay that evaluates to a
float, and typecasting is not done, or if someone uses a string
representation of an integer instead (e.g. "86400" instead of 86400)
This bug was originally found on PHP-4.3.10, verified on 4.4.2 and the
latest php4 snapshot. It took a while to track down what was causing
the weird crashes.
Build options: --disable-cgi
Run from build directory: sapi/cli/php
No php.ini
Reproduce code:
---
$fp = fopen("/dev/zero","r"); // Random stream
while(TRUE){
echo "Start of loop here.\n";
$reads = Array($fp);
$delay = 3.7; // <- Anything but an integer.
$null = NULL;
printf("Waiting for data or %d seconds...\n",$delay);
$result = stream_select($reads, $null, $null, $delay);
if($result){
foreach($reads as $stream){
$data = fread($stream, 1);
printf("Read %d byte(s).\n", strlen($data));
}
}
}
Expected result:
An endless loop reading single ASCII 0 bytes from /dev/zero until
interrupted.
Start of loop here.
Waiting for data or 3 seconds...
Read 1 byte(s).
Start of loop here.
Waiting for data or 3 seconds...
Read 1 byte(s).
...etc...
Actual result:
--
The code seems to run fine for a few iterations, but eventually starts
showing various errors or passing incorrect parameters to functions:
Start of loop here.
Waiting for data or 3 seconds...
Read 1 byte(s).
Start of loop here.
Waiting for data or 3 seconds...
Warning: fread(): supplied argument is not a valid stream resource in
/usr/home/cyberleo/logs/working/crashtest.php on line 12
Read 0 byte(s).
Start of loop here.
Waiting for data or 3 seconds...
Read 1 byte(s).
Start of loop here.
Waiting for data or 3 seconds...
Warning: fread(): supplied argument is not a valid stream resource in
/usr/home/cyberleo/logs/working/crashtest.php on line 12
Read 0 byte(s).
Start of loop here.
Warning: stream_select(): 4 is not a valid stream resource in
/usr/home/cyberleo/logs/working/crashtest.php on line 9
Warning: stream_select(): 4 is not a valid stream resource in
/usr/home/cyberleo/logs/working/crashtest.php on line 9
(Program hangs at this point, no looping)
--
Edit this bug report at http://bugs.php.net/?id=36242&edit=1
#36246 [Opn->Fbk]: Memory problem (double free)
ID: 36246 Updated by: [EMAIL PROTECTED] Reported By: eustaquiorangel at yahoo dot com -Status: Open +Status: Feedback Bug Type: XSLT related Operating System: Linux, Slackware 10.2 (current) PHP Version: 5.1.2 New Comment: To reproduce it we need test.xsl either. Previous Comments: [2006-02-01 13:36:22] eustaquiorangel at yahoo dot com Description: After I use the XSLT extension to process a huge file, I got an error on the Apache error_log and a blank page on the browser. The error is: *** glibc detected *** double free or corruption (fasttop): 0x08236cc8 *** [Wed Feb 01 08:56:12 2006] [notice] child pid 7121 exit signal Aborted (6) Reproduce code: --- http://pastebin.com/533629 Expected result: A regular HTML page and no error on error_log. Actual result: -- Sometimes it becomes blank and after some realoading it works, but *always* with an error message on error_log. I tested the code on all the ways I could but the only solution was downgrade PHP to 4.4.2 with Sablotron support. Then everything run fine (same Apache version, same OS), the only negavite thing is that it takes a lot of time to show the results on the browser, while using PHP 5.1.2 it was very fast. -- Edit this bug report at http://bugs.php.net/?id=36246&edit=1
#36246 [NEW]: Memory problem (double free)
From: eustaquiorangel at yahoo dot com Operating system: Linux, Slackware 10.2 (current) PHP version: 5.1.2 PHP Bug Type: XSLT related Bug description: Memory problem (double free) Description: After I use the XSLT extension to process a huge file, I got an error on the Apache error_log and a blank page on the browser. The error is: *** glibc detected *** double free or corruption (fasttop): 0x08236cc8 *** [Wed Feb 01 08:56:12 2006] [notice] child pid 7121 exit signal Aborted (6) Reproduce code: --- http://pastebin.com/533629 Expected result: A regular HTML page and no error on error_log. Actual result: -- Sometimes it becomes blank and after some realoading it works, but *always* with an error message on error_log. I tested the code on all the ways I could but the only solution was downgrade PHP to 4.4.2 with Sablotron support. Then everything run fine (same Apache version, same OS), the only negavite thing is that it takes a lot of time to show the results on the browser, while using PHP 5.1.2 it was very fast. -- Edit bug report at http://bugs.php.net/?id=36246&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36246&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36246&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36246&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36246&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36246&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36246&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36246&r=needscript Try newer version:http://bugs.php.net/fix.php?id=36246&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36246&r=support Expected behavior:http://bugs.php.net/fix.php?id=36246&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36246&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36246&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36246&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36246&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36246&r=dst IIS Stability:http://bugs.php.net/fix.php?id=36246&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=36246&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=36246&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=36246&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=36246&r=mysqlcfg
#36208 [Com]: Symbols in libphp5.so conflict with symbols in libgd.so and cause apache probs
ID: 36208 Comment by: jakub at gentoo dot org Reported By: hb at gentoo dot x256 dot org Status: Feedback Bug Type: Dynamic loading Operating System: Gentoo Linux x86 PHP Version: 5.1.2 New Comment: patch for 5.0.5: http://bugs.gentoo.org/attachment.cgi?id=78638 patch for 5.1.2, adding 6 additional compatibility symbols exported by libgd: http://bugs.gentoo.org/attachment.cgi?id=78639&action=view Reference Gentoo bug: http://bugs.gentoo.org/show_bug.cgi?id=120908 Should be backported to 4.4.x as well, but that's really upstream job. ;) Previous Comments: [2006-02-01 12:05:33] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. [2006-02-01 11:05:01] hb at gentoo dot x256 dot org Sorry, as I said, I spent over a day tracking down this problem. I submitted a bug report to Gentoo and they told me it was not their problem and that it should be fixed in PHP, which seemed somewhat reasonable. Then I was told that it had to be configured differently, which would require a change in Gentoo, but this problem would remain in other distributions. I just want to fix it so that other people don't have to go through what I did. I will try to make a patch. [2006-02-01 09:16:40] [EMAIL PROTECTED] There is no need to use this kind of language, it will not make us help you faster. That said, we actually do namespace protect those symbols in there by prefixing them with php_gd_. It seems however that some of them are not added yet, see the file main/php_compat.h. Feel free to submit a patch for that file. [2006-02-01 05:33:10] hb at gentoo dot x256 dot org This is a problem with PHP. You can't just tell me to compile it differently because in the real world, when actual users compile and install perl and PHP, they won't know this. There's no warning that I ever saw that tells me not to do this, and then my programs randomly crash, and I spent a whole day trying to work out why. This WILL happen to other people unless you fix YOUR bug, which is exporting non-standard GD symbols with standard names into the dynamic linker namespace. They should be renamed or hidden or set to a different version so they won't collide with the real GD. I guess if you're unwilling to fix it I'll have to get the Gentoo people to either patch PHP or change the portage system so it won't install PHP and mod_perl simultaneously with USE=gd. However, this has the possibility of biting people in other circumstances too. I can't understand why you say it's not your problem. You shouldn't export symbols willy-nilly especially when you modify them from the library you pulled them from originally and don't rename them. [2006-02-01 01:16:12] [EMAIL PROTECTED] In case when you need to compile another apache module that uses gdlib you need to compile php with the system library. (--with-gd=/path/to/system/gdlib) 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/36208 -- Edit this bug report at http://bugs.php.net/?id=36208&edit=1
#36245 [Opn]: SOAP in WDSL incorrect complex type encoding
ID: 36245
User updated by: hans at lintoo dot dk
Reported By: hans at lintoo dot dk
Status: Open
Bug Type: SOAP related
Operating System: FreeBSD 5.4
PHP Version: 5.1.2
New Comment:
switch: Expected result & Actual result... sorry!
Previous Comments:
[2006-02-01 13:02:32] hans at lintoo dot dk
Description:
Please excuse me if this problem is related to my code, i tried all
combinations of coding methods I could think of, but still it did not
return the code I was expecting.
I get the following exception:
SoapFault exception: [soap:Client] Incorrect format for named street
text line
which i believe is due to incorrect coding of the complex types.
You can find the WSDL at:
http://dev.lintoo.net/findaddressservice.wsdl
Reproduce code:
---
http://dev.lintoo.net/findaddressservice.wsdl', array(
'soap_version' => SOAP_1_1,
"trace" => 1,
"exceptions" => 1
));
class FindAddressAccessRequest {
public $NamedStreetTextInput;
public $StreetBuildingIdentifier;
public $MunicipalitySearch;
public $DistrictSearch;
public $DistrictSubdivisionSearch;
}
$FindAddressAccessRequest = new FindAddressAccessRequest();
$FindAddressAccessRequest->NamedStreetTextInput = "Hjallesevej";
$FindAddressAccessRequest->StreetBuildingIdentifier = "34";
$findAddressParam = array('NamedStreetTextInput' => "Hjallesevej",
'StreetBuildingIdentifier' => '34');
$client->FindAddressAccess($FindAddressAccessRequest);
print($client->__getLastRequest());
?>
Expected result:
Hjallesevej
34
Actual result:
--
Hjallesevej
34
--
Edit this bug report at http://bugs.php.net/?id=36245&edit=1
#36245 [NEW]: SOAP in WDSL incorrect complex type encoding
From: hans at lintoo dot dk
Operating system: FreeBSD 5.4
PHP version: 5.1.2
PHP Bug Type: SOAP related
Bug description: SOAP in WDSL incorrect complex type encoding
Description:
Please excuse me if this problem is related to my code, i tried all
combinations of coding methods I could think of, but still it did not
return the code I was expecting.
I get the following exception:
SoapFault exception: [soap:Client] Incorrect format for named street text
line
which i believe is due to incorrect coding of the complex types.
You can find the WSDL at:
http://dev.lintoo.net/findaddressservice.wsdl
Reproduce code:
---
http://dev.lintoo.net/findaddressservice.wsdl', array(
'soap_version' => SOAP_1_1,
"trace" => 1,
"exceptions" => 1
));
class FindAddressAccessRequest {
public $NamedStreetTextInput;
public $StreetBuildingIdentifier;
public $MunicipalitySearch;
public $DistrictSearch;
public $DistrictSubdivisionSearch;
}
$FindAddressAccessRequest = new FindAddressAccessRequest();
$FindAddressAccessRequest->NamedStreetTextInput = "Hjallesevej";
$FindAddressAccessRequest->StreetBuildingIdentifier = "34";
$findAddressParam = array('NamedStreetTextInput' => "Hjallesevej",
'StreetBuildingIdentifier' => '34');
$client->FindAddressAccess($FindAddressAccessRequest);
print($client->__getLastRequest());
?>
Expected result:
Hjallesevej
34
Actual result:
--
Hjallesevej
34
--
Edit bug report at http://bugs.php.net/?id=36245&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=36245&r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=36245&r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=36245&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=36245&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=36245&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=36245&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=36245&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=36245&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=36245&r=support
Expected behavior:http://bugs.php.net/fix.php?id=36245&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=36245&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=36245&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=36245&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36245&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=36245&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=36245&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=36245&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=36245&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=36245&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=36245&r=mysqlcfg
#36206 [Opn->Fbk]: LDAP in nsswitch.conf causes segfault when resolving hostnames in PHP
ID: 36206 Updated by: [EMAIL PROTECTED] Reported By: arnout at argeweb dot nl -Status: Open +Status: Feedback Bug Type: CGI related Operating System: freeBSD 5.4 PHP Version: 5.1.2 New Comment: Please try to run `top`, `ps aux` and `host example.com`. Do they work fine or segfault too? I'm asking because of this: http://lists.freebsd.org/pipermail/freebsd-bugs/2004-April/006201.html Previous Comments: [2006-01-30 12:25:00] arnout at argeweb dot nl This just in: The script does not terminate. It ends like it's supposed to. The segfault is put out when the scripts terminates. I don't know if it's a child process that dies, or that the segfault resides in a buffer untill termination or something. [EMAIL PROTECTED]: / # echo "" | php 64.246.30.37Segmentation fault (core dumped) I seem to have judged to fast before. But still: I can't surpress this error. It's ugly! [2006-01-30 12:01:41] arnout at argeweb dot nl status change [2006-01-30 12:00:33] oersoep at gmail dot com #0 0x in ?? () #1 0x292ff7a5 in ?? () from /usr/local/lib/nss_ldap.so.1 #2 0x2930a4c0 in ?? () from /usr/local/lib/nss_ldap.so.1 #3 0x2817d760 in ?? () from /libexec/ld-elf.so.1 #4 0x2817d5d8 in ?? () from /libexec/ld-elf.so.1 #5 0x292ff740 in ?? () from /usr/local/lib/nss_ldap.so.1 #6 0x28162730 in _rtld_error () from /libexec/ld-elf.so.1 #7 0x293086c9 in _fini () from /usr/local/lib/nss_ldap.so.1 #8 0x2816380b in find_symdef () from /libexec/ld-elf.so.1 #9 0x28163e6a in dlclose () from /libexec/ld-elf.so.1 #10 0x2845b53c in _nsdbtput () from /lib/libc.so.5 #11 0x2845aef0 in endhostent () from /lib/libc.so.5 #12 0x2845b5bb in _nsdbtput () from /lib/libc.so.5 #13 0x2847e1a5 in __cxa_finalize () from /lib/libc.so.5 #14 0x2847dec6 in exit () from /lib/libc.so.5 #15 0x08130cc5 in main () [2006-01-30 11:55:17] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. [2006-01-30 11:41:10] arnout at argeweb dot nl Description: Any hostname resolve in PHP causes a segmentation fault. It only happens when this file contains the ldap keyword. When removed, everything works fine. Everything works great when using modphp. It only happens when using the executable. [EMAIL PROTECTED]: / # cat /etc/nsswitch.conf group: files ldap group_compat: nis hosts: files dns networks: files passwd: files passwd_compat: nis shells: files We've seen it on two seperate systems. It's on PHP versions 5.0.5, 5.1.1 and 5.1.2 Server #1: openldap 2.2.30 nss_ldap 1.244 php 5.0.5 FreeBSD 5.4-RELEASE-p8 Server #2: nss_ldap-1.239 openldap-client-2.2.27 php 5.1.2 FreeBSD 5.4-RELEASE-p8 Reproduce code: --- [EMAIL PROTECTED]: / # echo "" | php [EMAIL PROTECTED]: / # echo "" | php #!/usr/local/bin/php Expected result: An IP-address and an error because the mysql host doesn't exist. Actual result: -- Segmentation fault on any line that resolves a hostname. -- Edit this bug report at http://bugs.php.net/?id=36206&edit=1
#36235 [Csd]: ocicolumnname delivers empty results before a succesfull ocifetch
ID: 36235 User updated by: Olaf dot Imig at bifab dot de Reported By: Olaf dot Imig at bifab dot de Status: Closed Bug Type: OCI8 related Operating System: SUN OS PHP Version: 5CVS-2006-01-31 (CVS) New Comment: Thank you for your bugfix, it works fine. Previous Comments: [2006-01-31 19:40:11] [EMAIL PROTECTED] This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2006-01-31 19:13:23] Olaf dot Imig at bifab dot de Description: Because of bug 36096 I used this snapshot. ociresult works fine, but the function ocicolumnname delivers empty results before a succesfull call of ocifetch or when the resultset is empty. Version 5.0.5 or 5.1.2 works fine in this case. -- Edit this bug report at http://bugs.php.net/?id=36235&edit=1
#36208 [Opn->Fbk]: Symbols in libphp5.so conflict with symbols in libgd.so and cause apache probs
ID: 36208 Updated by: [EMAIL PROTECTED] Reported By: hb at gentoo dot x256 dot org -Status: Open +Status: Feedback Bug Type: Dynamic loading Operating System: Gentoo Linux x86 PHP Version: 5.1.2 New Comment: Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. Previous Comments: [2006-02-01 11:05:01] hb at gentoo dot x256 dot org Sorry, as I said, I spent over a day tracking down this problem. I submitted a bug report to Gentoo and they told me it was not their problem and that it should be fixed in PHP, which seemed somewhat reasonable. Then I was told that it had to be configured differently, which would require a change in Gentoo, but this problem would remain in other distributions. I just want to fix it so that other people don't have to go through what I did. I will try to make a patch. [2006-02-01 09:16:40] [EMAIL PROTECTED] There is no need to use this kind of language, it will not make us help you faster. That said, we actually do namespace protect those symbols in there by prefixing them with php_gd_. It seems however that some of them are not added yet, see the file main/php_compat.h. Feel free to submit a patch for that file. [2006-02-01 05:33:10] hb at gentoo dot x256 dot org This is a problem with PHP. You can't just tell me to compile it differently because in the real world, when actual users compile and install perl and PHP, they won't know this. There's no warning that I ever saw that tells me not to do this, and then my programs randomly crash, and I spent a whole day trying to work out why. This WILL happen to other people unless you fix YOUR bug, which is exporting non-standard GD symbols with standard names into the dynamic linker namespace. They should be renamed or hidden or set to a different version so they won't collide with the real GD. I guess if you're unwilling to fix it I'll have to get the Gentoo people to either patch PHP or change the portage system so it won't install PHP and mod_perl simultaneously with USE=gd. However, this has the possibility of biting people in other circumstances too. I can't understand why you say it's not your problem. You shouldn't export symbols willy-nilly especially when you modify them from the library you pulled them from originally and don't rename them. [2006-02-01 01:16:12] [EMAIL PROTECTED] In case when you need to compile another apache module that uses gdlib you need to compile php with the system library. (--with-gd=/path/to/system/gdlib) [2006-01-30 12:45:16] hb at gentoo dot x256 dot org Description: PHP includes a tweaked GD library. It is not compatible with libgd. The problem is, it uses the same symbols (i.e. function names) as libgd and exports them from its shared object. When I load mod_php and mod_perl into Apache, mod_perl programs using the GD library end up sometimes calling PHP's modified GD routines and sometimes not. This causes Apache children to crash semi-randomly. Since the PHP GD library is not compatible with libgd itself (and because it's likely to be co-existing with a different version of libgd on the system, regardless of tweaks), the symbols (functions and others) should be renamed. Perhaps with a PHP_ prefix. This way there will be no dynamic loading collision and PHP/PERL will be able to co-exist in Apache children without damage. I worked around this by recompiling libPHP with external GD library support. However, it took me several hours to diagnose the exact problem. I have also been bitten by this once before already. I recommend fixing this in PHP4 as well as PHP5. Reproduce code: --- This PERL/MASON script crashes every time if libphp5.so is loaded as an Apache module, but works perfectly otherwise: <%INIT> use strict; use GD::Graph::lines; my $tgraph = GD::Graph::lines->new(800, 800); my $tgd = $tgraph->plot([ [ "a" ], [ 0 ] ]); print $tgd->png(); return; Expected result: Blank graph. Actual result: -- Zero-sized reply. GLIBC memory corruption reported upon free() in error_log. -- Edit this bug report at http://b
#36233 [Opn->Bgs]: Can not get php to compile
ID: 36233 Updated by: [EMAIL PROTECTED] Reported By: rwheeler at artifact-software dot com -Status: Open +Status: Bogus Bug Type: Compile Failure Operating System: Mandriva 2006 x86_64 PHP Version: 5.1.2 New Comment: Not PHP problem. See http://bugs.mysql.com/bug.php?id=13159 Previous Comments: [2006-01-31 17:57:52] rwheeler at artifact-software dot com Description: In configure I get a message about bison Configuring Zend checking for bison version... (cached) invalid configure: warning: bison versions supported for regeneration of the Zend/PHP parsers: 1.28 1.35 1.75 1.875 2.0 2.1 (found: none). But it is installed [ php-5.1.2]# bison --version bison (GNU Bison) 2.0 Written by Robert Corbett and Richard Stallman. Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. [ php-5.1.2]# urpmq -r -cf bison bison-2.0-3mdk.x86_64 In make, I get a ton of warnings about pointer signedness in many modules. For example: In file included from /home/rwheeler/0distrib/php-5.1.2/regex/regcomp.c:14: /home/rwheeler/0distrib/php-5.1.2/regex/cclass.h:7: warning: pointer targets in initialization differ in signedness Make finally dies with /usr/bin/ld: /usr/lib64/mysql/libmysqlclient.a(libmysql.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC /usr/lib64/mysql/libmysqlclient.a: could not read symbols: Bad value collect2: ld returned 1 exit status make: *** [libphp5.la] Error 1 The MySQL was installed using the 64 bit rpm from mysql.com and seems to work fine but I may not be testing libmysqlclient. This is probably a series of bugs but I can not figure out how to separate out the various errors or determine the interaction or dependencies between errors. Expected result: I expect it to compile clean and install and run Actual result: -- It does not make. -- Edit this bug report at http://bugs.php.net/?id=36233&edit=1
#36242 [Opn->Csd]: Weak type checking on stream_select() allows stack corruption
ID: 36242
Updated by: [EMAIL PROTECTED]
Reported By: cyberleo at cyberleo dot net
-Status: Open
+Status: Closed
Bug Type: Streams related
Operating System: FreeBSD 4.10-REL
PHP Version: 4CVS-2006-02-01 (snap)
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2006-02-01 10:41:29] cyberleo at cyberleo dot net
Description:
Weak type checking on stream_select() allows stack corruption.
Passing a value that is not an integer to stream_select()'s fourth
parameter, tv_sec, appears to overwrite stack data, eventually
resulting in a program crash, corruption of function parameters or
corruption of function frame and return pointer. This can occur if a
script uses math functions to compute a delay that evaluates to a
float, and typecasting is not done, or if someone uses a string
representation of an integer instead (e.g. "86400" instead of 86400)
This bug was originally found on PHP-4.3.10, verified on 4.4.2 and the
latest php4 snapshot. It took a while to track down what was causing
the weird crashes.
Build options: --disable-cgi
Run from build directory: sapi/cli/php
No php.ini
Reproduce code:
---
$fp = fopen("/dev/zero","r"); // Random stream
while(TRUE){
echo "Start of loop here.\n";
$reads = Array($fp);
$delay = 3.7; // <- Anything but an integer.
$null = NULL;
printf("Waiting for data or %d seconds...\n",$delay);
$result = stream_select($reads, $null, $null, $delay);
if($result){
foreach($reads as $stream){
$data = fread($stream, 1);
printf("Read %d byte(s).\n", strlen($data));
}
}
}
Expected result:
An endless loop reading single ASCII 0 bytes from /dev/zero until
interrupted.
Start of loop here.
Waiting for data or 3 seconds...
Read 1 byte(s).
Start of loop here.
Waiting for data or 3 seconds...
Read 1 byte(s).
...etc...
Actual result:
--
The code seems to run fine for a few iterations, but eventually starts
showing various errors or passing incorrect parameters to functions:
Start of loop here.
Waiting for data or 3 seconds...
Read 1 byte(s).
Start of loop here.
Waiting for data or 3 seconds...
Warning: fread(): supplied argument is not a valid stream resource in
/usr/home/cyberleo/logs/working/crashtest.php on line 12
Read 0 byte(s).
Start of loop here.
Waiting for data or 3 seconds...
Read 1 byte(s).
Start of loop here.
Waiting for data or 3 seconds...
Warning: fread(): supplied argument is not a valid stream resource in
/usr/home/cyberleo/logs/working/crashtest.php on line 12
Read 0 byte(s).
Start of loop here.
Warning: stream_select(): 4 is not a valid stream resource in
/usr/home/cyberleo/logs/working/crashtest.php on line 9
Warning: stream_select(): 4 is not a valid stream resource in
/usr/home/cyberleo/logs/working/crashtest.php on line 9
(Program hangs at this point, no looping)
--
Edit this bug report at http://bugs.php.net/?id=36242&edit=1
#36243 [Bgs]: Weak type checking on stream_select() allows stack corruption (php5)
ID: 36243
User updated by: cyberleo at cyberleo dot net
Reported By: cyberleo at cyberleo dot net
Status: Bogus
Bug Type: Streams related
Operating System: FreeBSD 4.10-REL
PHP Version: 5CVS-2006-02-01 (snap)
New Comment:
I wasn't sure, because the two versions behave so differently, and the
PHP version selector only allows for one.
Thanks.
Previous Comments:
[2006-02-01 11:17:39] [EMAIL PROTECTED]
No need to report it twice.
Dup of bug #36242.
[2006-02-01 10:54:34] cyberleo at cyberleo dot net
Description:
This bug is similar to http://bugs.php.net/36242 however, the symptoms
are different.
Weak type checking on stream_select() allows stack corruption.
Passing a value that is not an integer to stream_select()'s fourth
parameter, tv_sec, appears to overwrite stack data.
This results in strange, but consistent, modification of parameters
passed to later functions. The corruption does not appear to be
cumulative. This can occur if a script uses math functions to compute a
delay that evaluates to a float, and typecasting is not done, or if
someone uses a string representation of an integer instead (e.g.
"86400" instead of 86400)
Build options: --disable-cgi
Run from build directory: sapi/cli/php
No php.ini
Reproduce code:
---
$fp = fopen("/dev/zero","r"); // Random stream
while(TRUE){
echo "Start of loop here.\n";
$reads = Array($fp);
$delay = 3.7; // <- Anything but an integer.
$null = NULL;
printf("Waiting for data or %d seconds...\n",$delay);
$result = stream_select($reads, $null, $null, $delay);
if($result){
foreach($reads as $stream){
$data = fread($stream, 1);
printf("Read %d byte(s).\n", strlen($data));
}
}
}
Expected result:
An endless loop reading single ASCII 0 bytes from /dev/zero until
interrupted.
Start of loop here.
Waiting for data or 3 seconds...
Read 1 byte(s).
Start of loop here.
Waiting for data or 3 seconds...
Read 1 byte(s).
...etc...
Actual result:
--
Endless loop of reading 17 bytes. (My test run)
Start of loop here.
Waiting for data or 3 seconds...
Read 17 byte(s).
Start of loop here.
Waiting for data or 3 seconds...
Read 17 byte(s).
--
Edit this bug report at http://bugs.php.net/?id=36243&edit=1
#36243 [NEW]: Weak type checking on stream_select() allows stack corruption (php5)
From: cyberleo at cyberleo dot net
Operating system: FreeBSD 4.10-REL
PHP version: 5CVS-2006-02-01 (snap)
PHP Bug Type: Streams related
Bug description: Weak type checking on stream_select() allows stack corruption
(php5)
Description:
This bug is similar to http://bugs.php.net/36242 however, the symptoms are
different.
Weak type checking on stream_select() allows stack corruption.
Passing a value that is not an integer to stream_select()'s fourth
parameter, tv_sec, appears to overwrite stack data.
This results in strange, but consistent, modification of parameters passed
to later functions. The corruption does not appear to be cumulative. This
can occur if a script uses math functions to compute a delay that
evaluates to a float, and typecasting is not done, or if someone uses a
string representation of an integer instead (e.g. "86400" instead of
86400)
Build options: --disable-cgi
Run from build directory: sapi/cli/php
No php.ini
Reproduce code:
---
$fp = fopen("/dev/zero","r"); // Random stream
while(TRUE){
echo "Start of loop here.\n";
$reads = Array($fp);
$delay = 3.7; // <- Anything but an integer.
$null = NULL;
printf("Waiting for data or %d seconds...\n",$delay);
$result = stream_select($reads, $null, $null, $delay);
if($result){
foreach($reads as $stream){
$data = fread($stream, 1);
printf("Read %d byte(s).\n", strlen($data));
}
}
}
Expected result:
An endless loop reading single ASCII 0 bytes from /dev/zero until
interrupted.
Start of loop here.
Waiting for data or 3 seconds...
Read 1 byte(s).
Start of loop here.
Waiting for data or 3 seconds...
Read 1 byte(s).
...etc...
Actual result:
--
Endless loop of reading 17 bytes. (My test run)
Start of loop here.
Waiting for data or 3 seconds...
Read 17 byte(s).
Start of loop here.
Waiting for data or 3 seconds...
Read 17 byte(s).
--
Edit bug report at http://bugs.php.net/?id=36243&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=36243&r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=36243&r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=36243&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=36243&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=36243&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=36243&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=36243&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=36243&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=36243&r=support
Expected behavior:http://bugs.php.net/fix.php?id=36243&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=36243&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=36243&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=36243&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36243&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=36243&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=36243&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=36243&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=36243&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=36243&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=36243&r=mysqlcfg
#36243 [Opn->Bgs]: Weak type checking on stream_select() allows stack corruption (php5)
ID: 36243
Updated by: [EMAIL PROTECTED]
Reported By: cyberleo at cyberleo dot net
-Status: Open
+Status: Bogus
Bug Type: Streams related
Operating System: FreeBSD 4.10-REL
PHP Version: 5CVS-2006-02-01 (snap)
New Comment:
No need to report it twice.
Dup of bug #36242.
Previous Comments:
[2006-02-01 10:54:34] cyberleo at cyberleo dot net
Description:
This bug is similar to http://bugs.php.net/36242 however, the symptoms
are different.
Weak type checking on stream_select() allows stack corruption.
Passing a value that is not an integer to stream_select()'s fourth
parameter, tv_sec, appears to overwrite stack data.
This results in strange, but consistent, modification of parameters
passed to later functions. The corruption does not appear to be
cumulative. This can occur if a script uses math functions to compute a
delay that evaluates to a float, and typecasting is not done, or if
someone uses a string representation of an integer instead (e.g.
"86400" instead of 86400)
Build options: --disable-cgi
Run from build directory: sapi/cli/php
No php.ini
Reproduce code:
---
$fp = fopen("/dev/zero","r"); // Random stream
while(TRUE){
echo "Start of loop here.\n";
$reads = Array($fp);
$delay = 3.7; // <- Anything but an integer.
$null = NULL;
printf("Waiting for data or %d seconds...\n",$delay);
$result = stream_select($reads, $null, $null, $delay);
if($result){
foreach($reads as $stream){
$data = fread($stream, 1);
printf("Read %d byte(s).\n", strlen($data));
}
}
}
Expected result:
An endless loop reading single ASCII 0 bytes from /dev/zero until
interrupted.
Start of loop here.
Waiting for data or 3 seconds...
Read 1 byte(s).
Start of loop here.
Waiting for data or 3 seconds...
Read 1 byte(s).
...etc...
Actual result:
--
Endless loop of reading 17 bytes. (My test run)
Start of loop here.
Waiting for data or 3 seconds...
Read 17 byte(s).
Start of loop here.
Waiting for data or 3 seconds...
Read 17 byte(s).
--
Edit this bug report at http://bugs.php.net/?id=36243&edit=1
#36244 [Opn->Fbk]: Importing xsl:output breaks encoding attribute value
ID: 36244 Updated by: [EMAIL PROTECTED] Reported By: maximgb at is-a dot ru -Status: Open +Status: Feedback Bug Type: XSLT related Operating System: windows xp sp2 PHP Version: 5.1.2 New Comment: Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. Previous Comments: [2006-02-01 11:14:41] maximgb at is-a dot ru Description: I have two stylesheets first one with xsl:output tag only, where method="XML" and encoding="windows-1251", second one which imports the first one and where all other templates are stored. When I use then all russian characters after transformation become XML entities, when I use -- Edit this bug report at http://bugs.php.net/?id=36244&edit=1
#36241 [Opn->Fbk]: explode causes segm fault
ID: 36241 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: Linux on PowerPC PHP Version: 6CVS-2006-02-01 (CVS) New Comment: Can't reproduce on i386 both in Unicode and regular modes. Previous Comments: [2006-02-01 09:23:20] [EMAIL PROTECTED] Description: This simple script causes a segm fault php_explode (delim=0xed82208 "", delim_len=2147450528, str=0x3c , str_len=249048784, str_type=0 '\0', return_value=0x106ce240, limit=-1) at zend_operators.h:215 215 char ne = needle[needle_len-1]; (gdb) bt #0 php_explode (delim=0xed82208 "", delim_len=2147450528, str=0x3c , str_len=249048784, str_type=0 '\0', return_value=0x106ce240, limit=-1) at zend_operators.h:215 #1 0x1022b380 in zif_explode (ht=2, return_value=0x106ce240, return_value_ptr=, this_ptr=, return_value_used=) at /home/cvs/php/php-src/ext/standard/string.c:1137 #2 0x1030b414 in zend_do_fcall_common_helper_SPEC (execute_data=0x7fff7f80) at zend_vm_execute.h:201 #3 0x1030a8e4 in execute (op_array=0x106ce0e8) at zend_vm_execute.h:92 #4 0x102dc0b8 in zend_execute_scripts (type=8, retval=0x1022b380, file_count=3) at /home/cvs/php/php-src/Zend/zend.c:1806 #5 0x1027bf7c in php_execute_script (primary_file=0x7fffa4e4) at /home/cvs/php/php-src/main/main.c:1846 #6 0x103d6348 in main (argc=3, argv=0x7fffaac4) at /home/cvs/php/php-src/sapi/cli/php_cli.c:1090 -- Edit this bug report at http://bugs.php.net/?id=36241&edit=1
#36244 [NEW]: Importing xsl:output breaks encoding attribute value
From: maximgb at is-a dot ru Operating system: windows xp sp2 PHP version: 5.1.2 PHP Bug Type: XSLT related Bug description: Importing xsl:output breaks encoding attribute value Description: I have two stylesheets first one with xsl:output tag only, where method="XML" and encoding="windows-1251", second one which imports the first one and where all other templates are stored. When I use then all russian characters after transformation become XML entities, when I use -- Edit bug report at http://bugs.php.net/?id=36244&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36244&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36244&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36244&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36244&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36244&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36244&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36244&r=needscript Try newer version:http://bugs.php.net/fix.php?id=36244&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36244&r=support Expected behavior:http://bugs.php.net/fix.php?id=36244&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36244&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36244&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36244&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36244&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36244&r=dst IIS Stability:http://bugs.php.net/fix.php?id=36244&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=36244&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=36244&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=36244&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=36244&r=mysqlcfg
#36208 [Opn]: Symbols in libphp5.so conflict with symbols in libgd.so and cause apache probs
ID: 36208 User updated by: hb at gentoo dot x256 dot org Reported By: hb at gentoo dot x256 dot org Status: Open Bug Type: Dynamic loading Operating System: Gentoo Linux x86 PHP Version: 5.1.2 New Comment: Sorry, as I said, I spent over a day tracking down this problem. I submitted a bug report to Gentoo and they told me it was not their problem and that it should be fixed in PHP, which seemed somewhat reasonable. Then I was told that it had to be configured differently, which would require a change in Gentoo, but this problem would remain in other distributions. I just want to fix it so that other people don't have to go through what I did. I will try to make a patch. Previous Comments: [2006-02-01 09:16:40] [EMAIL PROTECTED] There is no need to use this kind of language, it will not make us help you faster. That said, we actually do namespace protect those symbols in there by prefixing them with php_gd_. It seems however that some of them are not added yet, see the file main/php_compat.h. Feel free to submit a patch for that file. [2006-02-01 05:33:10] hb at gentoo dot x256 dot org This is a problem with PHP. You can't just tell me to compile it differently because in the real world, when actual users compile and install perl and PHP, they won't know this. There's no warning that I ever saw that tells me not to do this, and then my programs randomly crash, and I spent a whole day trying to work out why. This WILL happen to other people unless you fix YOUR bug, which is exporting non-standard GD symbols with standard names into the dynamic linker namespace. They should be renamed or hidden or set to a different version so they won't collide with the real GD. I guess if you're unwilling to fix it I'll have to get the Gentoo people to either patch PHP or change the portage system so it won't install PHP and mod_perl simultaneously with USE=gd. However, this has the possibility of biting people in other circumstances too. I can't understand why you say it's not your problem. You shouldn't export symbols willy-nilly especially when you modify them from the library you pulled them from originally and don't rename them. [2006-02-01 01:16:12] [EMAIL PROTECTED] In case when you need to compile another apache module that uses gdlib you need to compile php with the system library. (--with-gd=/path/to/system/gdlib) [2006-01-30 12:45:16] hb at gentoo dot x256 dot org Description: PHP includes a tweaked GD library. It is not compatible with libgd. The problem is, it uses the same symbols (i.e. function names) as libgd and exports them from its shared object. When I load mod_php and mod_perl into Apache, mod_perl programs using the GD library end up sometimes calling PHP's modified GD routines and sometimes not. This causes Apache children to crash semi-randomly. Since the PHP GD library is not compatible with libgd itself (and because it's likely to be co-existing with a different version of libgd on the system, regardless of tweaks), the symbols (functions and others) should be renamed. Perhaps with a PHP_ prefix. This way there will be no dynamic loading collision and PHP/PERL will be able to co-exist in Apache children without damage. I worked around this by recompiling libPHP with external GD library support. However, it took me several hours to diagnose the exact problem. I have also been bitten by this once before already. I recommend fixing this in PHP4 as well as PHP5. Reproduce code: --- This PERL/MASON script crashes every time if libphp5.so is loaded as an Apache module, but works perfectly otherwise: <%INIT> use strict; use GD::Graph::lines; my $tgraph = GD::Graph::lines->new(800, 800); my $tgd = $tgraph->plot([ [ "a" ], [ 0 ] ]); print $tgd->png(); return; Expected result: Blank graph. Actual result: -- Zero-sized reply. GLIBC memory corruption reported upon free() in error_log. -- Edit this bug report at http://bugs.php.net/?id=36208&edit=1
#36242 [NEW]: Weak type checking on stream_select() allows stack corruption
From: cyberleo at cyberleo dot net
Operating system: FreeBSD 4.10-REL
PHP version: 4CVS-2006-02-01 (snap)
PHP Bug Type: Streams related
Bug description: Weak type checking on stream_select() allows stack corruption
Description:
Weak type checking on stream_select() allows stack corruption.
Passing a value that is not an integer to stream_select()'s fourth
parameter, tv_sec, appears to overwrite stack data, eventually resulting
in a program crash, corruption of function parameters or corruption of
function frame and return pointer. This can occur if a script uses math
functions to compute a delay that evaluates to a float, and typecasting is
not done, or if someone uses a string representation of an integer instead
(e.g. "86400" instead of 86400)
This bug was originally found on PHP-4.3.10, verified on 4.4.2 and the
latest php4 snapshot. It took a while to track down what was causing the
weird crashes.
Build options: --disable-cgi
Run from build directory: sapi/cli/php
No php.ini
Reproduce code:
---
$fp = fopen("/dev/zero","r"); // Random stream
while(TRUE){
echo "Start of loop here.\n";
$reads = Array($fp);
$delay = 3.7; // <- Anything but an integer.
$null = NULL;
printf("Waiting for data or %d seconds...\n",$delay);
$result = stream_select($reads, $null, $null, $delay);
if($result){
foreach($reads as $stream){
$data = fread($stream, 1);
printf("Read %d byte(s).\n", strlen($data));
}
}
}
Expected result:
An endless loop reading single ASCII 0 bytes from /dev/zero until
interrupted.
Start of loop here.
Waiting for data or 3 seconds...
Read 1 byte(s).
Start of loop here.
Waiting for data or 3 seconds...
Read 1 byte(s).
...etc...
Actual result:
--
The code seems to run fine for a few iterations, but eventually starts
showing various errors or passing incorrect parameters to functions:
Start of loop here.
Waiting for data or 3 seconds...
Read 1 byte(s).
Start of loop here.
Waiting for data or 3 seconds...
Warning: fread(): supplied argument is not a valid stream resource in
/usr/home/cyberleo/logs/working/crashtest.php on line 12
Read 0 byte(s).
Start of loop here.
Waiting for data or 3 seconds...
Read 1 byte(s).
Start of loop here.
Waiting for data or 3 seconds...
Warning: fread(): supplied argument is not a valid stream resource in
/usr/home/cyberleo/logs/working/crashtest.php on line 12
Read 0 byte(s).
Start of loop here.
Warning: stream_select(): 4 is not a valid stream resource in
/usr/home/cyberleo/logs/working/crashtest.php on line 9
Warning: stream_select(): 4 is not a valid stream resource in
/usr/home/cyberleo/logs/working/crashtest.php on line 9
(Program hangs at this point, no looping)
--
Edit bug report at http://bugs.php.net/?id=36242&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=36242&r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=36242&r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=36242&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=36242&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=36242&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=36242&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=36242&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=36242&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=36242&r=support
Expected behavior:http://bugs.php.net/fix.php?id=36242&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=36242&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=36242&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=36242&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36242&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=36242&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=36242&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=36242&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=36242&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=36242&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=36242&r=mysqlcfg
#36236 [Opn->Bgs]: zziplib module requires zzlib >= 0.10.6.
ID: 36236
Updated by: [EMAIL PROTECTED]
Reported By: aranna at free dot fr
-Status: Open
+Status: Bogus
Bug Type: ZZiplib Related
Operating System: RHE3
PHP Version: 5.1.2
New Comment:
Can't reproduce.
Also, please report PECL/zip problems to PECL bug system.
Thanks.
Previous Comments:
[2006-01-31 23:03:51] aranna at free dot fr
| #define HAVE_XSL 1
| /* end confdefs.h. */
|
| /* Override any gcc2 internal prototype to avoid an error. */
| #ifdef __cplusplus
| extern "C"
| #endif
| /* We use char because int might match the return type of a gcc2
|builtin and then its argument prototype would still apply. */
| char zzip_open ();
| int
| main ()
| {
| zzip_open ();
| ;
| return 0;
| }
configure:124745: result: no
configure:124765: error: zziplib module requires zzlib >= 0.10.6.
[2006-01-31 22:57:52] aranna at free dot fr
Description:
zziplib module requires zzlib >= 0.10.6 when compiling PHP 5.1.2 with
--with-zip option.
Actually zziplib Version 0.13.38 installed (../../bins/unzzip.c version
zziplib 0.13.38)
Actual result:
--
checking for EXSLT support... found
checking for ZIP support... yes
checking for zzip_open in -lzzip... no
configure: error: zziplib module requires zzlib >= 0.10.6.
--
Edit this bug report at http://bugs.php.net/?id=36236&edit=1
#36237 [Opn->Bgs]: error with PDO
ID: 36237 Updated by: [EMAIL PROTECTED] Reported By: monflomai at yahoo dot es -Status: Open +Status: Bogus Bug Type: Compile Failure Operating System: whitebox linux PHP Version: 5.1.2 New Comment: Don't use whitespaces in the path. Previous Comments: [2006-02-01 00:35:03] monflomai at yahoo dot es Description: thats happen at the moment compile (./configure) I don't know why Reproduce code: --- checking whether to enable PDO support... yes /bin/sed: can't read /home/moncho/Packs: No such file or directory /bin/sed: can't read Actuales/php-5.1.2/ext/pdo/Makefile.frag: No such file or directory checking for PDO_DBLIB support via FreeTDS... no checking for Firebird support for PDO... no checking for MySQL support for PDO... no checking Oracle OCI support for PDO... no checking for ODBC v3 support for PDO... no checking for PostgreSQL support for PDO... no checking for sqlite 3 driver for PDO... yes checking for PDO includes... checking for PDO includes... ./configure: line 76268: test: /home/moncho/Packs: binary operator expected ./configure: line 76270: test: /home/moncho/Packs: binary operator expected configure: error: Cannot find php_pdo_driver.h. Actual result: -- Esta es una mierda no liberen paquetes hasta estar seguros que no son betas o lo que sea -- Edit this bug report at http://bugs.php.net/?id=36237&edit=1
#36223 [Csd]: curl bypasses open_basedir restrictions
ID: 36223 Updated by: [EMAIL PROTECTED] Reported By: stevewest15 at yahoo dot com Status: Closed Bug Type: Safe Mode/open_basedir Operating System: Redhat Enterprise 3.6 PHP Version: 4.4.2 New Comment: Feel free to try snapshots, that's why they are packaged. You don't have to *INSTALL* a snapshot to test it. Previous Comments: [2006-02-01 09:06:45] stevewest15 at yahoo dot com > This bug has been fixed in CVS. But that is what was claimed with this release of 4.4.2. This is why we upgraded to 4.4.2. I'm not sure about using a CVS version on production servers but I hope a final version with this fix will be coming out soon. thx, SW [2006-01-31 11:57:54] [EMAIL PROTECTED] This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2006-01-31 11:18:59] stevewest15 at yahoo dot com Description: PHP 4.4.2 still has the bug which allows CURL to bypass open_basedir restrictions. Your release notes for 4.4.2 state that it has been fixed...but it hasn't! :-( Here is the configure line for PHP: './configure' '--localstatedir=/var/hsphere/php' '--with-apxs=/hsphere/shared/apache/bin/apxs' '--with-openssl=/usr' '--with-zlib=/usr' '--with-zlib-dir=/usr' '--with-bz2=/usr' '--enable-calendar' '--with-jpeg-dir=/hsphere/shared' '--enable-ftp' '--with-gd' '--with-ttf' '--with-freetype-dir=/hsphere/shared' '--enable-gd-native-ttf' '--with-png-dir=/hsphere/shared' '--with-gettext=/hsphere/shared' '--with-imap=/hsphere/shared' '--with-mysql=//usr' '--with-pgsql=//usr' '--with-curl=/hsphere/shared' '--with-curlwrappers' '--with-mhash=/hsphere/shared' '--with-mcrypt=/hsphere/shared' '--with-iconv=/hsphere/shared' '--enable-sockets' '--with-zip=/hsphere/shared' '--enable-versioning' '--enable-track-vars' '--enable-trans-sid' '--enable-bcmath' '--enable-mbstring' '--disable-debug' '--enable-pspell' '--enable-memory-limit' '--disable-files' Changes to php.ini made: open_basedir = /home/hsphere/shared/apache/htdocs/:/usr/local/lib/php/:/tmp/ disable_functions = "pack,system" Please fix this Reproduce code: --- Expected result: It should say that open_basedir restrictions are in affect and that it couldn't retrieve file. Actual result: -- When the above code is run, it actually retrieves my /etc/snmpd.conf and displays it's content in my browser. BIG SECURITY concern! -- Edit this bug report at http://bugs.php.net/?id=36223&edit=1
#36241 [NEW]: explode causes segm fault
From: [EMAIL PROTECTED] Operating system: Linux on PowerPC PHP version: 6CVS-2006-02-01 (CVS) PHP Bug Type: Reproducible crash Bug description: explode causes segm fault Description: This simple script causes a segm fault php_explode (delim=0xed82208 "", delim_len=2147450528, str=0x3c , str_len=249048784, str_type=0 '\0', return_value=0x106ce240, limit=-1) at zend_operators.h:215 215 char ne = needle[needle_len-1]; (gdb) bt #0 php_explode (delim=0xed82208 "", delim_len=2147450528, str=0x3c , str_len=249048784, str_type=0 '\0', return_value=0x106ce240, limit=-1) at zend_operators.h:215 #1 0x1022b380 in zif_explode (ht=2, return_value=0x106ce240, return_value_ptr=, this_ptr=, return_value_used=) at /home/cvs/php/php-src/ext/standard/string.c:1137 #2 0x1030b414 in zend_do_fcall_common_helper_SPEC (execute_data=0x7fff7f80) at zend_vm_execute.h:201 #3 0x1030a8e4 in execute (op_array=0x106ce0e8) at zend_vm_execute.h:92 #4 0x102dc0b8 in zend_execute_scripts (type=8, retval=0x1022b380, file_count=3) at /home/cvs/php/php-src/Zend/zend.c:1806 #5 0x1027bf7c in php_execute_script (primary_file=0x7fffa4e4) at /home/cvs/php/php-src/main/main.c:1846 #6 0x103d6348 in main (argc=3, argv=0x7fffaac4) at /home/cvs/php/php-src/sapi/cli/php_cli.c:1090 -- Edit bug report at http://bugs.php.net/?id=36241&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36241&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36241&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36241&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36241&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36241&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36241&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36241&r=needscript Try newer version:http://bugs.php.net/fix.php?id=36241&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36241&r=support Expected behavior:http://bugs.php.net/fix.php?id=36241&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36241&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36241&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36241&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36241&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36241&r=dst IIS Stability:http://bugs.php.net/fix.php?id=36241&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=36241&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=36241&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=36241&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=36241&r=mysqlcfg
#36229 [Opn->Bgs]: Adding arbitary expression to class cause premature end to script
ID: 36229
Updated by: [EMAIL PROTECTED]
Reported By: perry dot sebastian at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: Scripting Engine problem
Operating System: linux - SUSE 10
PHP Version: 5.1.1
New Comment:
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
Previous Comments:
[2006-02-01 04:25:39] perry dot sebastian at gmail dot com
I don't any problems with the code, either...
I installed 5.1.2 (the bug report should have indicated a version
number of 5.1.1). And now the following fatal error is being reported:
[debug info] -> size patterns[77], replacements[77] pagedata[13089]
Fatal error: Allowed memory size of 8388608 bytes exhausted at
/opt/php/php-5.1.2/ext/pcre/php_pcre.c:880 (tried to allocate 26179
bytes) in /srv/www/lampair/lib/PageMaker.php on line 578
Line 577 - 578 in PageMaker.php are:
577: if($carplinks) { print "size patterns[".count($patterns)."],
replacements[".count($replacements)."]
pagedata[".strlen($pagedata)."]\n"; }
578: $pagedata = preg_replace($patterns, $replacements, $pagedata);
This fatal error with preg_replace was not reported under 5.1.1, so it
would seem likely that the failure to complete the output of the page
under 5.1.1 was related to the same error.
[2006-01-31 15:44:22] [EMAIL PROTECTED]
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to "Open".
Thank you for your interest in PHP.
I don't see any problems with this code.
[2006-01-31 15:27:13] perry dot sebastian at gmail dot com
Description:
Adding a line of code to a specific object class causes the web
application to terminate prematurely. A line of code such as "function
testthis() {}" will trigger this problem. When this line is commented
out, the application behaves as expected.
Code previously worked under PHP 4.4.
Reproduce code:
---
Expected result:
Web page with printed output of application states at the top of the
page.
Actual result:
--
This problem seems to be isolated with this class file. I have turned
on STRICT for error reporting, but no error relevant to this object
comes back when the application is executed. I cleaned line endings,
changed function names, removed and added code, and the problem
persists. Apache does not report an error.
Premature termination is also very strange. It seems very inconsistent.
Initially an error occurred that flagged an included file for consuming
too much memory. This error stopped after the error was investigated
(and I have not been able to replicate this error). The failure appears
to "reach back" in the code execution and stop application output before
the point of failure (noted by various print statement track code
execution). Forcing an exit of the application before loading this
object class causes termination at the appropriate point - not before.
--
Edit this bug report at http://bugs.php.net/?id=36229&edit=1
#36240 [Opn->Bgs]: foreach($arr as $k => &$v) corrupts array on second iteration
ID: 36240 Updated by: [EMAIL PROTECTED] Reported By: dshadow at zort dot net -Status: Open +Status: Bogus Bug Type: Scripting Engine problem Operating System: Mac OS X PHP Version: 5.1.2 New Comment: Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Thank you for your interest in PHP. Duplicate of bug #29992 Previous Comments: [2006-02-01 08:20:39] judas dot iscariote at gmail dot com BOGUS. read bug 29992 [2006-02-01 06:35:00] dshadow at zort dot net Description: After using foreach($arr as $k => &$v) to modify the $arr, iterating again using the same variable $v causes the array to be altered unexpectedly. Adding an unset($v) between the two foreach loops, or using a different variable on the second foreach loop works around the problem. Reproduce code: --- 1, 'two' => 2, 'three' => 3, ); foreach($arr as $k => &$v) if($v == 1) $v = 'meh'; print_r($arr); foreach($arr as $k => $v) ; print_r($arr); Expected result: The code above should not cause the $arr to be modified by running the second foreach loop. Actual result: -- The code above outputs the following: Array ( [one] => meh [two] => 2 [three] => 3 ) Array ( [one] => meh [two] => 2 [three] => 2 ) -- Edit this bug report at http://bugs.php.net/?id=36240&edit=1
#36239 [Opn->Bgs]: $_SESSION Array Assignment Fails
ID: 36239
Updated by: [EMAIL PROTECTED]
Reported By: martin at itmission dot com
-Status: Open
+Status: Bogus
Bug Type: Session related
Operating System: Windows
PHP Version: 5.1.2
New Comment:
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
This is actually correct behavior. The $_SESSION array is special, and
now you're overwriting it removing its special capabilities.
Previous Comments:
[2006-02-01 05:37:52] martin at itmission dot com
Description:
$_SESSION does not keep results when assigned an array variable.
Reproduce code:
---
test1.php
click");
print_r($_SESSION);
$_SESSION = array('id' => 1, 'user' => 'test');
session_write_close();
?>
test2.php
click");
print_r($_SESSION);
$row = array('id' => 1, 'user' => 'test');
$_SESSION = $row;
session_write_close();
?>
test3.php
click");
print_r($_SESSION);
$row = array('id' => 1, 'user' => 'test');
$_SESSION = $row + array();
session_write_close();
?>
Expected result:
Test1.php: Works
Test2.php: Fails
Test3.php: Works
Actual result:
--
Test1: clickArray ( [id] => 1 [user] => test )
Test2: clickArray ( )
Test3: clickArray ( [id] => 1 [user] => test )
--
Edit this bug report at http://bugs.php.net/?id=36239&edit=1
#36208 [WFx->Opn]: Symbols in libphp5.so conflict with symbols in libgd.so and cause apache probs
ID: 36208 Updated by: [EMAIL PROTECTED] Reported By: hb at gentoo dot x256 dot org -Status: Wont fix +Status: Open Bug Type: Dynamic loading Operating System: Gentoo Linux x86 PHP Version: 5.1.2 New Comment: There is no need to use this kind of language, it will not make us help you faster. That said, we actually do namespace protect those symbols in there by prefixing them with php_gd_. It seems however that some of them are not added yet, see the file main/php_compat.h. Feel free to submit a patch for that file. Previous Comments: [2006-02-01 05:33:10] hb at gentoo dot x256 dot org This is a problem with PHP. You can't just tell me to compile it differently because in the real world, when actual users compile and install perl and PHP, they won't know this. There's no warning that I ever saw that tells me not to do this, and then my programs randomly crash, and I spent a whole day trying to work out why. This WILL happen to other people unless you fix YOUR bug, which is exporting non-standard GD symbols with standard names into the dynamic linker namespace. They should be renamed or hidden or set to a different version so they won't collide with the real GD. I guess if you're unwilling to fix it I'll have to get the Gentoo people to either patch PHP or change the portage system so it won't install PHP and mod_perl simultaneously with USE=gd. However, this has the possibility of biting people in other circumstances too. I can't understand why you say it's not your problem. You shouldn't export symbols willy-nilly especially when you modify them from the library you pulled them from originally and don't rename them. [2006-02-01 01:16:12] [EMAIL PROTECTED] In case when you need to compile another apache module that uses gdlib you need to compile php with the system library. (--with-gd=/path/to/system/gdlib) [2006-01-30 12:45:16] hb at gentoo dot x256 dot org Description: PHP includes a tweaked GD library. It is not compatible with libgd. The problem is, it uses the same symbols (i.e. function names) as libgd and exports them from its shared object. When I load mod_php and mod_perl into Apache, mod_perl programs using the GD library end up sometimes calling PHP's modified GD routines and sometimes not. This causes Apache children to crash semi-randomly. Since the PHP GD library is not compatible with libgd itself (and because it's likely to be co-existing with a different version of libgd on the system, regardless of tweaks), the symbols (functions and others) should be renamed. Perhaps with a PHP_ prefix. This way there will be no dynamic loading collision and PHP/PERL will be able to co-exist in Apache children without damage. I worked around this by recompiling libPHP with external GD library support. However, it took me several hours to diagnose the exact problem. I have also been bitten by this once before already. I recommend fixing this in PHP4 as well as PHP5. Reproduce code: --- This PERL/MASON script crashes every time if libphp5.so is loaded as an Apache module, but works perfectly otherwise: <%INIT> use strict; use GD::Graph::lines; my $tgraph = GD::Graph::lines->new(800, 800); my $tgd = $tgraph->plot([ [ "a" ], [ 0 ] ]); print $tgd->png(); return; Expected result: Blank graph. Actual result: -- Zero-sized reply. GLIBC memory corruption reported upon free() in error_log. -- Edit this bug report at http://bugs.php.net/?id=36208&edit=1
#36223 [Csd]: curl bypasses open_basedir restrictions
ID: 36223 User updated by: stevewest15 at yahoo dot com Reported By: stevewest15 at yahoo dot com Status: Closed Bug Type: Safe Mode/open_basedir Operating System: Redhat Enterprise 3.6 PHP Version: 4.4.2 New Comment: > This bug has been fixed in CVS. But that is what was claimed with this release of 4.4.2. This is why we upgraded to 4.4.2. I'm not sure about using a CVS version on production servers but I hope a final version with this fix will be coming out soon. thx, SW Previous Comments: [2006-01-31 11:57:54] [EMAIL PROTECTED] This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2006-01-31 11:18:59] stevewest15 at yahoo dot com Description: PHP 4.4.2 still has the bug which allows CURL to bypass open_basedir restrictions. Your release notes for 4.4.2 state that it has been fixed...but it hasn't! :-( Here is the configure line for PHP: './configure' '--localstatedir=/var/hsphere/php' '--with-apxs=/hsphere/shared/apache/bin/apxs' '--with-openssl=/usr' '--with-zlib=/usr' '--with-zlib-dir=/usr' '--with-bz2=/usr' '--enable-calendar' '--with-jpeg-dir=/hsphere/shared' '--enable-ftp' '--with-gd' '--with-ttf' '--with-freetype-dir=/hsphere/shared' '--enable-gd-native-ttf' '--with-png-dir=/hsphere/shared' '--with-gettext=/hsphere/shared' '--with-imap=/hsphere/shared' '--with-mysql=//usr' '--with-pgsql=//usr' '--with-curl=/hsphere/shared' '--with-curlwrappers' '--with-mhash=/hsphere/shared' '--with-mcrypt=/hsphere/shared' '--with-iconv=/hsphere/shared' '--enable-sockets' '--with-zip=/hsphere/shared' '--enable-versioning' '--enable-track-vars' '--enable-trans-sid' '--enable-bcmath' '--enable-mbstring' '--disable-debug' '--enable-pspell' '--enable-memory-limit' '--disable-files' Changes to php.ini made: open_basedir = /home/hsphere/shared/apache/htdocs/:/usr/local/lib/php/:/tmp/ disable_functions = "pack,system" Please fix this Reproduce code: --- Expected result: It should say that open_basedir restrictions are in affect and that it couldn't retrieve file. Actual result: -- When the above code is run, it actually retrieves my /etc/snmpd.conf and displays it's content in my browser. BIG SECURITY concern! -- Edit this bug report at http://bugs.php.net/?id=36223&edit=1
