#25699 [Csd->Bgs]: for does not execute from within foreach
ID: 25699
Updated by: [EMAIL PROTECTED]
Reported By: richy at smilingsouls dot net
-Status: Closed
+Status: Bogus
Bug Type: *Programming Data Structures
Operating System: Windows XP Home
PHP Version: 4.3.3
New Comment:
Bogusing..
Previous Comments:
[2003-09-30 02:35:45] richy at smilingsouls dot net
I figured out that the condition wasn't ever being met.
[2003-09-30 02:18:23] richy at smilingsouls dot net
Description:
I have tried several variations of trying to use a for loop from within
a foreach. In no case did the for loop execute.
I have no idea if this is simply not allowed, or a bug. But it has
frustrated me enough to report it!
This works neither on my home dev. server (Xitami, Windows XP, PHP
4.3.3 R4) or on my remote ISP which sports some flavor of Unix. See
server config at http://www.smilingsouls.net/phpinfo.php
Reproduce code:
---
function foo()
{
$foo[1] = 'test1';
$foo[2] = 'test2';
foreach($foo as $key => $value)
{
for($d = 0; $d == 10; $d++) {echo $d;}
}
}
function foo2()
{
$foo[1] = 'test1';
$foo[2] = 'test2';
foreach($foo as $key => $value)
{
loop_it();
}
}
function loop_it()
{
for($d = 0; $d == 10; $d++) {echo $d;}
}
$foo[1] = 'test1';
$foo[2] = 'test2';
foreach($foo as $key => $value)
{
loop_it();
}
Expected result:
each should output:
012345678910
012345678910
Actual result:
--
blank, nothing!
--
Edit this bug report at http://bugs.php.net/?id=25699&edit=1
#25699 [Opn->Csd]: for does not execute from within foreach
ID: 25699
User updated by: richy at smilingsouls dot net
Reported By: richy at smilingsouls dot net
-Status: Open
+Status: Closed
Bug Type: *Programming Data Structures
Operating System: Windows XP Home
PHP Version: 4.3.3
New Comment:
I figured out that the condition wasn't ever being met.
Previous Comments:
[2003-09-30 02:18:23] richy at smilingsouls dot net
Description:
I have tried several variations of trying to use a for loop from within
a foreach. In no case did the for loop execute.
I have no idea if this is simply not allowed, or a bug. But it has
frustrated me enough to report it!
This works neither on my home dev. server (Xitami, Windows XP, PHP
4.3.3 R4) or on my remote ISP which sports some flavor of Unix. See
server config at http://www.smilingsouls.net/phpinfo.php
Reproduce code:
---
function foo()
{
$foo[1] = 'test1';
$foo[2] = 'test2';
foreach($foo as $key => $value)
{
for($d = 0; $d == 10; $d++) {echo $d;}
}
}
function foo2()
{
$foo[1] = 'test1';
$foo[2] = 'test2';
foreach($foo as $key => $value)
{
loop_it();
}
}
function loop_it()
{
for($d = 0; $d == 10; $d++) {echo $d;}
}
$foo[1] = 'test1';
$foo[2] = 'test2';
foreach($foo as $key => $value)
{
loop_it();
}
Expected result:
each should output:
012345678910
012345678910
Actual result:
--
blank, nothing!
--
Edit this bug report at http://bugs.php.net/?id=25699&edit=1
#25699 [NEW]: for does not execute from within foreach
From: richy at smilingsouls dot net
Operating system: Windows XP Home
PHP version: 4.3.3
PHP Bug Type: *Programming Data Structures
Bug description: for does not execute from within foreach
Description:
I have tried several variations of trying to use a for loop from within a
foreach. In no case did the for loop execute.
I have no idea if this is simply not allowed, or a bug. But it has
frustrated me enough to report it!
This works neither on my home dev. server (Xitami, Windows XP, PHP 4.3.3
R4) or on my remote ISP which sports some flavor of Unix. See server
config at http://www.smilingsouls.net/phpinfo.php
Reproduce code:
---
function foo()
{
$foo[1] = 'test1';
$foo[2] = 'test2';
foreach($foo as $key => $value)
{
for($d = 0; $d == 10; $d++) {echo $d;}
}
}
function foo2()
{
$foo[1] = 'test1';
$foo[2] = 'test2';
foreach($foo as $key => $value)
{
loop_it();
}
}
function loop_it()
{
for($d = 0; $d == 10; $d++) {echo $d;}
}
$foo[1] = 'test1';
$foo[2] = 'test2';
foreach($foo as $key => $value)
{
loop_it();
}
Expected result:
each should output:
012345678910
012345678910
Actual result:
--
blank, nothing!
--
Edit bug report at http://bugs.php.net/?id=25699&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25699&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25699&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=25699&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=25699&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=25699&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=25699&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=25699&r=support
Expected behavior: http://bugs.php.net/fix.php?id=25699&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=25699&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=25699&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=25699&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25699&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=25699&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=25699&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=25699&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=25699&r=float
#25686 [Bgs->Opn]: XML processing instruction handling feature request (Expat)
ID: 25686 User updated by: bart at mediawave dot nl -Summary: XML processing instruction handling feature request Reported By: bart at mediawave dot nl -Status: Bogus +Status: Open Bug Type: Feature/Change Request Operating System: All PHP Version: Irrelevant New Comment: That could be a nice "work-around" but you don't include() XML files. You parse them with Expat. That's what Expat is for. Using include() to load an XML file would mean that I would have to use Expat to parse a PHP file that includes the XML file on the background. Unless there is no other way I think this is an ugly sollution that carries too much overhead. Especially when parsing large XML files. The fact is that my feature request already partially exists in PHP. There is a reason for that. I just think that this feature is incomplete. Previous Comments: [2003-09-29 21:13:30] [EMAIL PROTECTED] You don't need to use XML functions for this, just include() the file.. [2003-09-29 15:37:46] bart at mediawave dot nl Excuse me if I was not clear enough. This "problem" occurs when parsing the specified XML file with the Expat XML functions. I get this problem with PHP 4.3.2, PHP 4.3.3 and PHP 5.0.0 beta. You can reproduce the problem with the code on http://www.php.net/manual/en/ref.xml.php under "Example 3. External Entity Example" and using the following XML for xmltest.xml: [2003-09-29 05:42:00] [EMAIL PROTECTED] With PHP 4.3.3 I get the correct output. Disable short-tags maybe? [2003-09-29 04:38:50] bart at mediawave dot nl Description: With the XML parser module PHP currently handles processing instruction code per tag. For example: is seen as an isolated chunk of code. This doesn't work: PHP handles the PHP code per tag. While in this example the code actually spans through 5 tags. But PHP doesn't recognize it this way. Also. For my application it would be desirable if the PHP XML parser would not return the php code. The evaluation of the PHP code in the XML should be hanled by the parser. It should then only return the resulting (evaluated) XML as if it was normal XML. Reproduce code: --- Expected result: 0 1 2 3 Actual result: -- Parse error: parse error, unexpected $end in D:\php-4.3.2\PEAR\wrap_v4\dam.php(544) : eval()'d code on line 1 Parse error: parse error, unexpected T_ENDFOR in D:\php-4.3.2\PEAR\wrap_v4\dam.php(544) : eval()'d code on line 1 -- Edit this bug report at http://bugs.php.net/?id=25686&edit=1
#14222 [Com]: PHP Crashes with weird output often
ID: 14222 Comment by: Julio_mello at terra dot com dot br Reported By: mail at seen dot ch Status: Closed Bug Type: Apache related Operating System: Windows XP Pro PHP Version: 4.1.1 New Comment: I had the same problem, Apache -X fixed the problem. Previous Comments: [2003-02-07 12:05:07] m_s at mobilixnet dot dk Apache -X worked for me as well. I'm using Apache 2.0.43 and PHP 4.3.0, and without the -X switch it didn't work. I got corrupted output (as described above), but there wasn't any problems with small amounts of data. When a given query (to an Access database) returned many results (about >70), the page reloaded several times and either resulted in partially corrupted output or a 404. [2002-07-24 02:43:38] sinachen at chtd dot com dot tw i try Apache 1.3.26 and PHP 4.2.1 it's work fine :) [2002-06-18 19:01:29] [EMAIL PROTECTED] Try Apache 1.3.24 and PHP 4.2.1. Reopen if problem persists. [2002-03-21 07:07:37] [EMAIL PROTECTED] Sounds like it is related to Bugs #15613 and #15245. This really needs sorting out for PHP 4.2 [2002-03-21 04:56:34] [EMAIL PROTECTED] no, you have found a workaround that hides the actual problem for now, maybe due to reduced output buffer sizes ... 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/14222 -- Edit this bug report at http://bugs.php.net/?id=14222&edit=1
#23973 [Com]: Ming Funtion don't work
ID: 23973
Comment by: gabrielsanroman at hotmail dot com
Reported By: vicviper at skcc dot com
Status: No Feedback
Bug Type: Ming related
Operating System: XP sp1a, Win2K sp3
PHP Version: 4.3.2
New Comment:
I still have this problem.
Windows XP SP1 Spanish
IIS 5.1 or Apache 2.0.47
PHP 4.3.2, 4.3.3, and some taken from CVS (27/09/03)
ming 0.2a
Every call to SWFFont with an FDB crashes the web server (msvcrt.dll
causes an error on IIS, ntdll.dll on Apache)
if i call it with _sans or something like that no text is generated.
Previous Comments:
[2003-07-20 10:37:46] [EMAIL PROTECTED]
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
[2003-07-13 00:12:21] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
[2003-06-03 02:36:32] vicviper at skcc dot com
OS : Windows 2K sp3, Windows XP sp1 Hangul Version
HTTPD : Apache2, IIS 5.0
Browser : IE 6.0
don't work it or Crash System.
setFont($f);
$t->setColor(255, 0, 0);
$t->setHeight(60);
$t->addString("Advanced PHP");
$m = new SWFMovie();
$m->setDimension(320, 240);
$i = $m->add($t);
$i->moveTo(160-$t->getWidth("Advanced PHP")/2,
120+$t->getAscent()/2);
$filename ="test.swf";
$m->save($filename);
?>
http://www.macromedia.com/shockwave/download/index.cgi?P1_Prod_Version=ShockwaveFlash"type="application/x-shockwave-flash";
width=600 height=300>
Fix plz!!
--
Edit this bug report at http://bugs.php.net/?id=23973&edit=1
#24502 [Opn->Bgs]: Fast CGI interface is broken
ID: 24502 Updated by: [EMAIL PROTECTED] Reported By: gwang at litespeedtech dot com -Status: Open +Status: Bogus Bug Type: CGI related Operating System: Linux PHP Version: 4.3.4 dev Assigned To: shane New Comment: Read the note above the cgi.fix_pathinfo in php.ini-dist (found in the release tarball). There is no bug. Previous Comments: [2003-09-29 16:06:07] gwang at litespeedtech dot com BTW: I tested the latest stable snapshot. [2003-09-29 16:03:36] gwang at litespeedtech dot com Thank you for the response. Here is the result. Testing url /phpinfo.php/path/info?a=b is used, when set cgi.fix_pathinfo=0, same result (0 is the default according to the comments in the ini file), "no input file" is returned. set cgi.fix_pathinfo=1, the php information page is returned, but _SERVER["PATH_INFO"] and _SERVER["PATH_TRANSLATED"] contain no value and the vlaue of _SERVER["ORIG_"] environment variables are all correct. I don't think set cgi.fix_pathinfo=1 is the right fix for this bug. All correct values are provided in the first place, why waste CPU cycles to try to guess them from other sources? I think the cleanest and probably the easiest fix is to provide a configuration directive to skip all the reverse hacking code. best regards, LiteSpeed Team [2003-09-29 05:58:48] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2003-09-24 12:03:07] [EMAIL PROTECTED] Check php.ini for cgi.fix_pathinfo and try setting it to 1 or 0. [2003-08-25 16:28:02] gwang at litespeedtech dot com This has not been completely fixed in 4.3.3. When there is no PATH_INFO, it works fine. When PATH_INFO is populated, it breaks. Try something like /phpinfo.php/path/info?a=b The reason it breaks is PATH_TRANSLATED is used as the path to the PHP script file instead of SCRIPT_FILENAME when PAHT_INFO is popluated. As our LiteSpeed web server follows the CGI specification, all the code controled by macro #if !DISCARD_PATH and #if ENABLE_PATHINFO_CHECK are not necessory. If PHP is configured with following options, ./configure --enable-fastcgi --enable-discard-path --disable-path-info-check then the testing URL /phpinfo.php/path/info?a=b works just fine except the PHP and Zend logos are missing due to the wrong value of PHP_SELF. According to the comments in the code that the way PHP_SELF populated is to provide backward compatibility for version before 4.3. My question is, is this another reverse hacking for web server that does not follow CGI spec, like Apache? By doing so, PHP_SELF is happen to be the right value for them? If so, those code should be moved inside the section controled by macro ENABLE_PATHINFO_CHECK or !DISCARD_PATH. I think it is better to seperate the reserve hacking code for Apache's fast CGI interface from the others as it is the only odd guy. The code could be much cleaner. Just some suggestions. Sincerely, LiteSpeed Team . 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/24502 -- Edit this bug report at http://bugs.php.net/?id=24502&edit=1
#25697 [Fbk->Bgs]: Locale-specific formats of strftime() do not work
ID: 25697
Updated by: [EMAIL PROTECTED]
Reported By: joho at webbplatsen dot se
-Status: Feedback
+Status: Bogus
Bug Type: Unknown/Other Function
Operating System: SuSE Linux 8.x, 2.4.19-4GB kerne
PHP Version: 4.3.3
New Comment:
Locale names differ from system to system.
Given the correct one for your system will give correct results. Not
PHP bug.
Previous Comments:
[2003-09-29 19:13:10] [EMAIL PROTECTED]
Try
$ locale -a | grep "sv_SV"
to see if your system supports that locale.
[2003-09-29 18:07:00] joho at webbplatsen dot se
Description:
After upgrading our system to PHP 4.3.2, setlocate() no longer seemed
to have any effect. I later upgraded to PHP 4.3.3 but find the same
problem present. No compile-time problems are reported.
Uppercase/lowercase of Swedish national characters no longer works
either.
Reproduce code:
---
Code from the PHP manual (fails):
/* Set locale to Dutch */
setlocale (LC_ALL, 'nl_NL');
/* Output: vrijdag 22 december 1978 */
echo strftime ("%A %e %B %Y", mktime (0, 0, 0, 12, 22, 1978));
/* try different possible locale names for german as of PHP 4.3.0 */
$loc_de = setlocale (LC_ALL, '[EMAIL PROTECTED]', 'de_DE', 'de', 'ge');
echo "Preferred locale for german on this system is '$loc_de'";
Own code (fails):
setlocale (LC_ALL, 'sv_SV');
return
(
ucfirst (strftime ("%a")) .
" " .
date ("Y-m-d") .
" ".
"V." .
strftime ("%V")
);
Expected result:
Own code should result in this:
Tis 2003-09-30 V.40
(if run on 2003-09-30, that is ;)
Actual result:
--
Tue 2003-09-30 V.40
And no, I am not certain I have not done something wrong, but since
this behavior changed after we installed 4.3.2.. ???
--
Edit this bug report at http://bugs.php.net/?id=25697&edit=1
#25692 [Opn->Bgs]: global $$formvar fails if $formvar == "array[element]"
ID: 25692
Updated by: [EMAIL PROTECTED]
Reported By: declan at context dot ie
-Status: Open
+Status: Bogus
-Bug Type: Arrays related
+Bug Type: *General Issues
Operating System: linux
PHP Version: Irrelevant
New Comment:
Try setting error_reporting to E_ALL and you'll find out why it doesn't
work.
Previous Comments:
[2003-09-29 10:50:13] declan at context dot ie
Description:
If you pass a variable name to a function and then try to dereference
that variable name for use in a global statement, then the global
statement fails.
I believe the problem lies in the way that global is implemented. If I
have the following:
$ary[foo]="bar";
function use_global($varname) {
global $$varname;
echo "$varname is set to ". $$varname;
}
use_global ("ary[foo]");
then I think that the global line is being re-written to be equivalent
to something like:
$_use_global_varname=&$GLOBALS["ary[foo]"];
whereas, AFAICS, it should be:
$_use_global_varname=&$GLOBALS["ary"]["foo"];
I want to be able to use this construct without having to know whether
the incoming variable is a plain variable or an array element.
Reproduce code:
---
Expected result:
If things worked correctly, the output should be:
global[bar]=2
formvar: global[bar] =2
Actual result:
--
global[bar]=2
formvar: global[bar] =
--
Edit this bug report at http://bugs.php.net/?id=25692&edit=1
#25686 [Opn->Bgs]: XML processing instruction handling feature request
ID: 25686 Updated by: [EMAIL PROTECTED] Reported By: bart at mediawave dot nl -Status: Open +Status: Bogus Bug Type: Feature/Change Request Operating System: All PHP Version: Irrelevant New Comment: You don't need to use XML functions for this, just include() the file.. Previous Comments: [2003-09-29 15:37:46] bart at mediawave dot nl Excuse me if I was not clear enough. This "problem" occurs when parsing the specified XML file with the Expat XML functions. I get this problem with PHP 4.3.2, PHP 4.3.3 and PHP 5.0.0 beta. You can reproduce the problem with the code on http://www.php.net/manual/en/ref.xml.php under "Example 3. External Entity Example" and using the following XML for xmltest.xml: [2003-09-29 05:42:00] [EMAIL PROTECTED] With PHP 4.3.3 I get the correct output. Disable short-tags maybe? [2003-09-29 04:38:50] bart at mediawave dot nl Description: With the XML parser module PHP currently handles processing instruction code per tag. For example: is seen as an isolated chunk of code. This doesn't work: PHP handles the PHP code per tag. While in this example the code actually spans through 5 tags. But PHP doesn't recognize it this way. Also. For my application it would be desirable if the PHP XML parser would not return the php code. The evaluation of the PHP code in the XML should be hanled by the parser. It should then only return the resulting (evaluated) XML as if it was normal XML. Reproduce code: --- Expected result: 0 1 2 3 Actual result: -- Parse error: parse error, unexpected $end in D:\php-4.3.2\PEAR\wrap_v4\dam.php(544) : eval()'d code on line 1 Parse error: parse error, unexpected T_ENDFOR in D:\php-4.3.2\PEAR\wrap_v4\dam.php(544) : eval()'d code on line 1 -- Edit this bug report at http://bugs.php.net/?id=25686&edit=1
#25693 [Opn->Bgs]: No access to posted variables via socket connection
ID: 25693
Updated by: [EMAIL PROTECTED]
Reported By: a dot erler at brain-at-work dot de
-Status: Open
+Status: Bogus
Bug Type: Sockets related
Operating System: Debian
PHP Version: 4.3.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.
Thank you for your interest in PHP.
And your PHP version is too old..
Previous Comments:
[2003-09-29 12:11:08] a dot erler at brain-at-work dot de
Description:
I'm trying to send some variables via POST with a socket connection to
a HTML form.
The problem:
The socket connection returns HTML-code from the form, but in the form
I can't access the variables I sent (e.g. "go" is not set in
$HTTP_POST_VARS and not in the global scope).
I took the sample code from the PHP manual, section "Stream functions",
"Example 2. Making a POST request to an https server".
I think it should be no problem, that there are additional
GET-parameters in the URI "d_content_kontakt.php" !?
Reproduce code:
---
$sock = fsockopen("linux", 80, $errno, $errstr, 30);
$data = 'go='.urlencode('sent');
fputs($sock, "POST
/caranet_redesign/d_content_kontakt.php?art_angebot=Gebrauchtwagen&id_haendler=0002&id_lang=0001&typ=rm&hersteller=&schlafplaetze=&preis_von=&preis_bis=&id_fahrzeuge=2158
HTTP/1.0\r\n");
fputs($sock, "Host: linux\r\n");
fputs($sock, "Content-type: application/x-www-url-encoded\r\n");
fputs($sock, "Content-length: " . strlen($data) . "\r\n");
fputs($sock, "Accept: */*\r\n");
fputs($sock, "\r\n");
fputs($sock, "$data\r\n");
fputs($sock, "\r\n");
$headers = "";
while ($str = trim(fgets($sock, 4096)))
$headers .= "$str\n";
print "\n";
$body = "";
while (!feof($sock))
$body .= fgets($sock, 4096);
fclose($sock);
Expected result:
variable "go" should contain "sent", but is not set in
d_content_kontakt.php
--
Edit this bug report at http://bugs.php.net/?id=25693&edit=1
#12995 [Opn->Bgs]: "Failed opening ... in Unknown on line 0
ID: 12995 Updated by: [EMAIL PROTECTED] Reported By: se at brainbits dot net -Status: Open +Status: Bogus Bug Type: Scripting Engine problem Operating System: SuSE Linux 7.2 PHP Version: 4.3.3 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. Because of this, we hope you add your comments to the existing bug instead. Thank you for your interest in PHP. See bug #23580 (same issue, vhost specific php settings leaked) Previous Comments: [2003-09-29 11:53:15] se at brainbits dot net Again I have this problem. Now it occurs on an Debian 3.0 with PHP4.3.3 and on a SuSE 7.2 with PHP4.3.2 - both with Apache/1.3.26. But the error-message changed a little bit: Warning: Unknown(prepend.php4): failed to open stream: No such file or directory in Unknown on line 0 Warning: (null)(): Failed opening 'prepend.php4' for inclusion (include_path='.:/www/user1/inc') in Unknown on line 0 Curios: there is no auto_prepend-file and there is no script which includes a file called "prepend.php4" in the host enviroment of user1. There is another user with another virtual hosts who uses a auto_prepend_file called "prepend.php4". But why does this takes effect on the host of user 1? Bye, Sascha [2001-08-28 07:04:30] se at brainbits dot net I get this warning: Warning: Failed opening 'path_to_a_script' for inclusion (include_path='.:/path/to/a/include/directory') in Unknown on line 0 Sometimes everything works fine, sometimes don't - without changing anything in the php.ini or httpd.conf . A few days ago I updated from php4.0.4 to php4.0.6 and after that the problems begann. All parameters in 4.0.6 are the same than in 4.0.4. Do you need more informations? Bye, Sascha Emondts -- Edit this bug report at http://bugs.php.net/?id=12995&edit=1
#25698 [Opn->Fbk]: php4ts!php_execute_script + 0x22A
ID: 25698 Updated by: [EMAIL PROTECTED] Reported By: karel at publihost dot com -Status: Open +Status: Feedback Bug Type: IIS related Operating System: Windows 2k Server SP4 PHP Version: 4.3.3 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: [2003-09-29 18:33:41] karel at publihost dot com Description: IIS 5.0 Loaded PHP-modules: php_gd.dll IIS hangs, I need to close the dllhost and restart it. I get this error in the system log file: The HTTP server encountered an unhandled exception while processing the ISAPI Application ' php4ts!php_execute_script + 0x22A '. For additional information specific to this message please visit the Microsoft Online Support site located at: http://www.microsoft.com/contentredirect.asp. -- Edit this bug report at http://bugs.php.net/?id=25698&edit=1
#25690 [Opn->Bgs]: call_user_func_array disrespect returned references
ID: 25690
Updated by: [EMAIL PROTECTED]
Reported By: ask-me at ask-me dot ru
-Status: Open
+Status: Bogus
Bug Type: Scripting Engine problem
Operating System: All
PHP Version: 4.3.3
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
..
Previous Comments:
[2003-09-29 09:29:07] ask-me at ask-me dot ru
Description:
Unfortunatly even in version 4.3.3 there was an bug with
"call_user_func_array" function.
call_user_func and call_user_func do respect functions that return
references. That is, function foo that returns a references to an
object, does not return a reference to an object when foo is called
via
call_user_func. Instead, foo called via call_user_func returns a
"copy"
of the object. (I'm not sure "copy" is the right word.) See the code
example for a concise example of the problem.
Reproduce code:
---
function &testfunction()
{
global $testglobal;
return ($testglobal=1);
}
$testglobal_link=&call_user_func_array("testfunction",array('testparam-1','testparam-2'));
// $testglobal_link must be link to $testglobal at this stage
print $testglobal_link;
// trying to assign new value to $testglobal thru link
$testglobal_link=2;
// in theory we will get "2" as result
print $testglobal;
// but unfortunatly we will have "1" as result
print $testglobal_link;
--
Edit this bug report at http://bugs.php.net/?id=25690&edit=1
#25379 [Opn->Csd]: 'make install' partially broken
ID: 25379 Updated by: [EMAIL PROTECTED] Reported By: marcus at synchromedia dot co dot uk -Status: Open +Status: Closed Bug Type: Compile Failure Operating System: OpenBSD PHP Version: 4.3.3 New Comment: This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. See bug #25348 Previous Comments: [2003-09-29 08:45:17] marcus at synchromedia dot co dot uk make install-pear gives errors: Installing PEAR environment: /usr/local/lib/php/ PHP Parse error: parse error in /usr/local/src/php- 4.3.3/pear/package-Archive_Tar.xml on line 1 *** Error code 255 Stop in /usr/local/src/php-4.3.3 (line 274 of Makefile). *** Error code 1 Stop in /usr/local/src/php-4.3.3 (line 280 of Makefile). [2003-09-29 08:27:08] [EMAIL PROTECTED] What does this do: # make install-pear [2003-09-29 07:51:22] marcus at synchromedia dot co dot uk Sorry for the delay in responding. cc -v gives me: Reading specs from /usr/lib/gcc-lib/i386-unknown- openbsd3.1/2.95.3/specs gcc version 2.95.3 20010125 (prerelease) [2003-09-23 22:11:41] [EMAIL PROTECTED] What compiler you have there? [2003-09-22 04:47:23] marcus at synchromedia dot co dot uk Unfortunately I can't. I'm running OpenBSD 3.1-stable, and the docs say: > The current ports tree may not be used with the > previous release. This is due to changes, typically > with the port make process, that require code based > upon the OpenBSD-current source tree. I guess a solution would be to upgrade to OpenBSD 3.4 when it comes out, but that's a whole load of work and downtime I can't afford right now. I can make do with 4.3.2 for now as I was planning on upgrading the whole system for PHP5. I don't know if you want to continue tracking this bug - 3.1 isn't that old (about 15 months), but I don't know how many users it may affect. FWIW, the current PHP5 beta installs ok. 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/25379 -- Edit this bug report at http://bugs.php.net/?id=25379&edit=1
#25348 [Csd]: "make install" fails with --enable-short-tags
ID: 25348 Updated by: [EMAIL PROTECTED] Reported By: rjmooney at lsb dot syr dot edu Status: Closed Bug Type: Reproducible crash Operating System: OpenBSD 3.2 PHP Version: 4.3.3 New Comment: See bug #25348 Previous Comments: [2003-09-01 20:30:35] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. [2003-09-01 20:19:29] rjmooney at lsb dot syr dot edu Description: PHP 4.3.3 builds as expected under OpenBSD 3.2 w/ Apache 1.3.27. However, when I attempt to install, I receive the following: -- cut here -- Build complete. (It is safe to ignore warnings about tempnam and tmpnam). ... Installing PEAR environment: /usr/local/lib/php/ Parse error: parse error in ./php-4.3.3/pear/package-Archive_Tar.xml on line 1 *** Error code 255 -- cut here -- Line 1 of Archive_Tar.xml is: Here are my configure options: ./configure --with-apxs=/usr/sbin/apxs --with-mysql --with-xml --with-pgsql --enable-ftp --enable-short-tags --enable-calendar --enable-track-vars --with-tsrm-pth --enable-sockets --with-gettext --with-zlib-dir --with-jpeg --with-png --with-gd --with-exif --with-ttf --with-bcmath --with-pspell --with-pdflib --with-config-file-path=/var/www/conf The module does seems to work (phpinfo() reports the correct version), however attempting a command from the command prompt such as "php -v" hangs waiting for input. 4.3.2 does not have this problem. Reproduce code: --- $ ./configure --with-apxs=/usr/sbin/apxs --with-mysql --with-xml --with-pgsql --enable-ftp --enable-short-tags --enable-calendar --enable-track-vars --with-tsrm-pth --enable-sockets --with-gettext --with-zlib-dir --with-jpeg --with-png --with-gd --with-exif --with-ttf --with-bcmath --with-pspell --with-pdflib --with-config-file-path=/var/www/conf $ make # make install Expected result: No installation errors. -- Edit this bug report at http://bugs.php.net/?id=25348&edit=1
#25688 [Opn->Bgs]: Connect To Oracle 9i using IIS & PHP
ID: 25688 Updated by: [EMAIL PROTECTED] Reported By: ramez at faraah dot com dot sa -Status: Open +Status: Bogus Bug Type: OCI8 related Operating System: Win XP PHP Version: 4.3.3 New Comment: Google is your friend.. Previous Comments: [2003-09-29 09:12:55] ramez at faraah dot com dot sa Hello i try to use PHP4.3.3 but the same problem happen again The Oracle9i comes with Apache but i have in my computer IIS i try To connect to Oracle DB in IIS using PHP4.3.3 i stoped the apache service [2003-09-29 08:29:23] [EMAIL PROTECTED] And try searching for ORA-12560 with Google for example.. [2003-09-29 08:28:16] [EMAIL PROTECTED] Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to "Open". Again, thank you for your continued support of PHP. We\'re at PHP 4.3.3 already. [2003-09-29 08:25:05] ramez at faraah dot com dot sa Description: Hello I am using Oracle9i release 2 it's comes with Apache but i am using IIS and i don't want to use Apache. how can i connect to Oracle DB from the IIS using PHP i try to use = user:scott Password:tiger Service:RamezDB = how can i do ti Reproduce code: --- Using PHP to Read a Table in Oracle Employees Could not connet to Oracle9i"); $stmt = ociparse($c1," select * from emp"); ociexecute($stmt,OCI_DEFAULT); echo $c1."selecting\n\n"; while (ocifetch($stmt)) echo $c1." <".ociresult($stmt,"TEST").">\n\n"; echo $c1."done\n\n"; Expected result: to reterive the data from Oracle9i Actual result: -- Warning: _oci_open_server: ORA-12560: TNS:protocol adapter error in c:\inetpub\wwwroot\oracle\test.php on line 10 Could not connet to Oracle9i Warning: ociparse(): supplied argument is not a valid OCI8-Connection resource in c:\inetpub\wwwroot\oracle\test.php on line 13 Warning: ociexecute(): supplied argument is not a valid OCI8-Statement resource in c:\inetpub\wwwroot\oracle\test.php on line 14 selecting Warning: ocifetch(): supplied argument is not a valid OCI8-Statement resource in c:\inetpub\wwwroot\oracle\test.php on line 16 done -- Edit this bug report at http://bugs.php.net/?id=25688&edit=1
#25697 [Opn->Fbk]: Locale-specific formats of strftime() do not work
ID: 25697
Updated by: [EMAIL PROTECTED]
Reported By: joho at webbplatsen dot se
-Status: Open
+Status: Feedback
Bug Type: Unknown/Other Function
Operating System: SuSE Linux 8.x, 2.4.19-4GB kerne
PHP Version: 4.3.3
New Comment:
Try
$ locale -a | grep "sv_SV"
to see if your system supports that locale.
Previous Comments:
[2003-09-29 18:07:00] joho at webbplatsen dot se
Description:
After upgrading our system to PHP 4.3.2, setlocate() no longer seemed
to have any effect. I later upgraded to PHP 4.3.3 but find the same
problem present. No compile-time problems are reported.
Uppercase/lowercase of Swedish national characters no longer works
either.
Reproduce code:
---
Code from the PHP manual (fails):
/* Set locale to Dutch */
setlocale (LC_ALL, 'nl_NL');
/* Output: vrijdag 22 december 1978 */
echo strftime ("%A %e %B %Y", mktime (0, 0, 0, 12, 22, 1978));
/* try different possible locale names for german as of PHP 4.3.0 */
$loc_de = setlocale (LC_ALL, '[EMAIL PROTECTED]', 'de_DE', 'de', 'ge');
echo "Preferred locale for german on this system is '$loc_de'";
Own code (fails):
setlocale (LC_ALL, 'sv_SV');
return
(
ucfirst (strftime ("%a")) .
" " .
date ("Y-m-d") .
" ".
"V." .
strftime ("%V")
);
Expected result:
Own code should result in this:
Tis 2003-09-30 V.40
(if run on 2003-09-30, that is ;)
Actual result:
--
Tue 2003-09-30 V.40
And no, I am not certain I have not done something wrong, but since
this behavior changed after we installed 4.3.2.. ???
--
Edit this bug report at http://bugs.php.net/?id=25697&edit=1
#25698 [NEW]: php4ts!php_execute_script + 0x22A
From: karel at publihost dot com Operating system: Windows 2k Server SP4 PHP version: 4.3.3 PHP Bug Type: IIS related Bug description: php4ts!php_execute_script + 0x22A Description: IIS 5.0 Loaded PHP-modules: php_gd.dll IIS hangs, I need to close the dllhost and restart it. I get this error in the system log file: The HTTP server encountered an unhandled exception while processing the ISAPI Application ' php4ts!php_execute_script + 0x22A '. For additional information specific to this message please visit the Microsoft Online Support site located at: http://www.microsoft.com/contentredirect.asp. -- Edit bug report at http://bugs.php.net/?id=25698&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25698&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25698&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=25698&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=25698&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=25698&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=25698&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=25698&r=support Expected behavior: http://bugs.php.net/fix.php?id=25698&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=25698&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=25698&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=25698&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25698&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=25698&r=dst IIS Stability: http://bugs.php.net/fix.php?id=25698&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=25698&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=25698&r=float
#25695 [Opn->Bgs]: Stack overflow
ID: 25695 Updated by: [EMAIL PROTECTED] Reported By: omar at the-one dot ca -Status: Open +Status: Bogus Bug Type: Unknown/Other Function Operating System: Windows 2000 Advanced Server PHP Version: 4.3.3 New Comment: Not a PHP problem. Report it to Zend. Previous Comments: [2003-09-29 15:17:34] omar at the-one dot ca Description: I found this bug after I installed Zend Optimizer with PHP 4.3.3: PHP has encountered a Stack overflow, on PHPMyAdmin when I clicked on privileges. I commented the zend optimizer stuff on the php.ini to disable zend optimizer and I don't get the error anymore. I just thought to let someone know bout it. -- Edit this bug report at http://bugs.php.net/?id=25695&edit=1
#25697 [NEW]: Locale-specific formats of strftime() do not work
From: joho at webbplatsen dot se
Operating system: SuSE Linux 8.x, 2.4.19-4GB kerne
PHP version: 4.3.3
PHP Bug Type: Unknown/Other Function
Bug description: Locale-specific formats of strftime() do not work
Description:
After upgrading our system to PHP 4.3.2, setlocate() no longer seemed to
have any effect. I later upgraded to PHP 4.3.3 but find the same problem
present. No compile-time problems are reported.
Uppercase/lowercase of Swedish national characters no longer works either.
Reproduce code:
---
Code from the PHP manual (fails):
/* Set locale to Dutch */
setlocale (LC_ALL, 'nl_NL');
/* Output: vrijdag 22 december 1978 */
echo strftime ("%A %e %B %Y", mktime (0, 0, 0, 12, 22, 1978));
/* try different possible locale names for german as of PHP 4.3.0 */
$loc_de = setlocale (LC_ALL, '[EMAIL PROTECTED]', 'de_DE', 'de', 'ge');
echo "Preferred locale for german on this system is '$loc_de'";
Own code (fails):
setlocale (LC_ALL, 'sv_SV');
return
(
ucfirst (strftime ("%a")) .
" " .
date ("Y-m-d") .
" ".
"V." .
strftime ("%V")
);
Expected result:
Own code should result in this:
Tis 2003-09-30 V.40
(if run on 2003-09-30, that is ;)
Actual result:
--
Tue 2003-09-30 V.40
And no, I am not certain I have not done something wrong, but since this
behavior changed after we installed 4.3.2.. ???
--
Edit bug report at http://bugs.php.net/?id=25697&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25697&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25697&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=25697&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=25697&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=25697&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=25697&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=25697&r=support
Expected behavior: http://bugs.php.net/fix.php?id=25697&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=25697&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=25697&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=25697&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25697&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=25697&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=25697&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=25697&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=25697&r=float
#25696 [Csd->Bgs]: PHP Website in Spanish
ID: 25696 Updated by: [EMAIL PROTECTED] Reported By: kevin at knconsulting dot com -Status: Closed +Status: Bogus Bug Type: Unknown/Other Function Operating System: Windows XP PHP Version: 4.3.3 New Comment: Please do not change the status of this bug. Previous Comments: [2003-09-29 17:11:30] kevin at knconsulting dot com thank you! [2003-09-29 17:07:17] [EMAIL PROTECTED] php.net performs a number of actions when you browse to determine what language to best serve the site in. IP address (to resolve back to the country you originate from), your browser's preferred language setting, the last explictly requested langauge, and the specific mirror's default language are all considered. In your case, these values combined to suggest you'd want the display in spanish. To override this value, simply select 'English' explicitly (from a dropdown on any manual page), or goto http://www.php.net/my.php to set your preferred language with a cookie (this page will also tell you what factors were conspiring to deliver spanish as opposed to english). [2003-09-29 16:15:13] kevin at knconsulting dot com Description: I go to www.php.net, I search in the upper right hand corner for 'date' so I can pull up documentation for the date function. This page is displayed in Spanish as well as every other page I click on. Is there a reason everything is in spanish by default? Seems like it should be in English. Thanks, Kevin -- Edit this bug report at http://bugs.php.net/?id=25696&edit=1
#25696 [Bgs->Csd]: PHP Website in Spanish
ID: 25696 User updated by: kevin at knconsulting dot com Reported By: kevin at knconsulting dot com -Status: Bogus +Status: Closed Bug Type: Unknown/Other Function Operating System: Windows XP PHP Version: 4.3.3 New Comment: thank you! Previous Comments: [2003-09-29 17:07:17] [EMAIL PROTECTED] php.net performs a number of actions when you browse to determine what language to best serve the site in. IP address (to resolve back to the country you originate from), your browser's preferred language setting, the last explictly requested langauge, and the specific mirror's default language are all considered. In your case, these values combined to suggest you'd want the display in spanish. To override this value, simply select 'English' explicitly (from a dropdown on any manual page), or goto http://www.php.net/my.php to set your preferred language with a cookie (this page will also tell you what factors were conspiring to deliver spanish as opposed to english). [2003-09-29 16:15:13] kevin at knconsulting dot com Description: I go to www.php.net, I search in the upper right hand corner for 'date' so I can pull up documentation for the date function. This page is displayed in Spanish as well as every other page I click on. Is there a reason everything is in spanish by default? Seems like it should be in English. Thanks, Kevin -- Edit this bug report at http://bugs.php.net/?id=25696&edit=1
#25696 [Opn->Bgs]: PHP Website in Spanish
ID: 25696 Updated by: [EMAIL PROTECTED] Reported By: kevin at knconsulting dot com -Status: Open +Status: Bogus Bug Type: Unknown/Other Function Operating System: Windows XP PHP Version: 4.3.3 New Comment: php.net performs a number of actions when you browse to determine what language to best serve the site in. IP address (to resolve back to the country you originate from), your browser's preferred language setting, the last explictly requested langauge, and the specific mirror's default language are all considered. In your case, these values combined to suggest you'd want the display in spanish. To override this value, simply select 'English' explicitly (from a dropdown on any manual page), or goto http://www.php.net/my.php to set your preferred language with a cookie (this page will also tell you what factors were conspiring to deliver spanish as opposed to english). Previous Comments: [2003-09-29 16:15:13] kevin at knconsulting dot com Description: I go to www.php.net, I search in the upper right hand corner for 'date' so I can pull up documentation for the date function. This page is displayed in Spanish as well as every other page I click on. Is there a reason everything is in spanish by default? Seems like it should be in English. Thanks, Kevin -- Edit this bug report at http://bugs.php.net/?id=25696&edit=1
#25696 [NEW]: PHP Website in Spanish
From: kevin at knconsulting dot com Operating system: Windows XP PHP version: 4.3.3 PHP Bug Type: Unknown/Other Function Bug description: PHP Website in Spanish Description: I go to www.php.net, I search in the upper right hand corner for 'date' so I can pull up documentation for the date function. This page is displayed in Spanish as well as every other page I click on. Is there a reason everything is in spanish by default? Seems like it should be in English. Thanks, Kevin -- Edit bug report at http://bugs.php.net/?id=25696&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25696&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25696&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=25696&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=25696&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=25696&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=25696&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=25696&r=support Expected behavior: http://bugs.php.net/fix.php?id=25696&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=25696&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=25696&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=25696&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25696&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=25696&r=dst IIS Stability: http://bugs.php.net/fix.php?id=25696&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=25696&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=25696&r=float
#24502 [Opn]: Fast CGI interface is broken
ID: 24502 User updated by: gwang at litespeedtech dot com Reported By: gwang at litespeedtech dot com Status: Open Bug Type: CGI related Operating System: Linux -PHP Version: 4.3.2 +PHP Version: 4.3.4 dev Assigned To: shane New Comment: BTW: I tested the latest stable snapshot. Previous Comments: [2003-09-29 16:03:36] gwang at litespeedtech dot com Thank you for the response. Here is the result. Testing url /phpinfo.php/path/info?a=b is used, when set cgi.fix_pathinfo=0, same result (0 is the default according to the comments in the ini file), "no input file" is returned. set cgi.fix_pathinfo=1, the php information page is returned, but _SERVER["PATH_INFO"] and _SERVER["PATH_TRANSLATED"] contain no value and the vlaue of _SERVER["ORIG_"] environment variables are all correct. I don't think set cgi.fix_pathinfo=1 is the right fix for this bug. All correct values are provided in the first place, why waste CPU cycles to try to guess them from other sources? I think the cleanest and probably the easiest fix is to provide a configuration directive to skip all the reverse hacking code. best regards, LiteSpeed Team [2003-09-29 05:58:48] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2003-09-24 12:03:07] [EMAIL PROTECTED] Check php.ini for cgi.fix_pathinfo and try setting it to 1 or 0. [2003-08-25 16:28:02] gwang at litespeedtech dot com This has not been completely fixed in 4.3.3. When there is no PATH_INFO, it works fine. When PATH_INFO is populated, it breaks. Try something like /phpinfo.php/path/info?a=b The reason it breaks is PATH_TRANSLATED is used as the path to the PHP script file instead of SCRIPT_FILENAME when PAHT_INFO is popluated. As our LiteSpeed web server follows the CGI specification, all the code controled by macro #if !DISCARD_PATH and #if ENABLE_PATHINFO_CHECK are not necessory. If PHP is configured with following options, ./configure --enable-fastcgi --enable-discard-path --disable-path-info-check then the testing URL /phpinfo.php/path/info?a=b works just fine except the PHP and Zend logos are missing due to the wrong value of PHP_SELF. According to the comments in the code that the way PHP_SELF populated is to provide backward compatibility for version before 4.3. My question is, is this another reverse hacking for web server that does not follow CGI spec, like Apache? By doing so, PHP_SELF is happen to be the right value for them? If so, those code should be moved inside the section controled by macro ENABLE_PATHINFO_CHECK or !DISCARD_PATH. I think it is better to seperate the reserve hacking code for Apache's fast CGI interface from the others as it is the only odd guy. The code could be much cleaner. Just some suggestions. Sincerely, LiteSpeed Team . [2003-07-04 18:04:00] gwang at litespeedtech dot com Also, when I test it with phpinfo(), if the PATH_INFO is not empty, PHP_SELF is set to PATH_INFO instead of SCRIPT_NAME, then the PHP and Zend logos are missing. 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/24502 -- Edit this bug report at http://bugs.php.net/?id=24502&edit=1
#24502 [NoF->Opn]: Fast CGI interface is broken
ID: 24502 User updated by: gwang at litespeedtech dot com Reported By: gwang at litespeedtech dot com -Status: No Feedback +Status: Open Bug Type: CGI related Operating System: Linux -PHP Version: 4.3.3 +PHP Version: 4.3.2 Assigned To: shane New Comment: Thank you for the response. Here is the result. Testing url /phpinfo.php/path/info?a=b is used, when set cgi.fix_pathinfo=0, same result (0 is the default according to the comments in the ini file), "no input file" is returned. set cgi.fix_pathinfo=1, the php information page is returned, but _SERVER["PATH_INFO"] and _SERVER["PATH_TRANSLATED"] contain no value and the vlaue of _SERVER["ORIG_"] environment variables are all correct. I don't think set cgi.fix_pathinfo=1 is the right fix for this bug. All correct values are provided in the first place, why waste CPU cycles to try to guess them from other sources? I think the cleanest and probably the easiest fix is to provide a configuration directive to skip all the reverse hacking code. best regards, LiteSpeed Team Previous Comments: [2003-09-29 05:58:48] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2003-09-24 12:03:07] [EMAIL PROTECTED] Check php.ini for cgi.fix_pathinfo and try setting it to 1 or 0. [2003-08-25 16:28:02] gwang at litespeedtech dot com This has not been completely fixed in 4.3.3. When there is no PATH_INFO, it works fine. When PATH_INFO is populated, it breaks. Try something like /phpinfo.php/path/info?a=b The reason it breaks is PATH_TRANSLATED is used as the path to the PHP script file instead of SCRIPT_FILENAME when PAHT_INFO is popluated. As our LiteSpeed web server follows the CGI specification, all the code controled by macro #if !DISCARD_PATH and #if ENABLE_PATHINFO_CHECK are not necessory. If PHP is configured with following options, ./configure --enable-fastcgi --enable-discard-path --disable-path-info-check then the testing URL /phpinfo.php/path/info?a=b works just fine except the PHP and Zend logos are missing due to the wrong value of PHP_SELF. According to the comments in the code that the way PHP_SELF populated is to provide backward compatibility for version before 4.3. My question is, is this another reverse hacking for web server that does not follow CGI spec, like Apache? By doing so, PHP_SELF is happen to be the right value for them? If so, those code should be moved inside the section controled by macro ENABLE_PATHINFO_CHECK or !DISCARD_PATH. I think it is better to seperate the reserve hacking code for Apache's fast CGI interface from the others as it is the only odd guy. The code could be much cleaner. Just some suggestions. Sincerely, LiteSpeed Team . [2003-07-04 18:04:00] gwang at litespeedtech dot com Also, when I test it with phpinfo(), if the PATH_INFO is not empty, PHP_SELF is set to PATH_INFO instead of SCRIPT_NAME, then the PHP and Zend logos are missing. [2003-07-04 16:53:44] gwang at litespeedtech dot com Description: Fast CGI interface is broken in both 4.3.2 4.3.3rc1 and the most recent snap shot for web server with Fast CGI implementation that follows CGI specification. Our LiteSpeed web server (at http://www.litespeedtech.com ) supports PHP through the Fast CGI interface (faster than Apache's mod_php). Our Fast CGI implementation follows the CGI specification and set environment variables exactly as what Apache's CGI does. It set SCRIPT_FILENAME=/docroot/info.php and works fine with 4.3.1, but the interface is broken since 4.3.2. Our test shows that SG(request_info).path_translated is not populated with the value of SCRIPT_FILENAME but is NULL. Further study shows that the root cause is at cgi-main.c:812 in release 4.3.2 > script_path_translated=env_path_translated; set script_path_translated to NULL or whatever the value of PATH_TRANSLATED. If we take that line out, every thing works fine. We can use --enable-discard-path to avoid it but it is forbidden in README.FastCGI (We don't know why based on our reading of the source code). I think one possilbe fix is to avoid that line of code for FastCGI, but may need to add some code for Apache's mod_fastcgi. Or change the document, say: --enable-discard-path should be used for web server follows CGI Specs. Sincerely, LiteSpeed Team
#25686 [Bgs->Opn]: XML processing instruction handling feature request
ID: 25686 User updated by: bart at mediawave dot nl Reported By: bart at mediawave dot nl -Status: Bogus +Status: Open Bug Type: Feature/Change Request Operating System: All PHP Version: Irrelevant New Comment: Excuse me if I was not clear enough. This "problem" occurs when parsing the specified XML file with the Expat XML functions. I get this problem with PHP 4.3.2, PHP 4.3.3 and PHP 5.0.0 beta. You can reproduce the problem with the code on http://www.php.net/manual/en/ref.xml.php under "Example 3. External Entity Example" and using the following XML for xmltest.xml: Previous Comments: [2003-09-29 05:42:00] [EMAIL PROTECTED] With PHP 4.3.3 I get the correct output. Disable short-tags maybe? [2003-09-29 04:38:50] bart at mediawave dot nl Description: With the XML parser module PHP currently handles processing instruction code per tag. For example: is seen as an isolated chunk of code. This doesn't work: PHP handles the PHP code per tag. While in this example the code actually spans through 5 tags. But PHP doesn't recognize it this way. Also. For my application it would be desirable if the PHP XML parser would not return the php code. The evaluation of the PHP code in the XML should be hanled by the parser. It should then only return the resulting (evaluated) XML as if it was normal XML. Reproduce code: --- Expected result: 0 1 2 3 Actual result: -- Parse error: parse error, unexpected $end in D:\php-4.3.2\PEAR\wrap_v4\dam.php(544) : eval()'d code on line 1 Parse error: parse error, unexpected T_ENDFOR in D:\php-4.3.2\PEAR\wrap_v4\dam.php(544) : eval()'d code on line 1 -- Edit this bug report at http://bugs.php.net/?id=25686&edit=1
#25695 [NEW]: Stack overflow
From: omar at the-one dot ca Operating system: Windows 2000 Advanced Server PHP version: 4.3.3 PHP Bug Type: Unknown/Other Function Bug description: Stack overflow Description: I found this bug after I installed Zend Optimizer with PHP 4.3.3: PHP has encountered a Stack overflow, on PHPMyAdmin when I clicked on privileges. I commented the zend optimizer stuff on the php.ini to disable zend optimizer and I don't get the error anymore. I just thought to let someone know bout it. -- Edit bug report at http://bugs.php.net/?id=25695&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25695&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25695&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=25695&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=25695&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=25695&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=25695&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=25695&r=support Expected behavior: http://bugs.php.net/fix.php?id=25695&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=25695&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=25695&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=25695&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25695&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=25695&r=dst IIS Stability: http://bugs.php.net/fix.php?id=25695&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=25695&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=25695&r=float
#25694 [NEW]: Round and number_format give inconsistent results.
From: russ at kdimail dot com Operating system: RedHat Linux 7.3 PHP version: 4.3.3 PHP Bug Type: *Math Functions Bug description: Round and number_format give inconsistent results. Description: Round and number_format seem to be rounding the same numbers in different ways, also the output of the "round" function does not match the example given in the php documentation. Round just seems to be always rounding up. Number format seems to be rounding either up or down depending on the value of the number before the decimal point. In my php.ini I have changed precision = 14. Reproduce code: --- echo "round 0.045 = " . round(0.045, 2) . ""; echo "number format 0.045 = " . number_format(0.045, 2) . ""; echo "round 0.055 = " . round(0.055, 2) . ""; echo "number format 0.055 = " . number_format(0.055, 2) . ""; echo "round 5.045 = " . round(5.045, 2) . ""; echo "number format 5.045 = " . number_format(5.045, 2) . ""; echo "round 5.055 = " . round(5.055, 2) . ""; echo "number format 5.055 = " . number_format(5.055, 2) . ""; echo "round 3.025 = " . round(3.025, 2) . ""; echo "number format 3.025 = " . number_format(3.025, 2) . ""; echo "round 4.025 = " . round(4.025, 2) . ""; echo "number format 4.025 = " . number_format(4.025, 2) . ""; Actual result: -- round 0.045 = 0.05 number format 0.045 = 0.05 round 0.055 = 0.06 number format 0.055 = 0.06 round 5.045 = 5.05 number format 5.045 = 5.04 round 5.055 = 5.06 number format 5.055 = 5.05 round 3.025 = 3.03 number format 3.025 = 3.02 round 4.025 = 4.03 number format 4.025 = 4.03 -- Edit bug report at http://bugs.php.net/?id=25694&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25694&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25694&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=25694&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=25694&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=25694&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=25694&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=25694&r=support Expected behavior: http://bugs.php.net/fix.php?id=25694&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=25694&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=25694&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=25694&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25694&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=25694&r=dst IIS Stability: http://bugs.php.net/fix.php?id=25694&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=25694&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=25694&r=float
#20548 [Com]: Decrement ("$x[$y]--") doesn't work on uninitiated variable
ID: 20548 Comment by: lew at mailduct dot com Reported By: prgallier at yahoo dot com Status: Wont fix Bug Type: Scripting Engine problem Operating System: Linux 2.4 PHP Version: 4.3.2-dev New Comment: "IMO, using unitialized variables should cause a FATAL error. Just initialize the variables you use." You miss the point. This is not about uninitialized variables. It is about a GROSS difference between how the increment and decrement operators work! Either *both* operations should fail with uninitialized variables (for consistency and sanity), or *both* operations should succeed (again, for the same reason). By simply saying, "initialize your variables" you avoid looking at the underlying problem and instead apply a band-aid. Band-aids are not a good thing... they come back to bite you later. If "plus" works a certain way, you'd expect "minus" to work the same (meaning, within the same framework of rules). All we are saying is, make them consistent! Previous Comments: [2003-09-27 20:01:38] prgallier at yahoo dot com There are plenty of workarounds, but the problem is the lack of consistency. Either you can or you can't use uninitialized variables. If you can use $test[0]++ you should be able to use $test[0]-- as well (no, I don't think they should drop the ability to use direct increments/decrements). [2003-09-27 16:47:47] [EMAIL PROTECTED] IMO, using unitialized variables should cause a FATAL error. Just initialize the variables you use. [2003-09-27 14:38:53] lew at mailduct dot com PHP 4.3.3 on FreeBSD 4.8-RELEASE: [2003-09-27 14:36:59] lew at mailduct dot com This is a GROSS inconsistency in how the increment/decrement operators work, and one that coders are likely to stumble upon the hard way. Please study the effect of fixing this, at the expense of breaking a long-time quirk in BC. Breaking a quirk, and documenting it on the BC page, is better than maintaining a GROSS inconsistency in one of the basic language construct operators! Please fix this! [2003-08-03 12:57:49] [EMAIL PROTECTED] This is a valid bug, however a fix would be a BC break that would result in a beahviour change that was in place since 3.0 days. 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/20548 -- Edit this bug report at http://bugs.php.net/?id=20548&edit=1
#17662 [Com]: getenv() Apache variables not available
ID: 17662 Comment by: egomez at eudoramail dot com Reported By: garth at cybernode dot com Status: Closed Bug Type: Apache2 related Operating System: SuSE 7.2 PHP Version: 4.2.3 - 200207251200 New Comment: tengo problemas con los script desarrollados en PHP en red hat 9.0 ya que cuando envio una consulta a mysql con las etiquetas form en html estas no me conectan con los script en php4 ahora todo me funciona en red hat 7.2 perfectamente y en RH 9 no funciona nada. Previous Comments: [2002-09-24 01:10:17] garth at cybernode dot com ah - yes, that seems to have done the trick. Though the affected tables still don't show up in phpinfo(). Specifically the tables outlined in my '26 Aug 3:49pm' post. Thanks for the fix. Onto Apache 2 at last. [2002-09-23 22:09:28] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. The bug has been fixed in CVS, not the STABLE branch. You need to checkout 4.3.0-dev from CVS or download http://snaps.php.net/php4-latest.tar.gz [2002-09-23 22:03:53] garth at cybernode dot com Just tried Snapshot php4-STABLE-200209231800 and still the same problem. [2002-09-22 23:15:07] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. [2002-09-19 04:28:32] hsv at hsv dot ping dot de Nearly the same installation, but with Apache section. Look at http://www.edisys.de/phpinfo.php But I have still a variable-passing problem. I installed tutos http://www.tutos.org and no vatriables are passed to the tutos enviroment. Greeting -hsv- 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/17662 -- Edit this bug report at http://bugs.php.net/?id=17662&edit=1
#17604 [Com]: Apache 2/MySQL/PHP4/Sablotron Will not compile
ID: 17604 Comment by: markus at gebert dot net Reported By: kevin at kevinfries dot com Status: No Feedback Bug Type: Compile Failure Operating System: Solaris 8 IA PHP Version: 4.2.1 New Comment: Tested on RedHat 8.0, Apache 1.3.28, PHP 4.3.3: without -lstdc++ compiling failed, after changing the Makefile, PHP seems to compile fine, but starting apache causes the error message already mentioned here: -- Cannot load /usr/local/apache/libexec/libphp4.so into server: ld.so.1: /usr /local/apache-test/bin/httpd: fatal: relocation error: file /usr/local/lib/libsa blot.so.0: symbol __gxx_personality_v0: referenced symbol not found ./apachectl restart: httpd could not be started -- Then I added -lgcc_s to the extra flags as well, which made it work in the end. First I had forgotten to install libjs, which caused exacty the same error message when starting apache. (Sablotron compiled successfully altough libjs was missing). Anyway, using -lstdc++ and -lgcc_s (not forgetting to install libjs :) ) worked out in my case. Previous Comments: [2003-08-29 19:23:38] sthakar at qualys dot com I had the same issue with my php-4.3.2 and sablotron on redhat 9.0. My apache 1.3 would not start. This is what worked perfectly for me. configure php make clean edit Makefile - add "-lstdc++' to the EXTRA_LDFLAGS line make make install The adding of the -lstdc++ resolved my issue and apache started correctly and my phpinfo shows sablotron configured. Sumedh [2003-07-31 17:54:02] dgran at spinweb dot net I just wanted to confirm that I have this problem with php-4.3.2 on Solaris 8 using gcc 3.1. I was able to get php to compile by adding the --disable-cli switch, however when starting apache 1.3.27 I get the following: Syntax error on line 208 of /usr/local/apache-test/ conf/httpd.conf: Cannot load /usr/local/apache-test/libexec/libphp4.so into server: ld.so.1: /usr /local/apache-test/bin/httpd: fatal: relocation error: file /usr/local/lib/libsa blot.so.0: symbol __gxx_personality_v0: referenced symbol not found ./apachectl restart: httpd could not be started I've tried various suggestions in this thread with no luck, but I could be misunderstanding some things. Has anyone else gotten it to work in a similar configuration? [2003-04-17 08:54:46] jnugent at unb dot ca For what it's worth, I had this exact same problem, but on a Slackware 9 machine. I had upgraded my development machine's OS to slackware 9 (from slackware 7), and kept everything else exactly the same. The build was against Apache 2.0.45, PHP 4.3.1, Sablotron 0.98, and Expat 1.95.5. Standard ./configure calls for sablotron and expat. The configure for PHP was: './configure' '--with-apxs2=/usr/local/apache/bin/apxs' '--with-mysql=/usr/local' '--enable-xslt' '--with-xslt-sablot' '--with-gd' '--with-zlib-dir=/usr/local' '--with-expat-dir=/usr/local' The solution to the Sablotron error was to export LDFLAGS=-lstdc++ before running configure. Perhaps that is of use to someone. The other oddity I noticed was that ./configuring PHP with --disable-cli also made the error go away during the build process of PHP. It still broke Apache's ability to run, however. These two servers are identical in every way, with the exception of the differences in slackware installs. The older machine is still running off of GCC 2.95.3, whereas Slackware 9 comes with GCC 3.2.2 (and all assorted GNU utilities). Regards, Jason [2002-10-25 01:00:11] php-bugs at lists dot php dot net No feedback was provided for this bug for over 2 weeks, 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". [2002-10-09 22:15:17] [EMAIL PROTECTED] Could you please provide more information, like why is it refusing to run in particular? 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/17604 -- Edit this bug report at http://bugs.php.net/?id=17604&edit=1
#25669 [Opn->Fbk]: eregi() vs. 8-bit chars in regex
ID: 25669 Updated by: [EMAIL PROTECTED] Reported By: svs at ropnet dot ru -Status: Open +Status: Feedback Bug Type: Regexps related Operating System: FreeBSD 4.8 PHP Version: 4.3.3 New Comment: Yup, if possible. The following is just a template (supposed to be put in ext/standard/tests/reg). Please try to avoid using non-ascii characters in the test case. Thanks in advance. --TEST-- Bug #25669 (eregi() with non-ascii characters) --SKIP-- --FILE-- --EXPECT-- bool(true) bool(false) bool(true) bool(false) Previous Comments: [2003-09-29 12:03:34] svs at ropnet dot ru This one is OK. Should I write a test case? [2003-09-29 11:17:04] [EMAIL PROTECTED] Can you try this one again: http://www.voltex.jp/patches/regpatch.diff Note: This problem is known to not be reproduced with glibc and unfortunately I don't have a freebsd box atm. [2003-09-29 08:08:38] [EMAIL PROTECTED] Ilia: your patch doesn't seem to deal with it correctly, as isalpha() expects signed integer indeed. A char value can be any of the numbers, -128 to 127, so if you cast it to unsigned integer, you never got a value in range of 0 to 255. So you should first cast it to unsigned char, and then make it signed integer. [2003-09-29 06:23:14] svs at ropnet dot ru No, it does not. [2003-09-28 20:14:05] [EMAIL PROTECTED] Try this patch and see if it fixes the problem. http://bb.prohost.org/reg.txt 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/25669 -- Edit this bug report at http://bugs.php.net/?id=25669&edit=1
#25693 [NEW]: No access to posted variables via socket connection
From: a dot erler at brain-at-work dot de
Operating system: Debian
PHP version: 4.3.1
PHP Bug Type: Sockets related
Bug description: No access to posted variables via socket connection
Description:
I'm trying to send some variables via POST with a socket connection to a
HTML form.
The problem:
The socket connection returns HTML-code from the form, but in the form I
can't access the variables I sent (e.g. "go" is not set in $HTTP_POST_VARS
and not in the global scope).
I took the sample code from the PHP manual, section "Stream functions",
"Example 2. Making a POST request to an https server".
I think it should be no problem, that there are additional GET-parameters
in the URI "d_content_kontakt.php" !?
Reproduce code:
---
$sock = fsockopen("linux", 80, $errno, $errstr, 30);
$data = 'go='.urlencode('sent');
fputs($sock, "POST
/caranet_redesign/d_content_kontakt.php?art_angebot=Gebrauchtwagen&id_haendler=0002&id_lang=0001&typ=rm&hersteller=&schlafplaetze=&preis_von=&preis_bis=&id_fahrzeuge=2158
HTTP/1.0\r\n");
fputs($sock, "Host: linux\r\n");
fputs($sock, "Content-type: application/x-www-url-encoded\r\n");
fputs($sock, "Content-length: " . strlen($data) . "\r\n");
fputs($sock, "Accept: */*\r\n");
fputs($sock, "\r\n");
fputs($sock, "$data\r\n");
fputs($sock, "\r\n");
$headers = "";
while ($str = trim(fgets($sock, 4096)))
$headers .= "$str\n";
print "\n";
$body = "";
while (!feof($sock))
$body .= fgets($sock, 4096);
fclose($sock);
Expected result:
variable "go" should contain "sent", but is not set in
d_content_kontakt.php
--
Edit bug report at http://bugs.php.net/?id=25693&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25693&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25693&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=25693&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=25693&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=25693&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=25693&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=25693&r=support
Expected behavior: http://bugs.php.net/fix.php?id=25693&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=25693&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=25693&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=25693&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25693&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=25693&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=25693&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=25693&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=25693&r=float
#25669 [Fbk->Opn]: eregi() vs. 8-bit chars in regex
ID: 25669
User updated by: svs at ropnet dot ru
Reported By: svs at ropnet dot ru
-Status: Feedback
+Status: Open
Bug Type: Regexps related
Operating System: FreeBSD 4.8
PHP Version: 4.3.3
New Comment:
This one is OK. Should I write a test case?
Previous Comments:
[2003-09-29 11:17:04] [EMAIL PROTECTED]
Can you try this one again:
http://www.voltex.jp/patches/regpatch.diff
Note: This problem is known to not be reproduced with glibc and
unfortunately I don't have a freebsd box atm.
[2003-09-29 08:08:38] [EMAIL PROTECTED]
Ilia: your patch doesn't seem to deal with it correctly, as isalpha()
expects signed integer indeed. A char value can be any of the numbers,
-128 to 127, so if you cast it to unsigned integer, you never got a
value in range of 0 to 255. So you should first cast it to unsigned
char, and then make it signed integer.
[2003-09-29 06:23:14] svs at ropnet dot ru
No, it does not.
[2003-09-28 20:14:05] [EMAIL PROTECTED]
Try this patch and see if it fixes the problem.
http://bb.prohost.org/reg.txt
[2003-09-26 09:34:44] svs at ropnet dot ru
oops, mozilla mangled those characters.
begin 644 l.php
M/#]P:'`*R!E8VAO(")B861<;B([
M?0II9B`H<')E9U]M871C:"@B+]$O:2(L("+Q\2(I*2![(&5C:&\@(F]K7&XB
=.R!](&5LR!E8VAO(")B861<;B([?0H_/@H`
`
end
'./configure' '--without-x' '--disable-debug'
'--with-apxs=/usr/local/apache/bin/apxs' '--with-mod_charset'
'--enable-dba' '--with-gdbm=/usr/local' '--with-db4=/usr/local'
'--enable-dbase' '--enable-ftp' '--enable-sockets'
'--enable-inline-optimization' '--enable-memory-limit' '--with-mysql'
'--with-gd' '--enable-gd-native-ttf' '--with-zlib=/usr'
'--with-jpeg-dir=/usr/local' '--with-png-dir=/usr/local'
'--with-freetype-dir=/usr/local' '--enable-exif' '--enable-calendar'
'--enable-wddx' '--with-gmp' '--with-openssl=/usr'
'--with-iconv=/usr/local' '--with-imap=shared,/usr/local'
'--with-curl=/usr/local' '--with-dom=shared,/usr/local'
'--with-dom-xslt=shared,/usr/local'
'--with-dom-exslt=shared,/usr/local' '--enable-xslt=shared'
'--with-xslt-sablot=shared,/usr/local' '--with-iconv-dir=/usr/local'
'--with-expat-dir=/usr/local' '--with-zip=/usr/local' '--with-pdflib'
'--with-tiff-dir=/usr/local'
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/25669
--
Edit this bug report at http://bugs.php.net/?id=25669&edit=1
#12995 [Csd->Opn]: "Failed opening ... in Unknown on line 0
ID: 12995 User updated by: se at brainbits dot net Reported By: se at brainbits dot net -Status: Closed +Status: Open Bug Type: Scripting Engine problem Operating System: SuSE Linux 7.2 -PHP Version: 4.0.6 +PHP Version: 4.3.3 New Comment: Again I have this problem. Now it occurs on an Debian 3.0 with PHP4.3.3 and on a SuSE 7.2 with PHP4.3.2 - both with Apache/1.3.26. But the error-message changed a little bit: Warning: Unknown(prepend.php4): failed to open stream: No such file or directory in Unknown on line 0 Warning: (null)(): Failed opening 'prepend.php4' for inclusion (include_path='.:/www/user1/inc') in Unknown on line 0 Curios: there is no auto_prepend-file and there is no script which includes a file called "prepend.php4" in the host enviroment of user1. There is another user with another virtual hosts who uses a auto_prepend_file called "prepend.php4". But why does this takes effect on the host of user 1? Bye, Sascha Previous Comments: [2003-05-09 07:23:37] [EMAIL PROTECTED] Most likely fixed already. [2003-04-29 11:18:34] se at brainbits dot net Sorry, I am very busy at the moment. I think before end of may I won't be able to test it. Please tell me if I should test it even if takes a long time till you get the feedback. [2003-04-28 11:52:22] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2003-04-25 03:08:11] se at brainbits dot net No, No, I can definitly negate, that this error happens when another process chmod'd the file. With version 4.2.3 we still have this problem. But it doesn't happens as often as under 4.0.6. In the meantime I can also debar, that this only happens under a load of more than 1.0. I saw this error on systems with a load lesser than 0.2. When this error happens, mostly it is quite enough to press the reload-button for a few times. After three to five reloads everything works fine. Here is our current systems under which the error occurs: Debian Woody 3.0 with Apache/1.3.27 and mod_php 4.2.3 [2003-04-16 21:16:50] bishop at platypus dot bc dot ca when I ran into this error, a bit of fiddling made me realize that another process inadvertantly chmod'd the file. Please, se@, can you check that if you see this again? (not a me-too; an idea, maybe) 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/12995 -- Edit this bug report at http://bugs.php.net/?id=12995&edit=1
#25669 [Opn->Fbk]: eregi() vs. 8-bit chars in regex
ID: 25669
Updated by: [EMAIL PROTECTED]
Reported By: svs at ropnet dot ru
-Status: Open
+Status: Feedback
Bug Type: Regexps related
Operating System: FreeBSD 4.8
PHP Version: 4.3.3
New Comment:
Can you try this one again:
http://www.voltex.jp/patches/regpatch.diff
Note: This problem is known to not be reproduced with glibc and
unfortunately I don't have a freebsd box atm.
Previous Comments:
[2003-09-29 08:08:38] [EMAIL PROTECTED]
Ilia: your patch doesn't seem to deal with it correctly, as isalpha()
expects signed integer indeed. A char value can be any of the numbers,
-128 to 127, so if you cast it to unsigned integer, you never got a
value in range of 0 to 255. So you should first cast it to unsigned
char, and then make it signed integer.
[2003-09-29 06:23:14] svs at ropnet dot ru
No, it does not.
[2003-09-28 20:14:05] [EMAIL PROTECTED]
Try this patch and see if it fixes the problem.
http://bb.prohost.org/reg.txt
[2003-09-26 09:34:44] svs at ropnet dot ru
oops, mozilla mangled those characters.
begin 644 l.php
M/#]P:'`*R!E8VAO(")B861<;B([
M?0II9B`H<')E9U]M871C:"@B+]$O:2(L("+Q\2(I*2![(&5C:&\@(F]K7&XB
=.R!](&5LR!E8VAO(")B861<;B([?0H_/@H`
`
end
'./configure' '--without-x' '--disable-debug'
'--with-apxs=/usr/local/apache/bin/apxs' '--with-mod_charset'
'--enable-dba' '--with-gdbm=/usr/local' '--with-db4=/usr/local'
'--enable-dbase' '--enable-ftp' '--enable-sockets'
'--enable-inline-optimization' '--enable-memory-limit' '--with-mysql'
'--with-gd' '--enable-gd-native-ttf' '--with-zlib=/usr'
'--with-jpeg-dir=/usr/local' '--with-png-dir=/usr/local'
'--with-freetype-dir=/usr/local' '--enable-exif' '--enable-calendar'
'--enable-wddx' '--with-gmp' '--with-openssl=/usr'
'--with-iconv=/usr/local' '--with-imap=shared,/usr/local'
'--with-curl=/usr/local' '--with-dom=shared,/usr/local'
'--with-dom-xslt=shared,/usr/local'
'--with-dom-exslt=shared,/usr/local' '--enable-xslt=shared'
'--with-xslt-sablot=shared,/usr/local' '--with-iconv-dir=/usr/local'
'--with-expat-dir=/usr/local' '--with-zip=/usr/local' '--with-pdflib'
'--with-tiff-dir=/usr/local'
[2003-09-26 09:16:38] [EMAIL PROTECTED]
And what was the configure line used to configure PHP?
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/25669
--
Edit this bug report at http://bugs.php.net/?id=25669&edit=1
#25692 [NEW]: global $$formvar fails if $formvar == "array[element]"
From: declan at context dot ie
Operating system: linux
PHP version: Irrelevant
PHP Bug Type: Arrays related
Bug description: global $$formvar fails if $formvar == "array[element]"
Description:
If you pass a variable name to a function and then try to dereference that
variable name for use in a global statement, then the global statement
fails.
I believe the problem lies in the way that global is implemented. If I
have the following:
$ary[foo]="bar";
function use_global($varname) {
global $$varname;
echo "$varname is set to ". $$varname;
}
use_global ("ary[foo]");
then I think that the global line is being re-written to be equivalent to
something like:
$_use_global_varname=&$GLOBALS["ary[foo]"];
whereas, AFAICS, it should be:
$_use_global_varname=&$GLOBALS["ary"]["foo"];
I want to be able to use this construct without having to know whether the
incoming variable is a plain variable or an array element.
Reproduce code:
---
Expected result:
If things worked correctly, the output should be:
global[bar]=2
formvar: global[bar] =2
Actual result:
--
global[bar]=2
formvar: global[bar] =
--
Edit bug report at http://bugs.php.net/?id=25692&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25692&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25692&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=25692&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=25692&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=25692&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=25692&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=25692&r=support
Expected behavior: http://bugs.php.net/fix.php?id=25692&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=25692&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=25692&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=25692&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25692&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=25692&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=25692&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=25692&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=25692&r=float
#25682 [Bgs]: PHP CLI crashes in case php.ini exists
ID: 25682 User updated by: hotta at net-newbie dot com Reported By: hotta at net-newbie dot com Status: Bogus Bug Type: Zend Engine 2 problem Operating System: Vine Linux(dev) PHP Version: 5CVS-2003-09-29 (dev) New Comment: i've downgraded bison to 1.28 and it worked fine. thanks! Previous Comments: [2003-09-29 05:39:21] [EMAIL PROTECTED] Actually bogus, your bison version is broken. (only supported & working version is 1.28) [2003-09-29 05:38:28] [EMAIL PROTECTED] And do not run buildconf!! [2003-09-29 05:38:16] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2003-09-29 00:37:13] hotta at net-newbie dot com my envs are below: $ rpm -qa|grep -e automake -e autoconf -e libtool \ -e bison -e gcc-3 -e glibc-2 glibc-2.3.2-57vl4 libgcc-3.2.3-0vl5 gcc-3.2.3-0vl5 libtool-libs-1.5-5vl1 autoconf-2.57-3vl1 bison-1.875-3vl1 automake-1.7.6-1vl1 libtool-1.5-5vl1 [2003-09-29 00:34:23] hotta at net-newbie dot com Description: if php.ini file exists PHP CLI crashes on startup even though it is a 0-byte file. Reproduce code: --- $ ./buildconf $ ./configure --disable-cgi --enable-debug $ make $ sudo make install $ php -v Expected result: it shows version info. Actual result: -- $ php Segmentation fault (core dumped) $ gdb php core.16001 #0 0x08179264 in ini_parse () at Zend/zend_ini_parser.c:1040 1040 goto yyoverflowlab; (gdb)bt #0 0x08179264 in ini_parse () at Zend/zend_ini_parser.c:1040 #1 0x081790f0 in zend_parse_ini_file (fh=0xb700, unbuffered_errors=1 '\001', ini_parser_cb=0x815abb7 , arg=0x820f800) at zend_ini_parser.y:156 #2 0x0815b2d4 in php_init_config () at /usr/local/src/php-5.0.0/main/php_ini.c:420 #3 0x08156bc4 in php_module_startup (sf=0x820e060, additional_modules=0x0, num_additional_modules=0) at /usr/local/src/php-5.0.0/main/main.c:1390 #4 0x081b7248 in main (argc=1, argv=0xb9c4) at /usr/local/src/php-5.0.0/sapi/cli/php_cli.c:593 #5 0x40204015 in __libc_start_main (main=0x81b70da , argc=1, ubp_av=0xb9c4, init=0x81b89dc <__libc_csu_init>, fini=0x81b8a28 <__libc_csu_fini>, rtld_fini=0x40013020 <_rtld_local>, stack_end=0xbfffbad0) at ../sysdeps/generic/libc-start.c:225 -- Edit this bug report at http://bugs.php.net/?id=25682&edit=1
#25690 [NEW]: call_user_func_array disrespect returned references
From: ask-me at ask-me dot ru
Operating system: All
PHP version: 4.3.3
PHP Bug Type: Scripting Engine problem
Bug description: call_user_func_array disrespect returned references
Description:
Unfortunatly even in version 4.3.3 there was an bug with
"call_user_func_array" function.
call_user_func and call_user_func do respect functions that return
references. That is, function foo that returns a references to an
object, does not return a reference to an object when foo is called via
call_user_func. Instead, foo called via call_user_func returns a "copy"
of the object. (I'm not sure "copy" is the right word.) See the code
example for a concise example of the problem.
Reproduce code:
---
function &testfunction()
{
global $testglobal;
return ($testglobal=1);
}
$testglobal_link=&call_user_func_array("testfunction",array('testparam-1','testparam-2'));
// $testglobal_link must be link to $testglobal at this stage
print $testglobal_link;
// trying to assign new value to $testglobal thru link
$testglobal_link=2;
// in theory we will get "2" as result
print $testglobal;
// but unfortunatly we will have "1" as result
print $testglobal_link;
--
Edit bug report at http://bugs.php.net/?id=25690&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25690&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25690&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=25690&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=25690&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=25690&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=25690&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=25690&r=support
Expected behavior: http://bugs.php.net/fix.php?id=25690&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=25690&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=25690&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=25690&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25690&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=25690&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=25690&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=25690&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=25690&r=float
#25689 [NEW]: RFE for: ceil() floor() functions
From: php at pgregg dot com Operating system: All PHP version: Irrelevant PHP Bug Type: Feature/Change Request Bug description: RFE for: ceil() floor() functions Description: RFE: modify ceil/floor functions so that they take a second optional argument (default 1) that is the factor to which the number is rounded up or down? e.g. you want to round up to the nearest 50? $x = ceil($y, 50); currently you'd have to do: $x = intval(($y+49)/50)*50; This would retain backward compatibility with all code as the default value of 1 would mean that behaviour was the same. -- Edit bug report at http://bugs.php.net/?id=25689&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25689&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25689&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=25689&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=25689&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=25689&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=25689&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=25689&r=support Expected behavior: http://bugs.php.net/fix.php?id=25689&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=25689&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=25689&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=25689&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25689&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=25689&r=dst IIS Stability: http://bugs.php.net/fix.php?id=25689&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=25689&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=25689&r=float
#25688 [Bgs->Opn]: Connect To Oracle 9i using IIS & PHP
ID: 25688 User updated by: ramez at faraah dot com dot sa Reported By: ramez at faraah dot com dot sa -Status: Bogus +Status: Open Bug Type: OCI8 related Operating System: Win XP -PHP Version: 4.3.1 +PHP Version: 4.3.3 New Comment: Hello i try to use PHP4.3.3 but the same problem happen again The Oracle9i comes with Apache but i have in my computer IIS i try To connect to Oracle DB in IIS using PHP4.3.3 i stoped the apache service Previous Comments: [2003-09-29 08:29:23] [EMAIL PROTECTED] And try searching for ORA-12560 with Google for example.. [2003-09-29 08:28:16] [EMAIL PROTECTED] Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to "Open". Again, thank you for your continued support of PHP. We\'re at PHP 4.3.3 already. [2003-09-29 08:25:05] ramez at faraah dot com dot sa Description: Hello I am using Oracle9i release 2 it's comes with Apache but i am using IIS and i don't want to use Apache. how can i connect to Oracle DB from the IIS using PHP i try to use = user:scott Password:tiger Service:RamezDB = how can i do ti Reproduce code: --- Using PHP to Read a Table in Oracle Employees Could not connet to Oracle9i"); $stmt = ociparse($c1," select * from emp"); ociexecute($stmt,OCI_DEFAULT); echo $c1."selecting\n\n"; while (ocifetch($stmt)) echo $c1." <".ociresult($stmt,"TEST").">\n\n"; echo $c1."done\n\n"; Expected result: to reterive the data from Oracle9i Actual result: -- Warning: _oci_open_server: ORA-12560: TNS:protocol adapter error in c:\inetpub\wwwroot\oracle\test.php on line 10 Could not connet to Oracle9i Warning: ociparse(): supplied argument is not a valid OCI8-Connection resource in c:\inetpub\wwwroot\oracle\test.php on line 13 Warning: ociexecute(): supplied argument is not a valid OCI8-Statement resource in c:\inetpub\wwwroot\oracle\test.php on line 14 selecting Warning: ocifetch(): supplied argument is not a valid OCI8-Statement resource in c:\inetpub\wwwroot\oracle\test.php on line 16 done -- Edit this bug report at http://bugs.php.net/?id=25688&edit=1
#25379 [Fbk->Opn]: 'make install' partially broken
ID: 25379 User updated by: marcus at synchromedia dot co dot uk Reported By: marcus at synchromedia dot co dot uk -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: OpenBSD PHP Version: 4.3.3 New Comment: make install-pear gives errors: Installing PEAR environment: /usr/local/lib/php/ PHP Parse error: parse error in /usr/local/src/php- 4.3.3/pear/package-Archive_Tar.xml on line 1 *** Error code 255 Stop in /usr/local/src/php-4.3.3 (line 274 of Makefile). *** Error code 1 Stop in /usr/local/src/php-4.3.3 (line 280 of Makefile). Previous Comments: [2003-09-29 08:27:08] [EMAIL PROTECTED] What does this do: # make install-pear [2003-09-29 07:51:22] marcus at synchromedia dot co dot uk Sorry for the delay in responding. cc -v gives me: Reading specs from /usr/lib/gcc-lib/i386-unknown- openbsd3.1/2.95.3/specs gcc version 2.95.3 20010125 (prerelease) [2003-09-23 22:11:41] [EMAIL PROTECTED] What compiler you have there? [2003-09-22 04:47:23] marcus at synchromedia dot co dot uk Unfortunately I can't. I'm running OpenBSD 3.1-stable, and the docs say: > The current ports tree may not be used with the > previous release. This is due to changes, typically > with the port make process, that require code based > upon the OpenBSD-current source tree. I guess a solution would be to upgrade to OpenBSD 3.4 when it comes out, but that's a whole load of work and downtime I can't afford right now. I can make do with 4.3.2 for now as I was planning on upgrading the whole system for PHP5. I don't know if you want to continue tracking this bug - 3.1 isn't that old (about 15 months), but I don't know how many users it may affect. FWIW, the current PHP5 beta installs ok. [2003-09-19 17:20:40] [EMAIL PROTECTED] Sigh, let me try that again: Have you tried the OpenBSD 3.4 port of PHP-4.3.3? It has quite a few patches to fix issues with the build process that I haven't had a chance to integrate properly with the PHP build process. 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/25379 -- Edit this bug report at http://bugs.php.net/?id=25379&edit=1
#25688 [Bgs]: Connect To Oracle 9i using IIS & PHP
ID: 25688 Updated by: [EMAIL PROTECTED] Reported By: ramez at faraah dot com dot sa Status: Bogus Bug Type: OCI8 related Operating System: Win XP PHP Version: 4.3.1 New Comment: And try searching for ORA-12560 with Google for example.. Previous Comments: [2003-09-29 08:28:16] [EMAIL PROTECTED] Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to "Open". Again, thank you for your continued support of PHP. We\'re at PHP 4.3.3 already. [2003-09-29 08:25:05] ramez at faraah dot com dot sa Description: Hello I am using Oracle9i release 2 it's comes with Apache but i am using IIS and i don't want to use Apache. how can i connect to Oracle DB from the IIS using PHP i try to use = user:scott Password:tiger Service:RamezDB = how can i do ti Reproduce code: --- Using PHP to Read a Table in Oracle Employees Could not connet to Oracle9i"); $stmt = ociparse($c1," select * from emp"); ociexecute($stmt,OCI_DEFAULT); echo $c1."selecting\n\n"; while (ocifetch($stmt)) echo $c1." <".ociresult($stmt,"TEST").">\n\n"; echo $c1."done\n\n"; Expected result: to reterive the data from Oracle9i Actual result: -- Warning: _oci_open_server: ORA-12560: TNS:protocol adapter error in c:\inetpub\wwwroot\oracle\test.php on line 10 Could not connet to Oracle9i Warning: ociparse(): supplied argument is not a valid OCI8-Connection resource in c:\inetpub\wwwroot\oracle\test.php on line 13 Warning: ociexecute(): supplied argument is not a valid OCI8-Statement resource in c:\inetpub\wwwroot\oracle\test.php on line 14 selecting Warning: ocifetch(): supplied argument is not a valid OCI8-Statement resource in c:\inetpub\wwwroot\oracle\test.php on line 16 done -- Edit this bug report at http://bugs.php.net/?id=25688&edit=1
#25688 [Opn->Bgs]: Connect To Oracle 9i using IIS & PHP
ID: 25688 Updated by: [EMAIL PROTECTED] Reported By: ramez at faraah dot com dot sa -Status: Open +Status: Bogus Bug Type: OCI8 related Operating System: Win XP PHP Version: 4.3.1 New Comment: Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to "Open". Again, thank you for your continued support of PHP. We're at PHP 4.3.3 already. Previous Comments: [2003-09-29 08:25:05] ramez at faraah dot com dot sa Description: Hello I am using Oracle9i release 2 it's comes with Apache but i am using IIS and i don't want to use Apache. how can i connect to Oracle DB from the IIS using PHP i try to use = user:scott Password:tiger Service:RamezDB = how can i do ti Reproduce code: --- Using PHP to Read a Table in Oracle Employees Could not connet to Oracle9i"); $stmt = ociparse($c1," select * from emp"); ociexecute($stmt,OCI_DEFAULT); echo $c1."selecting\n\n"; while (ocifetch($stmt)) echo $c1." <".ociresult($stmt,"TEST").">\n\n"; echo $c1."done\n\n"; Expected result: to reterive the data from Oracle9i Actual result: -- Warning: _oci_open_server: ORA-12560: TNS:protocol adapter error in c:\inetpub\wwwroot\oracle\test.php on line 10 Could not connet to Oracle9i Warning: ociparse(): supplied argument is not a valid OCI8-Connection resource in c:\inetpub\wwwroot\oracle\test.php on line 13 Warning: ociexecute(): supplied argument is not a valid OCI8-Statement resource in c:\inetpub\wwwroot\oracle\test.php on line 14 selecting Warning: ocifetch(): supplied argument is not a valid OCI8-Statement resource in c:\inetpub\wwwroot\oracle\test.php on line 16 done -- Edit this bug report at http://bugs.php.net/?id=25688&edit=1
#25379 [Opn->Fbk]: 'make install' partially broken
ID: 25379 Updated by: [EMAIL PROTECTED] Reported By: marcus at synchromedia dot co dot uk -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: OpenBSD PHP Version: 4.3.3 New Comment: What does this do: # make install-pear Previous Comments: [2003-09-29 07:51:22] marcus at synchromedia dot co dot uk Sorry for the delay in responding. cc -v gives me: Reading specs from /usr/lib/gcc-lib/i386-unknown- openbsd3.1/2.95.3/specs gcc version 2.95.3 20010125 (prerelease) [2003-09-23 22:11:41] [EMAIL PROTECTED] What compiler you have there? [2003-09-22 04:47:23] marcus at synchromedia dot co dot uk Unfortunately I can't. I'm running OpenBSD 3.1-stable, and the docs say: > The current ports tree may not be used with the > previous release. This is due to changes, typically > with the port make process, that require code based > upon the OpenBSD-current source tree. I guess a solution would be to upgrade to OpenBSD 3.4 when it comes out, but that's a whole load of work and downtime I can't afford right now. I can make do with 4.3.2 for now as I was planning on upgrading the whole system for PHP5. I don't know if you want to continue tracking this bug - 3.1 isn't that old (about 15 months), but I don't know how many users it may affect. FWIW, the current PHP5 beta installs ok. [2003-09-19 17:20:40] [EMAIL PROTECTED] Sigh, let me try that again: Have you tried the OpenBSD 3.4 port of PHP-4.3.3? It has quite a few patches to fix issues with the build process that I haven't had a chance to integrate properly with the PHP build process. [2003-09-08 05:23:49] marcus at synchromedia dot co dot uk Thanks for looking at this. This snapshot doesn't generate errors, but the resulting installation is still not usable. I still get 'php -v' giving nothing, and 'pear -v' giving PHP info. the results of 'make install' still differ. In 4.3.2 I get: Installing PHP CLI binary:/usr/local/bin/ Installing PHP CLI man page: /usr/local/man/man1/ Installing PHP SAPI module [activating module `php4' in /var/www/conf/httpd.conf] cp libs/libphp4.so /usr/lib/apache/modules/libphp4.so chmod 755 /usr/lib/apache/modules/libphp4.so cp /var/www/conf/httpd.conf /var/www/conf/ httpd.conf.bak cp /var/www/conf/httpd.conf.new /var/www/conf/ httpd.conf rm /var/www/conf/httpd.conf.new Installing shared extensions: /usr/local/lib/php/ extensions/no-debug-non-zts-20020429/ Installing PEAR environment: /usr/local/lib/php/ [PEAR] Archive_Tar- installed: 0.9 [PEAR] Console_Getopt - installed: 1.0 [PEAR] PEAR - installed: 1.1 [PEAR] DB - installed: 1.3 [PEAR] HTTP - installed: 1.2 [PEAR] Mail - installed: 1.0.1 [PEAR] Net_SMTP - installed: 1.0 [PEAR] Net_Socket - installed: 1.0.1 [PEAR] XML_Parser - installed: 1.0.1 [PEAR] XML_RPC- installed: 1.0.4 Installing build environment: /usr/local/lib/php/ build/ Installing header files: /usr/local/include/ php/ Installing helper programs: /usr/local/bin/ program: phpize program: php-config program: phpextdist and in this snapshot I get: Installing PHP CLI binary:/usr/local/bin/ Installing PHP CLI man page: /usr/local/man/man1/ Installing PHP SAPI module: apache [activating module `php4' in /var/www/conf/httpd.conf] cp libs/libphp4.so /usr/lib/apache/modules/libphp4.so chmod 755 /usr/lib/apache/modules/libphp4.so cp /var/www/conf/httpd.conf /var/www/conf/ httpd.conf.bak cp /var/www/conf/httpd.conf.new /var/www/conf/ httpd.conf rm /var/www/conf/httpd.conf.new Installing shared extensions: /usr/local/lib/php/ extensions/no-debug-non-zts-20020429/ Installing PEAR environment: /usr/local/lib/php/ Installing build environment: /usr/local/lib/php/ build/ Installing header files: /usr/local/include/ php/ Installing helper programs: /usr/local/bin/ program: phpize program: php-config program: phpextdist i.e. you can see it's missing a load of PEAR stuff. 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/25379 -- Edit this bug report at http://bugs.php.net/?id=25379&edit=1
#25688 [NEW]: Connect To Oracle 9i using IIS & PHP
From: ramez at faraah dot com dot sa Operating system: Win XP PHP version: 4.3.1 PHP Bug Type: OCI8 related Bug description: Connect To Oracle 9i using IIS & PHP Description: Hello I am using Oracle9i release 2 it's comes with Apache but i am using IIS and i don't want to use Apache. how can i connect to Oracle DB from the IIS using PHP i try to use = user:scott Password:tiger Service:RamezDB = how can i do ti Reproduce code: --- Using PHP to Read a Table in Oracle Employees Could not connet to Oracle9i"); $stmt = ociparse($c1," select * from emp"); ociexecute($stmt,OCI_DEFAULT); echo $c1."selecting\n\n"; while (ocifetch($stmt)) echo $c1." <".ociresult($stmt,"TEST").">\n\n"; echo $c1."done\n\n"; Expected result: to reterive the data from Oracle9i Actual result: -- Warning: _oci_open_server: ORA-12560: TNS:protocol adapter error in c:\inetpub\wwwroot\oracle\test.php on line 10 Could not connet to Oracle9i Warning: ociparse(): supplied argument is not a valid OCI8-Connection resource in c:\inetpub\wwwroot\oracle\test.php on line 13 Warning: ociexecute(): supplied argument is not a valid OCI8-Statement resource in c:\inetpub\wwwroot\oracle\test.php on line 14 selecting Warning: ocifetch(): supplied argument is not a valid OCI8-Statement resource in c:\inetpub\wwwroot\oracle\test.php on line 16 done -- Edit bug report at http://bugs.php.net/?id=25688&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25688&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25688&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=25688&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=25688&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=25688&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=25688&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=25688&r=support Expected behavior: http://bugs.php.net/fix.php?id=25688&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=25688&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=25688&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=25688&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25688&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=25688&r=dst IIS Stability: http://bugs.php.net/fix.php?id=25688&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=25688&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=25688&r=float
#25669 [Opn]: eregi() vs. 8-bit chars in regex
ID: 25669
Updated by: [EMAIL PROTECTED]
Reported By: svs at ropnet dot ru
Status: Open
Bug Type: Regexps related
Operating System: FreeBSD 4.8
PHP Version: 4.3.3
New Comment:
Ilia: your patch doesn't seem to deal with it correctly, as isalpha()
expects signed integer indeed. A char value can be any of the numbers,
-128 to 127, so if you cast it to unsigned integer, you never got a
value in range of 0 to 255. So you should first cast it to unsigned
char, and then make it signed integer.
Previous Comments:
[2003-09-29 06:23:14] svs at ropnet dot ru
No, it does not.
[2003-09-28 20:14:05] [EMAIL PROTECTED]
Try this patch and see if it fixes the problem.
http://bb.prohost.org/reg.txt
[2003-09-26 09:34:44] svs at ropnet dot ru
oops, mozilla mangled those characters.
begin 644 l.php
M/#]P:'`*R!E8VAO(")B861<;B([
M?0II9B`H<')E9U]M871C:"@B+]$O:2(L("+Q\2(I*2![(&5C:&\@(F]K7&XB
=.R!](&5LR!E8VAO(")B861<;B([?0H_/@H`
`
end
'./configure' '--without-x' '--disable-debug'
'--with-apxs=/usr/local/apache/bin/apxs' '--with-mod_charset'
'--enable-dba' '--with-gdbm=/usr/local' '--with-db4=/usr/local'
'--enable-dbase' '--enable-ftp' '--enable-sockets'
'--enable-inline-optimization' '--enable-memory-limit' '--with-mysql'
'--with-gd' '--enable-gd-native-ttf' '--with-zlib=/usr'
'--with-jpeg-dir=/usr/local' '--with-png-dir=/usr/local'
'--with-freetype-dir=/usr/local' '--enable-exif' '--enable-calendar'
'--enable-wddx' '--with-gmp' '--with-openssl=/usr'
'--with-iconv=/usr/local' '--with-imap=shared,/usr/local'
'--with-curl=/usr/local' '--with-dom=shared,/usr/local'
'--with-dom-xslt=shared,/usr/local'
'--with-dom-exslt=shared,/usr/local' '--enable-xslt=shared'
'--with-xslt-sablot=shared,/usr/local' '--with-iconv-dir=/usr/local'
'--with-expat-dir=/usr/local' '--with-zip=/usr/local' '--with-pdflib'
'--with-tiff-dir=/usr/local'
[2003-09-26 09:16:38] [EMAIL PROTECTED]
And what was the configure line used to configure PHP?
[2003-09-26 09:13:01] [EMAIL PROTECTED]
I don't think you meant to use those chars in your example
script..? Can you please add the actual ones 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/25669
--
Edit this bug report at http://bugs.php.net/?id=25669&edit=1
#25379 [NoF->Opn]: 'make install' partially broken
ID: 25379 User updated by: marcus at synchromedia dot co dot uk Reported By: marcus at synchromedia dot co dot uk -Status: No Feedback +Status: Open Bug Type: Compile Failure Operating System: OpenBSD PHP Version: 4.3.3 New Comment: Sorry for the delay in responding. cc -v gives me: Reading specs from /usr/lib/gcc-lib/i386-unknown- openbsd3.1/2.95.3/specs gcc version 2.95.3 20010125 (prerelease) Previous Comments: [2003-09-29 05:58:18] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2003-09-23 22:11:41] [EMAIL PROTECTED] What compiler you have there? [2003-09-22 04:47:23] marcus at synchromedia dot co dot uk Unfortunately I can't. I'm running OpenBSD 3.1-stable, and the docs say: > The current ports tree may not be used with the > previous release. This is due to changes, typically > with the port make process, that require code based > upon the OpenBSD-current source tree. I guess a solution would be to upgrade to OpenBSD 3.4 when it comes out, but that's a whole load of work and downtime I can't afford right now. I can make do with 4.3.2 for now as I was planning on upgrading the whole system for PHP5. I don't know if you want to continue tracking this bug - 3.1 isn't that old (about 15 months), but I don't know how many users it may affect. FWIW, the current PHP5 beta installs ok. [2003-09-19 17:20:40] [EMAIL PROTECTED] Sigh, let me try that again: Have you tried the OpenBSD 3.4 port of PHP-4.3.3? It has quite a few patches to fix issues with the build process that I haven't had a chance to integrate properly with the PHP build process. [2003-09-08 05:23:49] marcus at synchromedia dot co dot uk Thanks for looking at this. This snapshot doesn't generate errors, but the resulting installation is still not usable. I still get 'php -v' giving nothing, and 'pear -v' giving PHP info. the results of 'make install' still differ. In 4.3.2 I get: Installing PHP CLI binary:/usr/local/bin/ Installing PHP CLI man page: /usr/local/man/man1/ Installing PHP SAPI module [activating module `php4' in /var/www/conf/httpd.conf] cp libs/libphp4.so /usr/lib/apache/modules/libphp4.so chmod 755 /usr/lib/apache/modules/libphp4.so cp /var/www/conf/httpd.conf /var/www/conf/ httpd.conf.bak cp /var/www/conf/httpd.conf.new /var/www/conf/ httpd.conf rm /var/www/conf/httpd.conf.new Installing shared extensions: /usr/local/lib/php/ extensions/no-debug-non-zts-20020429/ Installing PEAR environment: /usr/local/lib/php/ [PEAR] Archive_Tar- installed: 0.9 [PEAR] Console_Getopt - installed: 1.0 [PEAR] PEAR - installed: 1.1 [PEAR] DB - installed: 1.3 [PEAR] HTTP - installed: 1.2 [PEAR] Mail - installed: 1.0.1 [PEAR] Net_SMTP - installed: 1.0 [PEAR] Net_Socket - installed: 1.0.1 [PEAR] XML_Parser - installed: 1.0.1 [PEAR] XML_RPC- installed: 1.0.4 Installing build environment: /usr/local/lib/php/ build/ Installing header files: /usr/local/include/ php/ Installing helper programs: /usr/local/bin/ program: phpize program: php-config program: phpextdist and in this snapshot I get: Installing PHP CLI binary:/usr/local/bin/ Installing PHP CLI man page: /usr/local/man/man1/ Installing PHP SAPI module: apache [activating module `php4' in /var/www/conf/httpd.conf] cp libs/libphp4.so /usr/lib/apache/modules/libphp4.so chmod 755 /usr/lib/apache/modules/libphp4.so cp /var/www/conf/httpd.conf /var/www/conf/ httpd.conf.bak cp /var/www/conf/httpd.conf.new /var/www/conf/ httpd.conf rm /var/www/conf/httpd.conf.new Installing shared extensions: /usr/local/lib/php/ extensions/no-debug-non-zts-20020429/ Installing PEAR environment: /usr/local/lib/php/ Installing build environment: /usr/local/lib/php/ build/ Installing header files: /usr/local/include/ php/ Installing helper programs: /usr/local/bin/ program: phpize program: php-config program: phpextdist i.e. you can see it's missing a load of PEAR stuff. 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/25379 -- Edit this bug report at http://bugs.php.
#25666 [Opn->Csd]: XML namespaces broken in PHP5
ID: 25666 Updated by: [EMAIL PROTECTED] Reported By: skissane at ics dot mq dot edu dot au -Status: Open +Status: Closed Bug Type: XML related Operating System: Linux PHP Version: 5CVS-2003-09-25 (dev) New Comment: This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Previous Comments: [2003-09-26 07:48:11] skissane at ics dot mq dot edu dot au My configure line was: ./configure --disable-cgi That's all. [2003-09-26 03:54:27] [EMAIL PROTECTED] What was the configure line you used to configure PHP? [2003-09-25 23:29:36] skissane at ics dot mq dot edu dot au Description: Namespace support by the xml_* functions is broken in PHP5 latest snapshot (works fine in PHP4). Reproduce code: --- http://example.com/foo\"; xmlns:bar=\"http://example.com/bar\";>\n"); xml_parser_free($parser); ?> Expected result: PHP 4.3.3 gives output: http://example.com/[EMAIL PROTECTED] http://example.com/[EMAIL PROTECTED] Actual result: -- http://example.com/foo:a bar:b -- Edit this bug report at http://bugs.php.net/?id=25666&edit=1
#22237 [Com]: PHP crashes when class references property using variable variable
ID: 22237
Comment by: rep at devdomain dot com
Reported By: peter at globalvision dot com dot au
Status: Closed
Bug Type: Zend Engine 2 problem
Operating System: All
PHP Version: 5CVS-2003-02-15 (dev)
New Comment:
Not closed! Using September's 28 PHP5 CVS:
PHP Fatal error: Method name must be a string in
/www/var/template/%%-16/%%-1606537564/Contact.en.tpl.php
And the php file goes like this:
_plugins['function']['mailto'][0](array('address' =>
"[EMAIL PROTECTED]",'encode' => 'javascript'), $this) ; ?>
(Smarty template.)
With this postfilter it works fine:
function dev_smarty_php5b1_fix_postfilter ($sTpl, &$oSmarty) {
return preg_replace (
'/echo (\$this-\>_plugins\[\'\w+\'\]\[\'\w+\'\]\[\d+\])/',
'$dev_php5b1_fix = "{\1}"; echo $dev_php5b1_fix', $sTpl);
}
Previous Comments:
[2003-04-19 20:06:16] peter at globalvision dot com dot au
Yup.. confirmed that the latest CVS no longer crashes...
[2003-04-18 18:14:16] thekid at thekid dot de
No crash here.
In line 1, I assume you're expecting "hi" as an output. This will of
course not work as $bar is not set.
Modify line 1 to read:
echo $this->{$this->bar}
and you will have your expected output. Note that with
error_reporting(E_ALL) you would notice such kinds of mistakes. Also,
var_dump() helps a lot, you can actually see type information instead
of just nothing appearing:)
[EMAIL PROTECTED]:~ > cat | php5
{$this->bar});
var_dump($this->foo);
}
}
$c= new myClass();
$c->test();
?>
string(2) "hi"
string(2) "hi"
[2003-03-23 06:46:27] peter at globalvision dot com dot au
Well... I have not had the time to solve it, but I now know pretty well
why it is caused.
**can someone please have a crack at fixing this**?
In zend_language_parser.y, the rule for object_property is either an
object_dim_list (which can be a T_STRING) or it is a
"variable_without_ibjects".
object_dim_list works for $this->foo, but $this->$foo is matched by
variable_without_objects.
HOWEVER, variable_without_objects is the match for vanilla variables,
so it consumes one '$' before it dereferences.
in other words, $this->$foo sends the $foo part off to the standard
variable compiler area which does not recognise that $foo is a
reference.
I experimented by placing a couple of rules in the lex scanner as
follows:
"$" {
fprintf(stderr,"xxx");
yy_push_state(ST_TEST)
return '$';
}
and
";" {
fprintf(stderr,"yyy");
yy_pop_state(TSRMLS_C);
return ';';
}
{LABEL} {
fprintf(stderr,"zzz");
zendlval->value.str.val = (char *)estrndup(yytext,yyleng);
zendlval->value.str.len = yyleng;
zendlval->type = IS_STRING;
return T_VARIABLE;
}
and suddenly, it all seems to parse, however I'm clearly missing
something - it still does not display the forrect output for
echo $this->$foo;
What am I doing wrong?
[2003-02-22 17:08:49] peter at globalvision dot com dot au
I'm assuming all OSes b/c my original report was MS Windows but a
subsequent dup report was for Linux.
I've narrowed it down a bit by running with debug mode on the ZE2
I'm 99% sure it is due to the way zend treats "$this" as special. I
don't think it's putting all the required data on the stack.
Specifically, when it processes the base_variable_without_objects bison
rule after reading T_OBJECT_OPERATOR (ie -> ) it sets yyval.u.EA.type
(see case 363 in zend_language_parser.c) but yyval.u is zero at that
time when the LH operand is $this.
Not sure why yet...
EG the following modification causes no crash:
$bar;
//echo $this->foo;
}
}
?>
[2003-02-19 06:26:45] root at kitten dot net
This is pretty serious... it prevents pear from working. Can someone
please take a look at it?
Thanks
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/22237
--
Edit this bug report at http://bugs.php.net/?id=22237&edit=1
#25669 [Fbk->Opn]: eregi() vs. 8-bit chars in regex
ID: 25669
User updated by: svs at ropnet dot ru
Reported By: svs at ropnet dot ru
-Status: Feedback
+Status: Open
Bug Type: Regexps related
Operating System: FreeBSD 4.8
PHP Version: 4.3.3
New Comment:
No, it does not.
Previous Comments:
[2003-09-28 20:14:05] [EMAIL PROTECTED]
Try this patch and see if it fixes the problem.
http://bb.prohost.org/reg.txt
[2003-09-26 09:34:44] svs at ropnet dot ru
oops, mozilla mangled those characters.
begin 644 l.php
M/#]P:'`*R!E8VAO(")B861<;B([
M?0II9B`H<')E9U]M871C:"@B+]$O:2(L("+Q\2(I*2![(&5C:&\@(F]K7&XB
=.R!](&5LR!E8VAO(")B861<;B([?0H_/@H`
`
end
'./configure' '--without-x' '--disable-debug'
'--with-apxs=/usr/local/apache/bin/apxs' '--with-mod_charset'
'--enable-dba' '--with-gdbm=/usr/local' '--with-db4=/usr/local'
'--enable-dbase' '--enable-ftp' '--enable-sockets'
'--enable-inline-optimization' '--enable-memory-limit' '--with-mysql'
'--with-gd' '--enable-gd-native-ttf' '--with-zlib=/usr'
'--with-jpeg-dir=/usr/local' '--with-png-dir=/usr/local'
'--with-freetype-dir=/usr/local' '--enable-exif' '--enable-calendar'
'--enable-wddx' '--with-gmp' '--with-openssl=/usr'
'--with-iconv=/usr/local' '--with-imap=shared,/usr/local'
'--with-curl=/usr/local' '--with-dom=shared,/usr/local'
'--with-dom-xslt=shared,/usr/local'
'--with-dom-exslt=shared,/usr/local' '--enable-xslt=shared'
'--with-xslt-sablot=shared,/usr/local' '--with-iconv-dir=/usr/local'
'--with-expat-dir=/usr/local' '--with-zip=/usr/local' '--with-pdflib'
'--with-tiff-dir=/usr/local'
[2003-09-26 09:16:38] [EMAIL PROTECTED]
And what was the configure line used to configure PHP?
[2003-09-26 09:13:01] [EMAIL PROTECTED]
I don't think you meant to use those chars in your example
script..? Can you please add the actual ones here?
[2003-09-26 08:20:57] svs at ropnet dot ru
Description:
Even though locale is set up correctly, eregi() fails to match
international characters case-insensitively. The reason, as far
as I understand, is that code in regex/ passes a negative value to
isalpha(). This can be worked around by recompiling regex/regcomp.c
manually with -funsigned-char (assuming GCC is the compiler).
Reproduce code:
---
Expected result:
ru_RU.KOI8-R
ok
ok
Actual result:
--
ru_RU.KOI8-R
bad
ok
--
Edit this bug report at http://bugs.php.net/?id=25669&edit=1
#24502 [Fbk->NoF]: Fast CGI interface is broken
ID: 24502 Updated by: [EMAIL PROTECTED] Reported By: gwang at litespeedtech dot com -Status: Feedback +Status: No Feedback Bug Type: CGI related Operating System: Linux PHP Version: 4.3.3 Assigned To: shane New Comment: No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. Previous Comments: [2003-09-24 12:03:07] [EMAIL PROTECTED] Check php.ini for cgi.fix_pathinfo and try setting it to 1 or 0. [2003-08-25 16:28:02] gwang at litespeedtech dot com This has not been completely fixed in 4.3.3. When there is no PATH_INFO, it works fine. When PATH_INFO is populated, it breaks. Try something like /phpinfo.php/path/info?a=b The reason it breaks is PATH_TRANSLATED is used as the path to the PHP script file instead of SCRIPT_FILENAME when PAHT_INFO is popluated. As our LiteSpeed web server follows the CGI specification, all the code controled by macro #if !DISCARD_PATH and #if ENABLE_PATHINFO_CHECK are not necessory. If PHP is configured with following options, ./configure --enable-fastcgi --enable-discard-path --disable-path-info-check then the testing URL /phpinfo.php/path/info?a=b works just fine except the PHP and Zend logos are missing due to the wrong value of PHP_SELF. According to the comments in the code that the way PHP_SELF populated is to provide backward compatibility for version before 4.3. My question is, is this another reverse hacking for web server that does not follow CGI spec, like Apache? By doing so, PHP_SELF is happen to be the right value for them? If so, those code should be moved inside the section controled by macro ENABLE_PATHINFO_CHECK or !DISCARD_PATH. I think it is better to seperate the reserve hacking code for Apache's fast CGI interface from the others as it is the only odd guy. The code could be much cleaner. Just some suggestions. Sincerely, LiteSpeed Team . [2003-07-04 18:04:00] gwang at litespeedtech dot com Also, when I test it with phpinfo(), if the PATH_INFO is not empty, PHP_SELF is set to PATH_INFO instead of SCRIPT_NAME, then the PHP and Zend logos are missing. [2003-07-04 16:53:44] gwang at litespeedtech dot com Description: Fast CGI interface is broken in both 4.3.2 4.3.3rc1 and the most recent snap shot for web server with Fast CGI implementation that follows CGI specification. Our LiteSpeed web server (at http://www.litespeedtech.com ) supports PHP through the Fast CGI interface (faster than Apache's mod_php). Our Fast CGI implementation follows the CGI specification and set environment variables exactly as what Apache's CGI does. It set SCRIPT_FILENAME=/docroot/info.php and works fine with 4.3.1, but the interface is broken since 4.3.2. Our test shows that SG(request_info).path_translated is not populated with the value of SCRIPT_FILENAME but is NULL. Further study shows that the root cause is at cgi-main.c:812 in release 4.3.2 > script_path_translated=env_path_translated; set script_path_translated to NULL or whatever the value of PATH_TRANSLATED. If we take that line out, every thing works fine. We can use --enable-discard-path to avoid it but it is forbidden in README.FastCGI (We don't know why based on our reading of the source code). I think one possilbe fix is to avoid that line of code for FastCGI, but may need to add some code for Apache's mod_fastcgi. Or change the document, say: --enable-discard-path should be used for web server follows CGI Specs. Sincerely, LiteSpeed Team -- Edit this bug report at http://bugs.php.net/?id=24502&edit=1
#25130 [Fbk->NoF]: Typos in 'configure' script
ID: 25130
Updated by: [EMAIL PROTECTED]
Reported By: sean dot healey at bayernlb dot co dot uk
-Status: Feedback
+Status: No Feedback
Bug Type: Compile Failure
Operating System: Solaris 9
PHP Version: 5.0.0b2-dev
New Comment:
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
Previous Comments:
[2003-09-23 22:16:24] [EMAIL PROTECTED]
Try this (get latest CVS snap first!):
# ./configure --with-apxs2=/opt/apache/2.0/bin/apxs
# make
[2003-08-19 12:31:41] sean dot healey at bayernlb dot co dot uk
Ok, Not *quite* the same problem.
The issues in the configure script seem to have been resolved, however
we still seem to have the issue with the 'iconv' failing to load.
[2003-08-18 11:46:14] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
many bugs have been fixed in CVS since the beta was released.
[2003-08-18 11:37:56] sean dot healey at bayernlb dot co dot uk
Description:
While trying to get PHP 5.0 to compile, I've found a couple of bugs in
the configure script.
1. There are 2 instances of a call 'grep -E {...args...}'
Under Solaris 9, the '-E' switch is only valid on the alternate version
of grep - '/usr/xpg4/bin/grep'. I added the necessary path to these
calls and the error went away.
2. I found that there are a number of instances of paths being built
containing the string 'usrucb'. This should in fact be '/usr/ucb'.
3. Although I fixed the above, I still can't get it to compile - there
seems to be some issue with inclusion of a library 'iconv'. I supply
the bebug.log file below:
# cat debug.log
CONFIGURE: './configure' '--prefix=/opt/php'
'--localstatedir=/var/php' '--with-apache2=/usr/build/httpd-2.0.47'
'--with-apxs2=/opt/apache/2.0/bin/apxs'
'--with-sybase-ct=/opt/sybase/11.9.2' '--with-db4' '--enable-sysvmsg'
'--enable-sysvsem' '--enable-sysvshm'
CC: gcc
CFLAGS: -g -O2 -pthreads
CPPFLAGS:-D_POSIX_PTHREAD_SEMANTICS -D_POSIX_PTHREAD_SEMANTICS
-D_REENTRANT
CXX:
CXXFLAGS:
INCLUDES:-I/opt/apache/2.0/include -I$(top_builddir)/Zend
-I/usr/include/libxml2 -I/usr/local/include/libxml2
LDFLAGS:-L/usr/local/BerkeleyDB.4.1/lib -ldb-4.1
-R/usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.3
-L/usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.3
-R/usr/local/BerkeleyDB.4.1/lib -L/usr/local/BerkeleyDB.4.1/lib
-R/usr/local/lib -L/usr/local/lib
LIBS: -lz -ldb-4.1 -lresolv -lm -ldl -lnsl -lsocket -lgcc -lxml2
-lz -lm -lsocket -lnsl -lxml2 -lz -liconv -lm -lsocket -lnsl
DLIBS:
SAPI: apache2handler
PHP_RPATHS: /usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.3
/usr/local/BerkeleyDB.4.1/lib /usr/local/lib
uname -a: SunOS tstsvr 5.9 Generic_112233-03 sun4m sparc
SUNW,SPARCstation-20
gcc -o conftest -g -O2 -pthreads -D_POSIX_PTHREAD_SEMANTICS
-D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -L/usr/local/BerkeleyDB.4.1/lib
-ldb-4.1 -R/usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.3
-L/usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.3
-R/usr/local/BerkeleyDB.4.1/lib -L/usr/local/BerkeleyDB.4.1/lib
-R/usr/local/lib -L/usr/local/lib conftest.c -lz -ldb-4.1 -lresolv -lm
-ldl -lnsl -lsocket -lgcc -lxml2 -lz -lm -lsocket -lnsl -lxml2 -lz
-liconv -lm -lsocket -lnsl 1>&5
ld: fatal: library -liconv: not found
ld: fatal: File processing errors. No output written to conftest
collect2: ld returned 1 exit status
In the meantime, I'm going to download and compile the latest stable
version.
Cheers :-)
--
Edit this bug report at http://bugs.php.net/?id=25130&edit=1
#25379 [Fbk->NoF]: 'make install' partially broken
ID: 25379 Updated by: [EMAIL PROTECTED] Reported By: marcus at synchromedia dot co dot uk -Status: Feedback +Status: No Feedback Bug Type: Compile Failure Operating System: OpenBSD PHP Version: 4.3.3 New Comment: No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. Previous Comments: [2003-09-23 22:11:41] [EMAIL PROTECTED] What compiler you have there? [2003-09-22 04:47:23] marcus at synchromedia dot co dot uk Unfortunately I can't. I'm running OpenBSD 3.1-stable, and the docs say: > The current ports tree may not be used with the > previous release. This is due to changes, typically > with the port make process, that require code based > upon the OpenBSD-current source tree. I guess a solution would be to upgrade to OpenBSD 3.4 when it comes out, but that's a whole load of work and downtime I can't afford right now. I can make do with 4.3.2 for now as I was planning on upgrading the whole system for PHP5. I don't know if you want to continue tracking this bug - 3.1 isn't that old (about 15 months), but I don't know how many users it may affect. FWIW, the current PHP5 beta installs ok. [2003-09-19 17:20:40] [EMAIL PROTECTED] Sigh, let me try that again: Have you tried the OpenBSD 3.4 port of PHP-4.3.3? It has quite a few patches to fix issues with the build process that I haven't had a chance to integrate properly with the PHP build process. [2003-09-08 05:23:49] marcus at synchromedia dot co dot uk Thanks for looking at this. This snapshot doesn't generate errors, but the resulting installation is still not usable. I still get 'php -v' giving nothing, and 'pear -v' giving PHP info. the results of 'make install' still differ. In 4.3.2 I get: Installing PHP CLI binary:/usr/local/bin/ Installing PHP CLI man page: /usr/local/man/man1/ Installing PHP SAPI module [activating module `php4' in /var/www/conf/httpd.conf] cp libs/libphp4.so /usr/lib/apache/modules/libphp4.so chmod 755 /usr/lib/apache/modules/libphp4.so cp /var/www/conf/httpd.conf /var/www/conf/ httpd.conf.bak cp /var/www/conf/httpd.conf.new /var/www/conf/ httpd.conf rm /var/www/conf/httpd.conf.new Installing shared extensions: /usr/local/lib/php/ extensions/no-debug-non-zts-20020429/ Installing PEAR environment: /usr/local/lib/php/ [PEAR] Archive_Tar- installed: 0.9 [PEAR] Console_Getopt - installed: 1.0 [PEAR] PEAR - installed: 1.1 [PEAR] DB - installed: 1.3 [PEAR] HTTP - installed: 1.2 [PEAR] Mail - installed: 1.0.1 [PEAR] Net_SMTP - installed: 1.0 [PEAR] Net_Socket - installed: 1.0.1 [PEAR] XML_Parser - installed: 1.0.1 [PEAR] XML_RPC- installed: 1.0.4 Installing build environment: /usr/local/lib/php/ build/ Installing header files: /usr/local/include/ php/ Installing helper programs: /usr/local/bin/ program: phpize program: php-config program: phpextdist and in this snapshot I get: Installing PHP CLI binary:/usr/local/bin/ Installing PHP CLI man page: /usr/local/man/man1/ Installing PHP SAPI module: apache [activating module `php4' in /var/www/conf/httpd.conf] cp libs/libphp4.so /usr/lib/apache/modules/libphp4.so chmod 755 /usr/lib/apache/modules/libphp4.so cp /var/www/conf/httpd.conf /var/www/conf/ httpd.conf.bak cp /var/www/conf/httpd.conf.new /var/www/conf/ httpd.conf rm /var/www/conf/httpd.conf.new Installing shared extensions: /usr/local/lib/php/ extensions/no-debug-non-zts-20020429/ Installing PEAR environment: /usr/local/lib/php/ Installing build environment: /usr/local/lib/php/ build/ Installing header files: /usr/local/include/ php/ Installing helper programs: /usr/local/bin/ program: phpize program: php-config program: phpextdist i.e. you can see it's missing a load of PEAR stuff. [2003-09-07 18:58:27] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip 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/25379 -- Edit this bug report at http://bugs.php.net/?id=25379&edit=
#25517 [Fbk->NoF]: make error with --with-nsapi (THREADLIB)
ID: 25517 Updated by: [EMAIL PROTECTED] Reported By: bmolinari at sitrack dot com -Status: Feedback +Status: No Feedback Bug Type: Informix related Operating System: TRU64/Digital Unix PHP Version: 4.3.3 New Comment: No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. Previous Comments: [2003-09-23 15:20:30] [EMAIL PROTECTED] I read this: http://www-3.ibm.com/software/data/informix/pubs/library/notes/machnote/280/DEC/ESQLC_machine_notes_2.80.txt You're using korn shell, so you should do: # THREADLIB=POSIX # export THREADLIB # make Try this too: # make THREADLIB=POSIX [2003-09-23 07:36:12] bmolinari at sitrack dot com I already try that with, setenv THREADLIB posix but it keeps giving the same annoying error. [2003-09-23 04:24:08] [EMAIL PROTECTED] Try 'export THREADLIB=POSIX' prior to make. [2003-09-12 11:44:14] bmolinari at sitrack dot com Description: Greetings, I searched through the forum pages and the archive and didn't find a solution. Here's what I'm doing - TRU64, with iPlanet in /usr/netscape/server4 and Informix in /disco/home/informix configure --with-nsapi=/usr/netscape/server4 --with-informix=/disco/home/informix Configure runs fine, and produces no errors. Immediately after issue the make command I get /bin/ksh /php-4.3.3/libtool --silent --preserve-dup-deps --mode=compile /php-4.3.3/meta_ccld -Iext/ctype/ -I/php-4.3.3/ext/ctype/ -DPHP_ATOM_INC -I/php-4.3.3/include -I/php-4.3.3/main -I/php-4.3.3 -I/usr/netscape/server4/plugins/include -I/php-4.3.3/Zend -I/php-4.3.3/ext/xml/expat -DIFX_THREAD -I/php-4.3.3/TSRM -DTHREAD=1 -g -pthread -DZTS -prefer-pic -c /php-4.3.3/ext/ctype/ctype.c -o ext/ctype/ctype.lo /bin/ksh /php-4.3.3/libtool --silent --preserve-dup-deps --mode=link /php-4.3.3/meta_ccld -o ext/informix/libphpifx.a (if test -d /disco/home/informix; then THREADLIB=POSIX /disco/home/informix/bin/esql -e -thread -EUHAVE_IFX_IUS /php-4.3.3/ext/informix/ifx.ec; mv ifx.c /php-4.3.3/ext/informix/ifx.c; else touch /php-4.3.3/ext/informix/ifx.c; fi) esql: When using -thread, the THREADLIB environment variable must be set to a supported thread library. Currently supporting: DCE, POSIX(Solaris 2.5 and higher only) and SOL (Solaris Kernel Threads). *** Exit 1 Stop. Any Tips ? Thanks. -- Edit this bug report at http://bugs.php.net/?id=25517&edit=1
#25521 [Fbk->NoF]: corrupt output - garbage characters returned
ID: 25521 Updated by: [EMAIL PROTECTED] Reported By: info at tnext dot com -Status: Feedback +Status: No Feedback Bug Type: IIS related Operating System: Windows2000 iis5 PHP Version: 4CVS-2003-09-12 (stable) New Comment: No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. Previous Comments: [2003-09-23 03:29:52] [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. [2003-09-12 22:05:41] info at tnext dot com Description: I have the same problem as Bug #10193 (which is closed and not solved). Latest Stable CVS running on Windows 2000 IIS5, on a dual processor PC. About every 2 to 5 refreshes of any page or image generated by a php page, garbage characters are returned causing the page to display incorrectly. Each time, the corrupt characters and their position on the page change. I get no errors, just corrupted pages. Example: I get Instead of When I reload the page might be ok or the corruption will be at another position. -- Edit this bug report at http://bugs.php.net/?id=25521&edit=1
#25568 [Fbk->NoF]: feof is not working correctly with fsockopen
ID: 25568
Updated by: [EMAIL PROTECTED]
Reported By: svan at mailgate dot ru
-Status: Feedback
+Status: No Feedback
Bug Type: Filesystem function related
Operating System: Linux
PHP Version: 4.3.3
New Comment:
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
Previous Comments:
[2003-09-24 18:39:25] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
[2003-09-18 01:28:40] svan at mailgate dot ru
No errors. error_reporting is set to E_ALL
[2003-09-17 19:38:15] [EMAIL PROTECTED]
Do you get any errors? (make sure error_reporting is set to E_ALL and
nothing else)
[2003-09-17 02:38:00] svan at mailgate dot ru
Possible workaround:
$fp = fsockopen("www.xx.xx", 80, $errno, $errstr, 30);
if(!$fp)
exit;
fputs($fp, "GET http://www.xx.xx/CENTER.GIF HTTP/1.0\n\n");
$qStr = "";
while(($tmpStr = fgets($fp, 255)))
if($tmpStr == "\r\n") break;
else if( !strncmp($tmpStr, "Content-Length:",
strlen("Content-Length:")) ) $len = (int)substr($tmpStr,
strlen("Content-Length:"));
while( true ){
$rrr = stream_get_meta_data( $fp );
if( $rrr['eof'] == 1 ) break;
$qStr.=fread($fp, $len);
if( strlen( $qStr ) >= $len ) break;
}
fclose($fp);
[2003-09-17 02:33:41] svan at mailgate dot ru
Description:
End of file is not detect coorectly when stream open with fsockopen().
When I read binary data from such stream the end of file detected
absolutely unexpected and before real end.
Reproduce code:
---
$fp = fsockopen("www.xx.xx", 80, $errno, $errstr, 30);
if(!$fp)
exit;
fputs($fp, "GET http://www.xx.xx/CENTER.GIF HTTP/1.0\n\n");
$qStr = "";
while(($tmpStr = fgets($fp, 255)))
if($tmpStr == "\r\n") break;
else if( !strncmp($tmpStr, "Content-Length:",
strlen("Content-Length:")) ) $len = (int)substr($tmpStr,
strlen("Content-Length:"));
$qStr=fread($fp, $len);
fclose($fp);
=== OR ==
$fp = fsockopen("www.xx.xx", 80, $errno, $errstr, 30);
if(!$fp) exit;
fputs($fp, "GET http://www.xx.xx/CENTER.GIF HTTP/1.0\n\n");
$qStr = "";
while(($tmpStr = fgets($fp, 255))) if($tmpStr == "\r\n") break;
while( !feof( $fp ) $qStr .= fread($fp, 1);
fclose($fp);
Expected result:
$qStr contain full content of "CENTER.GIF"
Actual result:
--
$qStr contain cutted content of "CENTER.GIF"
--
Edit this bug report at http://bugs.php.net/?id=25568&edit=1
#25623 [Fbk->NoF]: Memory leak in function load()
ID: 25623 Updated by: [EMAIL PROTECTED] Reported By: maoy at fjii dot com -Status: Feedback +Status: No Feedback Bug Type: OCI8 related Operating System: Windows XP PHP Version: 4.3.3 New Comment: No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. Previous Comments: [2003-09-24 05:41:54] [EMAIL PROTECTED] sorry, if the leak does not show on unix there's not much i can do as i don't run windows. can you compile a debug-build and see if php actually complains about mem-leaks? [2003-09-22 06:04:55] maoy at fjii dot com In fact, I tried to use following codes: ocifetchinto($stmt, $arr,OCI_ASSOC); $result = $arr["CLOB_FLDNAME"]->load(); but it always cause memory leak on Windows system. It doesn't cause memory leak on Linux system. By the way, running environment is: Windows XP Apache 1.3.26 PHP 4.3.3 Oracle 8.1.7 I am looking forward to reply. [2003-09-22 05:09:45] [EMAIL PROTECTED] could you plz replace $result = OCIResult($stmt, "clob_fldname"); if (is_object ($result)) $result = $result->load(); against: ocifetchinto($stmt, $arr,OCI_ASSOC); $result = $arr["CLOB_FLDNAME"]->load(); as this is the code i use all the time and it doesn't (seem) to leak for me. [2003-09-21 22:55:48] maoy at fjii dot com memory leak size relate with value of the field, it also increase along with running times [2003-09-21 22:38:20] maoy at fjii dot com Description: Web Server: Apache 1.3.26 When I get value of a field as Clob type, it always cause memory leak. Reproduce code: --- load(); ?> -- Edit this bug report at http://bugs.php.net/?id=25623&edit=1
#25628 [Fbk->NoF]: Cannot Connect to postgres database
ID: 25628
Updated by: [EMAIL PROTECTED]
Reported By: matt at coffeecup dot com
-Status: Feedback
+Status: No Feedback
Bug Type: PostgreSQL related
Operating System: Red Hat Enterprise Linux ES 2.1
PHP Version: 4.3.4-dev
New Comment:
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
Previous Comments:
[2003-09-22 19:06:59] [EMAIL PROTECTED]
How many apache children do you have at maximum and how many
connections (at maximum) does your postgreSQL allow to connect?
[2003-09-22 14:59:13] matt at coffeecup dot com
This version had the exact same problem.
[2003-09-22 12:23:20] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
[2003-09-22 11:58:16] matt at coffeecup dot com
Description:
I upgraded to php 4.3.3, and started receiving this error when
connecting to postgres:
PHP Warning: pg_connect(): Cannot create new link. Too many open links
(0).
I use the same configure line with php 4.3.2:
./configure --with-apxs=/usr/local/apache/bin/apxs --with-curl
--with-xml --with-mysql=/usr --with-ssl --with-mcrypt
--enable-xslt-sablot --with-gd --with-jpeg-dir=/usr/bin/cjpeg
--with-zlib --with-ttf --with-pgsql
php.ini file remains the same:
; Maximum number of links (persistent+non persistent). -1 means no
limit.
pgsql.max_links = -1
When I re-install 4.3.2, the problem goes away.
Reproduce code:
---
$bd_db = pg_connect ("host=$hostname dbname=$database_name
user=$username password=$password");
Expected result:
A connection to the database given
Actual result:
--
PHP Warning: pg_connect(): Cannot create new link. Too many open links
(0).
--
Edit this bug report at http://bugs.php.net/?id=25628&edit=1
#25631 [Fbk->NoF]: fgets() problem
ID: 25631
Updated by: [EMAIL PROTECTED]
Reported By: marqs10 at hotmail dot com
-Status: Feedback
+Status: No Feedback
Bug Type: *Directory/Filesystem functions
Operating System: XP
PHP Version: 4.3.3
New Comment:
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
Previous Comments:
[2003-09-23 03:24:24] [EMAIL PROTECTED]
Please provide a complete example script, which starts with like PHP scripts usually do..
[2003-09-23 03:14:51] marqs10 at hotmail dot com
Description:
0 in a text file does not have a length- it returns as an empty string;
however,the echo line below does echo a 0 to the screen. There is no
way to differentiate between a blank string and a string containing
"0". I have not tried this on unix system yet, but definately does not
work on windows.
Reproduce code:
---
while(!feof($handle))
{
$buffer= fgets($handle);
echo "$buffer";
if(strlen($buffer!=0))
{
$x=(int)($buffer);
$n=(int)($buffer);
Expected result:
it is a simple program that returns the word "ZERO"
if a 0 is in the buffer and returns a blank line if the buffer is
empty.
Actual result:
--
a blank line is returned regardless if it is a 0 or a blank line.
example data file-
655221583
127334
605
0
0
10
100045
100015015
101015120
012100120
-5000
-2147483648
13
--
Edit this bug report at http://bugs.php.net/?id=25631&edit=1
#25639 [Fbk->NoF]: problem with rand()
ID: 25639 Updated by: [EMAIL PROTECTED] Reported By: adamm at nycap dot rr dot com -Status: Feedback +Status: No Feedback Bug Type: Scripting Engine problem Operating System: windows PHP Version: 4.3.3 New Comment: No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. Previous Comments: [2003-09-23 22:29:00] [EMAIL PROTECTED] Does this happen if you call srand() prior to calling the rand() function? [2003-09-23 18:37:38] adamm at nycap dot rr dot com I downgraded to 4.3.2 and I dont have this problem. I also found several posts on the net about many people on Win XP having this problem with 4.3.3. Definate bug id say. [2003-09-23 18:21:40] adamm at nycap dot rr dot com Description: I am developing on a newly setup Windows XP Box running PHP 4.3.3 on IIS as CGI. The rand() function is not generating random numbers. Even with a min/max declared it will only once generate a number in that range... and than any other time called (even across browser sessions) it will always and forever generate the same number. The code below is broken down to the smallest example possible. Reproduce code: --- Expected result: I expect to see a random number. Actual result: -- The same number is always displayed. -- Edit this bug report at http://bugs.php.net/?id=25639&edit=1
#25641 [Fbk->NoF]: ftp_rawlist long list retrive fail after 60 sec
ID: 25641
Updated by: [EMAIL PROTECTED]
Reported By: sentomas at hotmail dot com
-Status: Feedback
+Status: No Feedback
Bug Type: FTP related
Operating System: FreeBSD
PHP Version: 4.3.3
New Comment:
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
Previous Comments:
[2003-09-24 13:32:54] [EMAIL PROTECTED]
Your use of ftp_rawlist is incorrect. The second argument must contain
a path (otherwise a -- technicly -- invalid command is sent to the
server).
Try again with ftp_rawlist($conn_if, "-lR /");
(Passing -lR as arguments, while undocumented, will at least not result
in invalid behavior)
I'm not saying this is necessarily the problem (in fact it's probably
not), but I'd like to rule it out.
In the mean time, are you querying a public FTP server? If so which
one? (I'd like to reproduce the precise circumstances). If it's a
private FTP, it would help to at least know what FTP daemon is running
(i.e.: ProFTPd, IIS, etc...)
[2003-09-24 06:22:11] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
[2003-09-24 05:42:17] sentomas at hotmail dot com
Description:
if the ftp list so long that can retrive in 60sec, the ftp_rawlist()
automaticly fail.
I re-set FTP timeout and default_socket timeout and of cause use
commandline mode , but it didnt seems to work.
Reproduce code:
---
//-lR option in order to make ftp server reply whole dir list, which
might be very very long, so its take time more than 60 sec.
$dirlist = ftp_rawlist($conn_id, "-lR");
if ($dirlist === false){
//defintely fail whatever you do after 60sec
//commandline mode
return "fail";
}
Expected result:
might be some kind of "default_socket_timeout" limit in inter-core?
because i saw the ftp.c will write to the list tmpfile first then
output to array.
--
Edit this bug report at http://bugs.php.net/?id=25641&edit=1
#25684 [Bgs->WFx]: segmentation fault in java.php
ID: 25684 Updated by: [EMAIL PROTECTED] Reported By: fperez at tuzsa dot es -Status: Bogus +Status: Wont fix Bug Type: Java related Operating System: RedHat Linux 7.3 PHP Version: 4.3.3 New Comment: Any report which says 'crashed' is related. The java extension in PHP 4 is unmaintained and considered extremely experimental..it doesn't even exist in PHP 5 (yet) for which it will be rewritten. Wait for PHP 5. Changed status to 'wont fix' which is more appropriate for this. Previous Comments: [2003-09-29 05:43:46] fperez at tuzsa dot es I have tried to find any bug report with this same result. I have found several bug reports what seems to be pretty near to my results, but with different (old) versions or different operating system. After your note, I have tried to find any bug report with: java enable-debug (or) java segmentation fault I have found a lot of bug reports, specially with the second searches. But all of them are closed or bogus and the opened reports I could find seems different for me. Please, could you send me the bug report number to follow its progress ? I am sure it is there but I cannot find it. Thanks a lot and congratulations for your job. [2003-09-29 05:31:27] [EMAIL PROTECTED] 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. Because of this, we hope you add your comments to the existing bug instead. Thank you for your interest in PHP. This has been reported many many times before, check back when PHP 5 is released.. [2003-09-29 04:57:39] fperez at tuzsa dot es A new note: if I configure php without --enable-debug and execute the java.php url page within Zend Studio (Zend Development environment) then execution script and results goes ok again. Thanks. [2003-09-29 03:31:01] fperez at tuzsa dot es Description: Hello, Apache 1.3.28, php-4.3.3, RedHat 7.3, java 1.4.2_01. I have configured ld.so.conf with the java_paths and I have configured, also, export LD_LIBRARY_PATH java_paths on /usr/local/apache/bin/apachectl I have a segmentation fault which is difficult to report you because: 1.- If I compile php without --enable-debug I always obtain a segmentation fault running java.php (java.php=example 1 in http://www.php.net/manual/en/ref.java.php). 2.- If I compile php WITH --enable-debug then the same script (java.php) runs fine without any problem. Because of that I cannot send you a backtrace or something else with --enable-debug. :-( What I should to do ? How can I sent you more information ? Thanks PS: Of course, I have the same problem with other php/java scripts and, again, if I compile php with --enable-debug, all crashes goes out. Reproduce code: --- EXAMPLE 1. in: http://www.php.net/manual/en/ref.java.php Actual result: -- Sometimes I obtain a whole empty page and this apache error_log (note the strange characters on the first line after NoSuchMethodException): [Mon Sep 29 09:19:37 2003] [error] PHP Warning: java.lang.NoSuchMethodException: Þ7 in /www/tuzsa/java.php on line 16 [Mon Sep 29 09:19:37 2003] [notice] child pid 1661 exit signal Segmentation fault (11) Sometimes I obtain this results (note the date/time formated result aren't) === Java version=1.4.2_01 Java vendor=Sun Microsystems Inc. OS=Linux 2.4.18-3smp on i386 === And I have this, again, in the apache error log: [Mon Sep 29 09:23:01 2003] [error] PHP Warning: java.lang.NoSuchMethodException: ÔH? in /www/tuzsa/java.php on line 16 [Mon Sep 29 09:23:03 2003] [notice] child pid 1662 exit signal Segmentation fault (11) -- Edit this bug report at http://bugs.php.net/?id=25684&edit=1
#25684 [Bgs]: segmentation fault in java.php
ID: 25684 User updated by: fperez at tuzsa dot es Reported By: fperez at tuzsa dot es Status: Bogus Bug Type: Java related Operating System: RedHat Linux 7.3 PHP Version: 4.3.3 New Comment: I have tried to find any bug report with this same result. I have found several bug reports what seems to be pretty near to my results, but with different (old) versions or different operating system. After your note, I have tried to find any bug report with: java enable-debug (or) java segmentation fault I have found a lot of bug reports, specially with the second searches. But all of them are closed or bogus and the opened reports I could find seems different for me. Please, could you send me the bug report number to follow its progress ? I am sure it is there but I cannot find it. Thanks a lot and congratulations for your job. Previous Comments: [2003-09-29 05:31:27] [EMAIL PROTECTED] 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. Because of this, we hope you add your comments to the existing bug instead. Thank you for your interest in PHP. This has been reported many many times before, check back when PHP 5 is released.. [2003-09-29 04:57:39] fperez at tuzsa dot es A new note: if I configure php without --enable-debug and execute the java.php url page within Zend Studio (Zend Development environment) then execution script and results goes ok again. Thanks. [2003-09-29 03:31:01] fperez at tuzsa dot es Description: Hello, Apache 1.3.28, php-4.3.3, RedHat 7.3, java 1.4.2_01. I have configured ld.so.conf with the java_paths and I have configured, also, export LD_LIBRARY_PATH java_paths on /usr/local/apache/bin/apachectl I have a segmentation fault which is difficult to report you because: 1.- If I compile php without --enable-debug I always obtain a segmentation fault running java.php (java.php=example 1 in http://www.php.net/manual/en/ref.java.php). 2.- If I compile php WITH --enable-debug then the same script (java.php) runs fine without any problem. Because of that I cannot send you a backtrace or something else with --enable-debug. :-( What I should to do ? How can I sent you more information ? Thanks PS: Of course, I have the same problem with other php/java scripts and, again, if I compile php with --enable-debug, all crashes goes out. Reproduce code: --- EXAMPLE 1. in: http://www.php.net/manual/en/ref.java.php Actual result: -- Sometimes I obtain a whole empty page and this apache error_log (note the strange characters on the first line after NoSuchMethodException): [Mon Sep 29 09:19:37 2003] [error] PHP Warning: java.lang.NoSuchMethodException: Þ7 in /www/tuzsa/java.php on line 16 [Mon Sep 29 09:19:37 2003] [notice] child pid 1661 exit signal Segmentation fault (11) Sometimes I obtain this results (note the date/time formated result aren't) === Java version=1.4.2_01 Java vendor=Sun Microsystems Inc. OS=Linux 2.4.18-3smp on i386 === And I have this, again, in the apache error log: [Mon Sep 29 09:23:01 2003] [error] PHP Warning: java.lang.NoSuchMethodException: ÔH? in /www/tuzsa/java.php on line 16 [Mon Sep 29 09:23:03 2003] [notice] child pid 1662 exit signal Segmentation fault (11) -- Edit this bug report at http://bugs.php.net/?id=25684&edit=1
#25686 [Opn->Bgs]: XML processing instruction handling feature request
ID: 25686 Updated by: [EMAIL PROTECTED] Reported By: bart at mediawave dot nl -Status: Open +Status: Bogus Bug Type: Feature/Change Request Operating System: All PHP Version: Irrelevant New Comment: With PHP 4.3.3 I get the correct output. Disable short-tags maybe? Previous Comments: [2003-09-29 04:38:50] bart at mediawave dot nl Description: With the XML parser module PHP currently handles processing instruction code per tag. For example: is seen as an isolated chunk of code. This doesn't work: PHP handles the PHP code per tag. While in this example the code actually spans through 5 tags. But PHP doesn't recognize it this way. Also. For my application it would be desirable if the PHP XML parser would not return the php code. The evaluation of the PHP code in the XML should be hanled by the parser. It should then only return the resulting (evaluated) XML as if it was normal XML. Reproduce code: --- Expected result: 0 1 2 3 Actual result: -- Parse error: parse error, unexpected $end in D:\php-4.3.2\PEAR\wrap_v4\dam.php(544) : eval()'d code on line 1 Parse error: parse error, unexpected T_ENDFOR in D:\php-4.3.2\PEAR\wrap_v4\dam.php(544) : eval()'d code on line 1 -- Edit this bug report at http://bugs.php.net/?id=25686&edit=1
#25682 [Fbk->Bgs]: PHP CLI crashes in case php.ini exists
ID: 25682 Updated by: [EMAIL PROTECTED] Reported By: hotta at net-newbie dot com -Status: Feedback +Status: Bogus Bug Type: Zend Engine 2 problem Operating System: Vine Linux(dev) PHP Version: 5CVS-2003-09-29 (dev) New Comment: Actually bogus, your bison version is broken. (only supported & working version is 1.28) Previous Comments: [2003-09-29 05:38:28] [EMAIL PROTECTED] And do not run buildconf!! [2003-09-29 05:38:16] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2003-09-29 00:37:13] hotta at net-newbie dot com my envs are below: $ rpm -qa|grep -e automake -e autoconf -e libtool \ -e bison -e gcc-3 -e glibc-2 glibc-2.3.2-57vl4 libgcc-3.2.3-0vl5 gcc-3.2.3-0vl5 libtool-libs-1.5-5vl1 autoconf-2.57-3vl1 bison-1.875-3vl1 automake-1.7.6-1vl1 libtool-1.5-5vl1 [2003-09-29 00:34:23] hotta at net-newbie dot com Description: if php.ini file exists PHP CLI crashes on startup even though it is a 0-byte file. Reproduce code: --- $ ./buildconf $ ./configure --disable-cgi --enable-debug $ make $ sudo make install $ php -v Expected result: it shows version info. Actual result: -- $ php Segmentation fault (core dumped) $ gdb php core.16001 #0 0x08179264 in ini_parse () at Zend/zend_ini_parser.c:1040 1040 goto yyoverflowlab; (gdb)bt #0 0x08179264 in ini_parse () at Zend/zend_ini_parser.c:1040 #1 0x081790f0 in zend_parse_ini_file (fh=0xb700, unbuffered_errors=1 '\001', ini_parser_cb=0x815abb7 , arg=0x820f800) at zend_ini_parser.y:156 #2 0x0815b2d4 in php_init_config () at /usr/local/src/php-5.0.0/main/php_ini.c:420 #3 0x08156bc4 in php_module_startup (sf=0x820e060, additional_modules=0x0, num_additional_modules=0) at /usr/local/src/php-5.0.0/main/main.c:1390 #4 0x081b7248 in main (argc=1, argv=0xb9c4) at /usr/local/src/php-5.0.0/sapi/cli/php_cli.c:593 #5 0x40204015 in __libc_start_main (main=0x81b70da , argc=1, ubp_av=0xb9c4, init=0x81b89dc <__libc_csu_init>, fini=0x81b8a28 <__libc_csu_fini>, rtld_fini=0x40013020 <_rtld_local>, stack_end=0xbfffbad0) at ../sysdeps/generic/libc-start.c:225 -- Edit this bug report at http://bugs.php.net/?id=25682&edit=1
#25683 [Bgs]: Send mail from any address
ID: 25683 User updated by: reveille187 at hotmail dot com Reported By: reveille187 at hotmail dot com Status: Bogus Bug Type: Mail related Operating System: win32 xp sp1 PHP Version: 4.3.2 New Comment: just checking, someone can cause some nice havoc with that feature. sorry. Previous Comments: [2003-09-29 05:36:43] [EMAIL PROTECTED] RTFM. It's feature, not bug. [2003-09-29 03:26:07] reveille187 at hotmail dot com Description: I'm not sure if anyone else noticed this... I run php 4.3.2 on my windows xp pc with apache 1.3. I don't have a domain name, and while exploring options on how to send mail from my pc, I found out you could send email from any address to anyone else without knowing thier password. Eg/ I could send hate mail from [EMAIL PROTECTED] where my real address is [EMAIL PROTECTED] Reproduce code: --- Expected result: An email in my inbox from you. Actual result: -- Same as above. -- Edit this bug report at http://bugs.php.net/?id=25683&edit=1
#25682 [Fbk]: PHP CLI crashes in case php.ini exists
ID: 25682 Updated by: [EMAIL PROTECTED] Reported By: hotta at net-newbie dot com Status: Feedback Bug Type: Zend Engine 2 problem Operating System: Vine Linux(dev) PHP Version: 5CVS-2003-09-29 (dev) New Comment: And do not run buildconf!! Previous Comments: [2003-09-29 05:38:16] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2003-09-29 00:37:13] hotta at net-newbie dot com my envs are below: $ rpm -qa|grep -e automake -e autoconf -e libtool \ -e bison -e gcc-3 -e glibc-2 glibc-2.3.2-57vl4 libgcc-3.2.3-0vl5 gcc-3.2.3-0vl5 libtool-libs-1.5-5vl1 autoconf-2.57-3vl1 bison-1.875-3vl1 automake-1.7.6-1vl1 libtool-1.5-5vl1 [2003-09-29 00:34:23] hotta at net-newbie dot com Description: if php.ini file exists PHP CLI crashes on startup even though it is a 0-byte file. Reproduce code: --- $ ./buildconf $ ./configure --disable-cgi --enable-debug $ make $ sudo make install $ php -v Expected result: it shows version info. Actual result: -- $ php Segmentation fault (core dumped) $ gdb php core.16001 #0 0x08179264 in ini_parse () at Zend/zend_ini_parser.c:1040 1040 goto yyoverflowlab; (gdb)bt #0 0x08179264 in ini_parse () at Zend/zend_ini_parser.c:1040 #1 0x081790f0 in zend_parse_ini_file (fh=0xb700, unbuffered_errors=1 '\001', ini_parser_cb=0x815abb7 , arg=0x820f800) at zend_ini_parser.y:156 #2 0x0815b2d4 in php_init_config () at /usr/local/src/php-5.0.0/main/php_ini.c:420 #3 0x08156bc4 in php_module_startup (sf=0x820e060, additional_modules=0x0, num_additional_modules=0) at /usr/local/src/php-5.0.0/main/main.c:1390 #4 0x081b7248 in main (argc=1, argv=0xb9c4) at /usr/local/src/php-5.0.0/sapi/cli/php_cli.c:593 #5 0x40204015 in __libc_start_main (main=0x81b70da , argc=1, ubp_av=0xb9c4, init=0x81b89dc <__libc_csu_init>, fini=0x81b8a28 <__libc_csu_fini>, rtld_fini=0x40013020 <_rtld_local>, stack_end=0xbfffbad0) at ../sysdeps/generic/libc-start.c:225 -- Edit this bug report at http://bugs.php.net/?id=25682&edit=1
#25682 [Opn->Fbk]: PHP CLI crashes in case php.ini exists
ID: 25682 Updated by: [EMAIL PROTECTED] Reported By: hotta at net-newbie dot com -Status: Open +Status: Feedback Bug Type: Zend Engine 2 problem Operating System: Vine Linux(dev) PHP Version: 5CVS-2003-09-29 (dev) New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip Previous Comments: [2003-09-29 00:37:13] hotta at net-newbie dot com my envs are below: $ rpm -qa|grep -e automake -e autoconf -e libtool \ -e bison -e gcc-3 -e glibc-2 glibc-2.3.2-57vl4 libgcc-3.2.3-0vl5 gcc-3.2.3-0vl5 libtool-libs-1.5-5vl1 autoconf-2.57-3vl1 bison-1.875-3vl1 automake-1.7.6-1vl1 libtool-1.5-5vl1 [2003-09-29 00:34:23] hotta at net-newbie dot com Description: if php.ini file exists PHP CLI crashes on startup even though it is a 0-byte file. Reproduce code: --- $ ./buildconf $ ./configure --disable-cgi --enable-debug $ make $ sudo make install $ php -v Expected result: it shows version info. Actual result: -- $ php Segmentation fault (core dumped) $ gdb php core.16001 #0 0x08179264 in ini_parse () at Zend/zend_ini_parser.c:1040 1040 goto yyoverflowlab; (gdb)bt #0 0x08179264 in ini_parse () at Zend/zend_ini_parser.c:1040 #1 0x081790f0 in zend_parse_ini_file (fh=0xb700, unbuffered_errors=1 '\001', ini_parser_cb=0x815abb7 , arg=0x820f800) at zend_ini_parser.y:156 #2 0x0815b2d4 in php_init_config () at /usr/local/src/php-5.0.0/main/php_ini.c:420 #3 0x08156bc4 in php_module_startup (sf=0x820e060, additional_modules=0x0, num_additional_modules=0) at /usr/local/src/php-5.0.0/main/main.c:1390 #4 0x081b7248 in main (argc=1, argv=0xb9c4) at /usr/local/src/php-5.0.0/sapi/cli/php_cli.c:593 #5 0x40204015 in __libc_start_main (main=0x81b70da , argc=1, ubp_av=0xb9c4, init=0x81b89dc <__libc_csu_init>, fini=0x81b8a28 <__libc_csu_fini>, rtld_fini=0x40013020 <_rtld_local>, stack_end=0xbfffbad0) at ../sysdeps/generic/libc-start.c:225 -- Edit this bug report at http://bugs.php.net/?id=25682&edit=1
#25683 [Opn->Bgs]: Send mail from any address
ID: 25683 Updated by: [EMAIL PROTECTED] Reported By: reveille187 at hotmail dot com -Status: Open +Status: Bogus Bug Type: *Mail Related Operating System: win32 xp sp1 PHP Version: 4.3.2 New Comment: RTFM. It's feature, not bug. Previous Comments: [2003-09-29 03:26:07] reveille187 at hotmail dot com Description: I'm not sure if anyone else noticed this... I run php 4.3.2 on my windows xp pc with apache 1.3. I don't have a domain name, and while exploring options on how to send mail from my pc, I found out you could send email from any address to anyone else without knowing thier password. Eg/ I could send hate mail from [EMAIL PROTECTED] where my real address is [EMAIL PROTECTED] Reproduce code: --- Expected result: An email in my inbox from you. Actual result: -- Same as above. -- Edit this bug report at http://bugs.php.net/?id=25683&edit=1
#25687 [Opn->Ver]: "Segmentation fault" - trying to inherit >2 classes and to call parent constr.
ID: 25687
Updated by: [EMAIL PROTECTED]
Reported By: kostyal at realeastnetworks dot com
-Status: Open
+Status: Verified
Bug Type: Class/Object related
-Operating System: Debian GNU/Linux 2.4.21-5-k7
+Operating System: *
-PHP Version: 4.3.3
+PHP Version: 5CVS, 4CVS
Previous Comments:
[2003-09-29 05:20:59] kostyal at realeastnetworks dot com
Description:
Description:
Segmentation fault occurs when trying to inherit more then two classes
and to call parent constructors (see example to understand how I'm
trying to do it).
When I comment last "call_constr()" call, the problem disappears.
Configure Command:
'../configure' '--prefix=/usr' '--with-apxs=/usr/bin/apxs'
'--with-regex=php' '--with-config-file-path=/etc/php4/apache'
'--disable-rpath' '--disable-debug' '--enable-memory-limit'
'--with-layout=GNU' '--with-pear=/usr/share/php' '--enable-calendar'
'--enable-sysvsem' '--enable-sysvshm' '--enable-track-vars'
'--enable-trans-sid' '--enable-bcmath' '--with-bz2' '--enable-ctype'
'--with-db4' '--with-iconv' '--enable-exif' '--enable-filepro'
'--enable-ftp' '--with-gettext' '--enable-mbstring'
'--with-pcre-regex=/usr' '--enable-shmop' '--enable-sockets'
'--enable-wddx' '--disable-xml' '--with-expat-dir=/usr' '--enable-yp'
'--with-zlib' '--without-pgsql' '--with-kerberos=/usr'
'--with-openssl=/usr' '--with-exec-dir=/usr/lib/php4/libexec'
'--disable-static' '--with-curl=shared,/usr' '--with-dom=shared,/usr'
'--with-dom-xslt=shared,/usr' '--with-dom-exslt=shared,/usr'
'--with-zlib-dir=/usr' '--with-gd=shared,/usr'
'--with-jpeg-dir=shared,/usr' '--with-xpm-dir=shared,/usr/X11R6'
'--with-png-dir=shared,/usr' '--with-freetype-dir=shared,/usr'
'--with-imap=shared,/usr' '--with-imap-ssl' '--with-ldap=shared,/usr'
'--with-mcal=shared,/usr' '--with-mhash=shared,/usr' '--with-mm'
'--with-mysql=shared,/usr' '--with-unixODBC=shared,/usr'
'--with-recode=shared,/usr' '--enable-xslt=shared'
'--with-xslt-sablot=shared,/usr' '--with-snmp=shared'
'--enable-ucd-snmp-hack' '--with-sybase-ct=shared,/usr'
'--with-ttf=shared,/usr' '--with-t1lib=shared,/usr'
Reproduce code:
---
class object {
function call_constr() {
$par=get_parent_class($this);
$this->$par();
}
}
class Graph extends object {
function Graph() {
}
}
class TwinGraph extends Graph {
function TwinGraph() {
$this->call_constr(); // calling parent constructor
}
}
class TwinBarChart extends TwinGraph {
function TwinBarChart() {
$this->call_constr(); // calling parent constructor
echo "Test";
}
}
$graph=new TwinBarChart();
Expected result:
Test
Actual result:
--
Segmentation fault
--
Edit this bug report at http://bugs.php.net/?id=25687&edit=1
#25685 [Opn->Bgs]: Access Violation
ID: 25685 Updated by: [EMAIL PROTECTED] Reported By: peter dot siebert at gsw-mainz dot de -Status: Open +Status: Bogus Bug Type: *Mail Related Operating System: Windows 2k Pro PHP Version: 4.3.1 New Comment: This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Too old version. Previous Comments: [2003-09-29 04:36:00] peter dot siebert at gsw-mainz dot de Description: I use an ArgoSoft Mailserver and IIS locally. When I send an e-Mail with the mail-function I get the following error: PHP has encountered an Access Violation at 01897BD4. In php.ini the value smtp is set to localhost and send_from is set to [EMAIL PROTECTED] Peter -- Edit this bug report at http://bugs.php.net/?id=25685&edit=1
#25684 [Opn->Bgs]: segmentation fault in java.php
ID: 25684 Updated by: [EMAIL PROTECTED] Reported By: fperez at tuzsa dot es -Status: Open +Status: Bogus Bug Type: Reproducible crash Operating System: RedHat Linux 7.3 PHP Version: 4.3.3 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. Because of this, we hope you add your comments to the existing bug instead. Thank you for your interest in PHP. This has been reported many many times before, check back when PHP 5 is released.. Previous Comments: [2003-09-29 04:57:39] fperez at tuzsa dot es A new note: if I configure php without --enable-debug and execute the java.php url page within Zend Studio (Zend Development environment) then execution script and results goes ok again. Thanks. [2003-09-29 03:31:01] fperez at tuzsa dot es Description: Hello, Apache 1.3.28, php-4.3.3, RedHat 7.3, java 1.4.2_01. I have configured ld.so.conf with the java_paths and I have configured, also, export LD_LIBRARY_PATH java_paths on /usr/local/apache/bin/apachectl I have a segmentation fault which is difficult to report you because: 1.- If I compile php without --enable-debug I always obtain a segmentation fault running java.php (java.php=example 1 in http://www.php.net/manual/en/ref.java.php). 2.- If I compile php WITH --enable-debug then the same script (java.php) runs fine without any problem. Because of that I cannot send you a backtrace or something else with --enable-debug. :-( What I should to do ? How can I sent you more information ? Thanks PS: Of course, I have the same problem with other php/java scripts and, again, if I compile php with --enable-debug, all crashes goes out. Reproduce code: --- EXAMPLE 1. in: http://www.php.net/manual/en/ref.java.php Actual result: -- Sometimes I obtain a whole empty page and this apache error_log (note the strange characters on the first line after NoSuchMethodException): [Mon Sep 29 09:19:37 2003] [error] PHP Warning: java.lang.NoSuchMethodException: Þ7 in /www/tuzsa/java.php on line 16 [Mon Sep 29 09:19:37 2003] [notice] child pid 1661 exit signal Segmentation fault (11) Sometimes I obtain this results (note the date/time formated result aren't) === Java version=1.4.2_01 Java vendor=Sun Microsystems Inc. OS=Linux 2.4.18-3smp on i386 === And I have this, again, in the apache error log: [Mon Sep 29 09:23:01 2003] [error] PHP Warning: java.lang.NoSuchMethodException: ÔH? in /www/tuzsa/java.php on line 16 [Mon Sep 29 09:23:03 2003] [notice] child pid 1662 exit signal Segmentation fault (11) -- Edit this bug report at http://bugs.php.net/?id=25684&edit=1
#25687 [NEW]: "Segmentation fault" - trying to inherit >2 classes and to call parent constr.
From: kostyal at realeastnetworks dot com
Operating system: Debian GNU/Linux 2.4.21-5-k7
PHP version: 4.3.3
PHP Bug Type: Class/Object related
Bug description: "Segmentation fault" - trying to inherit >2 classes and to call
parent constr.
Description:
Description:
Segmentation fault occurs when trying to inherit more then two classes and
to call parent constructors (see example to understand how I'm trying to
do it).
When I comment last "call_constr()" call, the problem disappears.
Configure Command:
'../configure' '--prefix=/usr' '--with-apxs=/usr/bin/apxs'
'--with-regex=php' '--with-config-file-path=/etc/php4/apache'
'--disable-rpath' '--disable-debug' '--enable-memory-limit'
'--with-layout=GNU' '--with-pear=/usr/share/php' '--enable-calendar'
'--enable-sysvsem' '--enable-sysvshm' '--enable-track-vars'
'--enable-trans-sid' '--enable-bcmath' '--with-bz2' '--enable-ctype'
'--with-db4' '--with-iconv' '--enable-exif' '--enable-filepro'
'--enable-ftp' '--with-gettext' '--enable-mbstring'
'--with-pcre-regex=/usr' '--enable-shmop' '--enable-sockets'
'--enable-wddx' '--disable-xml' '--with-expat-dir=/usr' '--enable-yp'
'--with-zlib' '--without-pgsql' '--with-kerberos=/usr'
'--with-openssl=/usr' '--with-exec-dir=/usr/lib/php4/libexec'
'--disable-static' '--with-curl=shared,/usr' '--with-dom=shared,/usr'
'--with-dom-xslt=shared,/usr' '--with-dom-exslt=shared,/usr'
'--with-zlib-dir=/usr' '--with-gd=shared,/usr'
'--with-jpeg-dir=shared,/usr' '--with-xpm-dir=shared,/usr/X11R6'
'--with-png-dir=shared,/usr' '--with-freetype-dir=shared,/usr'
'--with-imap=shared,/usr' '--with-imap-ssl' '--with-ldap=shared,/usr'
'--with-mcal=shared,/usr' '--with-mhash=shared,/usr' '--with-mm'
'--with-mysql=shared,/usr' '--with-unixODBC=shared,/usr'
'--with-recode=shared,/usr' '--enable-xslt=shared'
'--with-xslt-sablot=shared,/usr' '--with-snmp=shared'
'--enable-ucd-snmp-hack' '--with-sybase-ct=shared,/usr'
'--with-ttf=shared,/usr' '--with-t1lib=shared,/usr'
Reproduce code:
---
class object {
function call_constr() {
$par=get_parent_class($this);
$this->$par();
}
}
class Graph extends object {
function Graph() {
}
}
class TwinGraph extends Graph {
function TwinGraph() {
$this->call_constr(); // calling parent constructor
}
}
class TwinBarChart extends TwinGraph {
function TwinBarChart() {
$this->call_constr(); // calling parent constructor
echo "Test";
}
}
$graph=new TwinBarChart();
Expected result:
Test
Actual result:
--
Segmentation fault
--
Edit bug report at http://bugs.php.net/?id=25687&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25687&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25687&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=25687&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=25687&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=25687&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=25687&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=25687&r=support
Expected behavior: http://bugs.php.net/fix.php?id=25687&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=25687&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=25687&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=25687&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25687&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=25687&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=25687&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=25687&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=25687&r=float
#25684 [Opn]: segmentation fault in java.php
ID: 25684 User updated by: fperez at tuzsa dot es Reported By: fperez at tuzsa dot es Status: Open Bug Type: Reproducible crash Operating System: RedHat Linux 7.3 PHP Version: 4.3.3 New Comment: A new note: if I configure php without --enable-debug and execute the java.php url page within Zend Studio (Zend Development environment) then execution script and results goes ok again. Thanks. Previous Comments: [2003-09-29 03:31:01] fperez at tuzsa dot es Description: Hello, Apache 1.3.28, php-4.3.3, RedHat 7.3, java 1.4.2_01. I have configured ld.so.conf with the java_paths and I have configured, also, export LD_LIBRARY_PATH java_paths on /usr/local/apache/bin/apachectl I have a segmentation fault which is difficult to report you because: 1.- If I compile php without --enable-debug I always obtain a segmentation fault running java.php (java.php=example 1 in http://www.php.net/manual/en/ref.java.php). 2.- If I compile php WITH --enable-debug then the same script (java.php) runs fine without any problem. Because of that I cannot send you a backtrace or something else with --enable-debug. :-( What I should to do ? How can I sent you more information ? Thanks PS: Of course, I have the same problem with other php/java scripts and, again, if I compile php with --enable-debug, all crashes goes out. Reproduce code: --- EXAMPLE 1. in: http://www.php.net/manual/en/ref.java.php Actual result: -- Sometimes I obtain a whole empty page and this apache error_log (note the strange characters on the first line after NoSuchMethodException): [Mon Sep 29 09:19:37 2003] [error] PHP Warning: java.lang.NoSuchMethodException: Þ7 in /www/tuzsa/java.php on line 16 [Mon Sep 29 09:19:37 2003] [notice] child pid 1661 exit signal Segmentation fault (11) Sometimes I obtain this results (note the date/time formated result aren't) === Java version=1.4.2_01 Java vendor=Sun Microsystems Inc. OS=Linux 2.4.18-3smp on i386 === And I have this, again, in the apache error log: [Mon Sep 29 09:23:01 2003] [error] PHP Warning: java.lang.NoSuchMethodException: ÔH? in /www/tuzsa/java.php on line 16 [Mon Sep 29 09:23:03 2003] [notice] child pid 1662 exit signal Segmentation fault (11) -- Edit this bug report at http://bugs.php.net/?id=25684&edit=1
#25686 [NEW]: XML processing instruction handling feature request
From: bart at mediawave dot nl Operating system: All PHP version: Irrelevant PHP Bug Type: Feature/Change Request Bug description: XML processing instruction handling feature request Description: With the XML parser module PHP currently handles processing instruction code per tag. For example: is seen as an isolated chunk of code. This doesn't work: PHP handles the PHP code per tag. While in this example the code actually spans through 5 tags. But PHP doesn't recognize it this way. Also. For my application it would be desirable if the PHP XML parser would not return the php code. The evaluation of the PHP code in the XML should be hanled by the parser. It should then only return the resulting (evaluated) XML as if it was normal XML. Reproduce code: --- Expected result: 0 1 2 3 Actual result: -- Parse error: parse error, unexpected $end in D:\php-4.3.2\PEAR\wrap_v4\dam.php(544) : eval()'d code on line 1 Parse error: parse error, unexpected T_ENDFOR in D:\php-4.3.2\PEAR\wrap_v4\dam.php(544) : eval()'d code on line 1 -- Edit bug report at http://bugs.php.net/?id=25686&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25686&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25686&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=25686&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=25686&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=25686&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=25686&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=25686&r=support Expected behavior: http://bugs.php.net/fix.php?id=25686&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=25686&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=25686&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=25686&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25686&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=25686&r=dst IIS Stability: http://bugs.php.net/fix.php?id=25686&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=25686&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=25686&r=float
#25685 [NEW]: Access Violation
From: peter dot siebert at gsw-mainz dot de Operating system: Windows 2k Pro PHP version: 4.3.1 PHP Bug Type: *Mail Related Bug description: Access Violation Description: I use an ArgoSoft Mailserver and IIS locally. When I send an e-Mail with the mail-function I get the following error: PHP has encountered an Access Violation at 01897BD4. In php.ini the value smtp is set to localhost and send_from is set to [EMAIL PROTECTED] Peter -- Edit bug report at http://bugs.php.net/?id=25685&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25685&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25685&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=25685&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=25685&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=25685&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=25685&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=25685&r=support Expected behavior: http://bugs.php.net/fix.php?id=25685&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=25685&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=25685&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=25685&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25685&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=25685&r=dst IIS Stability: http://bugs.php.net/fix.php?id=25685&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=25685&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=25685&r=float
#25684 [NEW]: segmentation fault in java.php
From: fperez at tuzsa dot es Operating system: RedHat Linux 7.3 PHP version: 4.3.3 PHP Bug Type: Reproducible crash Bug description: segmentation fault in java.php Description: Hello, Apache 1.3.28, php-4.3.3, RedHat 7.3, java 1.4.2_01. I have configured ld.so.conf with the java_paths and I have configured, also, export LD_LIBRARY_PATH java_paths on /usr/local/apache/bin/apachectl I have a segmentation fault which is difficult to report you because: 1.- If I compile php without --enable-debug I always obtain a segmentation fault running java.php (java.php=example 1 in http://www.php.net/manual/en/ref.java.php). 2.- If I compile php WITH --enable-debug then the same script (java.php) runs fine without any problem. Because of that I cannot send you a backtrace or something else with --enable-debug. :-( What I should to do ? How can I sent you more information ? Thanks PS: Of course, I have the same problem with other php/java scripts and, again, if I compile php with --enable-debug, all crashes goes out. Reproduce code: --- EXAMPLE 1. in: http://www.php.net/manual/en/ref.java.php Actual result: -- Sometimes I obtain a whole empty page and this apache error_log (note the strange characters on the first line after NoSuchMethodException): [Mon Sep 29 09:19:37 2003] [error] PHP Warning: java.lang.NoSuchMethodException: Þ7 in /www/tuzsa/java.php on line 16 [Mon Sep 29 09:19:37 2003] [notice] child pid 1661 exit signal Segmentation fault (11) Sometimes I obtain this results (note the date/time formated result aren't) === Java version=1.4.2_01 Java vendor=Sun Microsystems Inc. OS=Linux 2.4.18-3smp on i386 === And I have this, again, in the apache error log: [Mon Sep 29 09:23:01 2003] [error] PHP Warning: java.lang.NoSuchMethodException: ÔH? in /www/tuzsa/java.php on line 16 [Mon Sep 29 09:23:03 2003] [notice] child pid 1662 exit signal Segmentation fault (11) -- Edit bug report at http://bugs.php.net/?id=25684&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25684&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25684&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=25684&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=25684&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=25684&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=25684&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=25684&r=support Expected behavior: http://bugs.php.net/fix.php?id=25684&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=25684&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=25684&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=25684&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25684&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=25684&r=dst IIS Stability: http://bugs.php.net/fix.php?id=25684&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=25684&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=25684&r=float
#25683 [NEW]: Send mail from any address
From: reveille187 at hotmail dot com Operating system: win32 xp sp1 PHP version: 4.3.2 PHP Bug Type: *Mail Related Bug description: Send mail from any address Description: I'm not sure if anyone else noticed this... I run php 4.3.2 on my windows xp pc with apache 1.3. I don't have a domain name, and while exploring options on how to send mail from my pc, I found out you could send email from any address to anyone else without knowing thier password. Eg/ I could send hate mail from [EMAIL PROTECTED] where my real address is [EMAIL PROTECTED] Reproduce code: --- Expected result: An email in my inbox from you. Actual result: -- Same as above. -- Edit bug report at http://bugs.php.net/?id=25683&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25683&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25683&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=25683&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=25683&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=25683&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=25683&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=25683&r=support Expected behavior: http://bugs.php.net/fix.php?id=25683&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=25683&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=25683&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=25683&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25683&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=25683&r=dst IIS Stability: http://bugs.php.net/fix.php?id=25683&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=25683&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=25683&r=float
