#20711 [NEW]: ressource id are incorrect
From: [EMAIL PROTECTED] Operating system: Windows 2000 and linux PHP version: 4.3.0RC2 PHP Bug Type: Unknown/Other Function Bug description: ressource id are incorrect First, I notice that the ressource id given by some function is always greater or egal to 2 with php-4.3.0RC1 and 4.3.0RC2. script: ?php $ds = ldap_connect ( $ldaphost ); echo $ds; ? output: ressource id #2 Second, the ressource id is always increased even if the function failed. ie script: ?php $fp = fopen ( 'not_existing_file', 'r'); echo '-'.$fp.'-br'; $ds = ldap_connect ( $ldaphost ); echo '-'.$ds.'-'; ? output: -- -ressource id#3- Thanks -- Edit bug report at http://bugs.php.net/?id=20711edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20711r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20711r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20711r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20711r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20711r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20711r=support Expected behavior: http://bugs.php.net/fix.php?id=20711r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20711r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20711r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20711r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20711r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20711r=dst IIS Stability: http://bugs.php.net/fix.php?id=20711r=isapi
#20712 [NEW]: the hostname lookup is incorrrect
From: [EMAIL PROTECTED] Operating system: linux PHP version: 4.3.0RC2 PHP Bug Type: Performance problem Bug description: the hostname lookup is incorrrect Hello, I found performance problem in the hostnmae lookup in php-4.3.0RC2 on linux. Windows platform works fine. ?php $localhost = 'localhost'; $ds = ldap_connect ( $localhost ); ldap_bind ( $ds ); ? When i run this script, php make a dns lookup to find the name localhost and if not found make a local search (/etc/hosts). Normaly, it should search first in the /etc/hosts file and next make dns lookup. the /etc/hosts and /etc/nsswitch.conf is good. Thanks -- Edit bug report at http://bugs.php.net/?id=20712edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20712r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20712r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20712r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20712r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20712r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20712r=support Expected behavior: http://bugs.php.net/fix.php?id=20712r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20712r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20712r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20712r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20712r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20712r=dst IIS Stability: http://bugs.php.net/fix.php?id=20712r=isapi
#20713 [NEW]: ldap_connect doesn't return FALSE
From: [EMAIL PROTECTED] Operating system: windows and linux PHP version: 4.3.0RC2 PHP Bug Type: LDAP related Bug description: ldap_connect doesn't return FALSE Hello, when i call the ldap_connect without any param, i don't get FALSE. ?php $ds = ldap_connect ( ); echo $ds; // -- i get ressource id #2 ? But the connection is not possible. Thanks -- Edit bug report at http://bugs.php.net/?id=20713edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20713r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20713r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20713r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20713r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20713r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20713r=support Expected behavior: http://bugs.php.net/fix.php?id=20713r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20713r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20713r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20713r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20713r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20713r=dst IIS Stability: http://bugs.php.net/fix.php?id=20713r=isapi
#20711 [Bgs]: ressource id are incorrect
ID: 20711 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Unknown/Other Function Operating System: Windows 2000 and linux PHP Version: 4.3.0RC2 New Comment: Sorry, but it's bugs. I know that i should send only 1 bug per submission but the solution for both bug concern the same part of code (in my opinion) and the first bug (resource id =2) is a very little bug to solve. So, i think you should take a little more time to answers bug report and/or give a better reason for a reject. Thanks Previous Comments: [2002-11-29 02:46:26] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php [2002-11-29 02:38:14] [EMAIL PROTECTED] First, I notice that the ressource id given by some function is always greater or egal to 2 with php-4.3.0RC1 and 4.3.0RC2. script: ?php $ds = ldap_connect ( $ldaphost ); echo $ds; ? output: ressource id #2 Second, the ressource id is always increased even if the function failed. ie script: ?php $fp = fopen ( 'not_existing_file', 'r'); echo '-'.$fp.'-br'; $ds = ldap_connect ( $ldaphost ); echo '-'.$ds.'-'; ? output: -- -ressource id#3- Thanks -- Edit this bug report at http://bugs.php.net/?id=20711edit=1
#20713 [Bgs]: ldap_connect doesn't return FALSE
ID: 20713 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: LDAP related Operating System: windows and linux PHP Version: 4.3.0RC2 New Comment: Thanks for your answer. I prefer the last answer (which is more clear) than the first. I add a comment to the bug 15637 Previous Comments: [2002-11-29 08:32:12] [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. http://bugs.php.net/bug.php?id=15637 [2002-11-29 07:04:49] [EMAIL PROTECTED] Soorry, but i don't ask support for PHP. I think your answer don't help user to love people, because you don't take care about bug submitted. I spent time to test PHP when i see strange bahaviour of PHP so for my problem, the documention is (on zend site) for ldap_connect: ldap_connect() establishes a connection to a LDAP server on a specified hostname and port. Both the arguments are optional. -- If no arguments are specified then the link identifier of the already opened link will be returned. In my script i don't have any previous opened link, so i think the function would return FALSE. Or the documention is wrong and need correction. Sincerely [2002-11-29 06:25:06] [EMAIL PROTECTED] 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. [2002-11-29 02:45:12] [EMAIL PROTECTED] Hello, when i call the ldap_connect without any param, i don't get FALSE. ?php $ds = ldap_connect ( ); echo $ds; // -- i get ressource id #2 ? But the connection is not possible. Thanks -- Edit this bug report at http://bugs.php.net/?id=20713edit=1
#19516 [Fbk-Opn]: output buffer timing is strange
ID: 19516 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Output Control Operating System: Windows 2000 server -PHP Version: 4.3.0pre1 +PHP Version: 4.3.0pre2 New Comment: I have always the same result with the php4-latest ( 28 oct at 15:00 ) Previous Comments: [2002-10-28 10:52:14] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip pre2 is now out with several changes/fixes in output buffering code. Could you please verify if the problem is still there? [2002-10-28 02:58:25] [EMAIL PROTECTED] I rerun the test with the 4.30pre1 version. I always have the same result on command line and with apache 1.3.27, but not with apache 2.0.43. the problem is really visible with the output buffer to 16384 and $max = 1000 in the script. I see that te first loop can take in buffer, so the timing for this loop is god, but the second loop can not tkae in buffer, so the timing is really bad. [2002-10-24 15:34:04] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-10-14 08:10:52] [EMAIL PROTECTED] I rerun test with and without zlib_output_compression. there is no difference. i don't use ob_gzhandler. with $max=1000 and output_buffer= 16384, the second loop is slower than the first. If i increase output_buffer to 32656 , the second loop take less time than the first ( it's the good result). The size odf output is 28ko. I will run test with the php 4.3.0pre1 as soon as possible. [2002-10-01 05:21:07] [EMAIL PROTECTED] It sounds like you are enabling zlib.output_compression. (If you are not using ob_gzhandler) If yes, this is not a bug. 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/19516 -- Edit this bug report at http://bugs.php.net/?id=19516edit=1
#19516 [Bgs]: output buffer timing is strange
ID: 19516 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Output Control Operating System: Windows 2000 server PHP Version: 4.3.0pre2 New Comment: If you don't want to fix bug on windows platforms, don't make a windows version of PHP. Thanks Previous Comments: [2002-10-29 05:11:52] [EMAIL PROTECTED] Some windows oddity. Works on Linux - not bug. [2002-10-29 04:37:07] [EMAIL PROTECTED] I have always the same result with the php4-latest ( 28 oct at 15:00 ) [2002-10-28 10:52:14] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip pre2 is now out with several changes/fixes in output buffering code. Could you please verify if the problem is still there? [2002-10-28 02:58:25] [EMAIL PROTECTED] I rerun the test with the 4.30pre1 version. I always have the same result on command line and with apache 1.3.27, but not with apache 2.0.43. the problem is really visible with the output buffer to 16384 and $max = 1000 in the script. I see that te first loop can take in buffer, so the timing for this loop is god, but the second loop can not tkae in buffer, so the timing is really bad. [2002-10-24 15:34:04] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-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/19516 -- Edit this bug report at http://bugs.php.net/?id=19516edit=1
#19516 [Fbk-Opn]: output buffer timing is strange
ID: 19516 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Output Control Operating System: Windows 2000 server -PHP Version: 4.2.3 +PHP Version: 4.3.0pre1 New Comment: I rerun the test with the 4.30pre1 version. I always have the same result on command line and with apache 1.3.27, but not with apache 2.0.43. the problem is really visible with the output buffer to 16384 and $max = 1000 in the script. I see that te first loop can take in buffer, so the timing for this loop is god, but the second loop can not tkae in buffer, so the timing is really bad. Previous Comments: [2002-10-24 15:34:04] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-10-14 08:10:52] [EMAIL PROTECTED] I rerun test with and without zlib_output_compression. there is no difference. i don't use ob_gzhandler. with $max=1000 and output_buffer= 16384, the second loop is slower than the first. If i increase output_buffer to 32656 , the second loop take less time than the first ( it's the good result). The size odf output is 28ko. I will run test with the php 4.3.0pre1 as soon as possible. [2002-10-01 05:21:07] [EMAIL PROTECTED] It sounds like you are enabling zlib.output_compression. (If you are not using ob_gzhandler) If yes, this is not a bug. [2002-10-01 02:44:00] [EMAIL PROTECTED] There is no difference with or without \n and in command line. gzip is disabled for all test. I think the problem is the rotation of the buffer. timing is good if the buffer size is greater or equal to the output size. all works fine on linux [2002-09-26 18:28:55] [EMAIL PROTECTED] If you add \n to $suite variable does this change the timings in any signifcant way? Also, check to make sure you do not gzip compression enabled as well as try doing this test via a command line rather then a browser. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/19516 -- Edit this bug report at http://bugs.php.net/?id=19516edit=1
#16217 [Opn]: syslog functions and exit functions are buggy
ID: 16217 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open -Bug Type: Documentation problem +Bug Type: Reproducible crash Operating System: windows NT 4/ win2000 pro/server -PHP Version: 4.2.1 +PHP Version: 4.3.0pre1 New Comment: i rerun test with php 4.30pre1 and i see this version is more stable. apache doesn't crash, but i get popup message like this : instruction at 0x100d4ebd . memory could not written. but the hexa value seems to change if i run apache in command line or like service, or sith a different version (like 2.0.43). Previous Comments: [2002-09-20 03:39:13] [EMAIL PROTECTED] i get the same crash with php 4.2.3. without exit call at end of script. Ok for the documentation error [2002-08-30 14:47:39] [EMAIL PROTECTED] Actually that's LOG_LOCAL0 through LOG_LOCAL7 that are not avaliable. I made a typo in my previous comment. [2002-08-30 14:35:06] [EMAIL PROTECTED] I cannot replicate the crash. However, there is a definate problem with the docs for openlog() functions. On win32 LOCAL_LOG0 through LOCAL_LOG7 are not avaliable. In fact the openlog line in the example returns a warning about the 3rd parameter being invalid. The openlog facilities should be better documented, mentioning which are *nix specific, win32 specific and which are common. [2002-06-10 04:33:37] [EMAIL PROTECTED] platform : apache 1.3.24 / php 4.2.1 / w2k SP2 I test on php 4.2.1 and there are some difference. The exit function seem to not cause bug, but the closelog crash apache (drwatson is started...). This appear when i reload one or two times the script. all works fine when i comment closelog. No problem on linux [2002-03-22 04:29:02] [EMAIL PROTECTED] Crash appear with the php module, not with cgi version. with module and without extensions, apache always crash... So this bugs is related to apache module. I don't test with php 4.1.2 and on linux, it seems to be 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/16217 -- Edit this bug report at http://bugs.php.net/?id=16217edit=1
#19516 [Fbk-Opn]: output buffer timing is strange
ID: 19516
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: Output Control
Operating System: Windows 2000 server
PHP Version: 4.2.3
New Comment:
I rerun test with and without zlib_output_compression. there is no
difference.
i don't use ob_gzhandler.
with $max=1000 and output_buffer= 16384, the second loop is slower than
the first. If i increase output_buffer to 32656 , the second loop take
less time than the first ( it's the good result). The size odf output
is 28ko.
I will run test with the php 4.3.0pre1 as soon as possible.
Previous Comments:
[2002-10-01 05:21:07] [EMAIL PROTECTED]
It sounds like you are enabling zlib.output_compression. (If you are
not using ob_gzhandler)
If yes, this is not a bug.
[2002-10-01 02:44:00] [EMAIL PROTECTED]
There is no difference with or without \n and in command line.
gzip is disabled for all test.
I think the problem is the rotation of the buffer. timing is good if
the buffer size is greater or equal to the output size.
all works fine on linux
[2002-09-26 18:28:55] [EMAIL PROTECTED]
If you add \n to $suite variable does this change the timings in any
signifcant way? Also, check to make sure you do not gzip compression
enabled as well as try doing this test via a command line rather then a
browser.
[2002-09-20 03:20:11] [EMAIL PROTECTED]
on Windows 2000 SP2 FR, and php 4.2.3, the outbut buffer seems to not
work correctly.
i make test to see the time taken to output data, and this time is not
linear.
explain, with output buffer = on in php.ini, all works fine. but with
output_buffer=off ou output_buffer = 4096 or 8192 or more, the time for
output data is very strange.
the script:
?
include exectimer.class.php;
$tip = new VWT_execTimeProfiler();
$suite = vs print;
$max = 1;
$tip-start();
$tip-watch(echo double);
for( $i=0;$i$max;$i++) {
print echo $suite;
}
echo hr;
$tip-watch(echo en simple);
for( $j=0;$j$max;$j++) {
print 'echo '.$suite;
}
$tip-stop();
$tip-show();
?
the first for loop can take 100 ms to 800 ms when i change the size of
output buffer.
if i increase the loop count, then the time for the second loop
inrease, but the firt loop decrease.
When output_buffer is on, all works fine.
I don't see this bug on Linux.
PS: sorry for my bad english...
--
Edit this bug report at http://bugs.php.net/?id=19516edit=1
#19516 [Fbk-Opn]: output buffer timing is strange
ID: 19516
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: Output Control
Operating System: Windows 2000 server
PHP Version: 4.2.3
New Comment:
There is no difference with or without \n and in command line.
gzip is disabled for all test.
I think the problem is the rotation of the buffer. timing is good if
the buffer size is greater or equal to the output size.
all works fine on linux
Previous Comments:
[2002-09-26 18:28:55] [EMAIL PROTECTED]
If you add \n to $suite variable does this change the timings in any
signifcant way? Also, check to make sure you do not gzip compression
enabled as well as try doing this test via a command line rather then a
browser.
[2002-09-20 03:20:11] [EMAIL PROTECTED]
on Windows 2000 SP2 FR, and php 4.2.3, the outbut buffer seems to not
work correctly.
i make test to see the time taken to output data, and this time is not
linear.
explain, with output buffer = on in php.ini, all works fine. but with
output_buffer=off ou output_buffer = 4096 or 8192 or more, the time for
output data is very strange.
the script:
?
include exectimer.class.php;
$tip = new VWT_execTimeProfiler();
$suite = vs print;
$max = 1;
$tip-start();
$tip-watch(echo double);
for( $i=0;$i$max;$i++) {
print echo $suite;
}
echo hr;
$tip-watch(echo en simple);
for( $j=0;$j$max;$j++) {
print 'echo '.$suite;
}
$tip-stop();
$tip-show();
?
the first for loop can take 100 ms to 800 ms when i change the size of
output buffer.
if i increase the loop count, then the time for the second loop
inrease, but the firt loop decrease.
When output_buffer is on, all works fine.
I don't see this bug on Linux.
PS: sorry for my bad english...
--
Edit this bug report at http://bugs.php.net/?id=19516edit=1
#19516 [NEW]: output buffer timing is strange
From: [EMAIL PROTECTED]
Operating system: Windows 2000 server
PHP version: 4.2.3
PHP Bug Type: Output Control
Bug description: output buffer timing is strange
on Windows 2000 SP2 FR, and php 4.2.3, the outbut buffer seems to not work
correctly.
i make test to see the time taken to output data, and this time is not
linear.
explain, with output buffer = on in php.ini, all works fine. but with
output_buffer=off ou output_buffer = 4096 or 8192 or more, the time for
output data is very strange.
the script:
?
include exectimer.class.php;
$tip = new VWT_execTimeProfiler();
$suite = vs print;
$max = 1;
$tip-start();
$tip-watch(echo double);
for( $i=0;$i$max;$i++) {
print echo $suite;
}
echo hr;
$tip-watch(echo en simple);
for( $j=0;$j$max;$j++) {
print 'echo '.$suite;
}
$tip-stop();
$tip-show();
?
the first for loop can take 100 ms to 800 ms when i change the size of
output buffer.
if i increase the loop count, then the time for the second loop inrease,
but the firt loop decrease.
When output_buffer is on, all works fine.
I don't see this bug on Linux.
PS: sorry for my bad english...
--
Edit bug report at http://bugs.php.net/?id=19516edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=19516r=trysnapshot
Fixed in CVS:http://bugs.php.net/fix.php?id=19516r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=19516r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=19516r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=19516r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=19516r=support
Expected behavior: http://bugs.php.net/fix.php?id=19516r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=19516r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=19516r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=19516r=globals
#16217 [Opn]: syslog functions and exit functions are buggy
ID: 16217 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Documentation problem Operating System: windows NT 4/ win2000 pro/server PHP Version: 4.2.1 New Comment: i get the same crash with php 4.2.3. without exit call at end of script. Ok for the documentation error Previous Comments: [2002-08-30 14:47:39] [EMAIL PROTECTED] Actually that's LOG_LOCAL0 through LOG_LOCAL7 that are not avaliable. I made a typo in my previous comment. [2002-08-30 14:35:06] [EMAIL PROTECTED] I cannot replicate the crash. However, there is a definate problem with the docs for openlog() functions. On win32 LOCAL_LOG0 through LOCAL_LOG7 are not avaliable. In fact the openlog line in the example returns a warning about the 3rd parameter being invalid. The openlog facilities should be better documented, mentioning which are *nix specific, win32 specific and which are common. [2002-06-10 04:33:37] [EMAIL PROTECTED] platform : apache 1.3.24 / php 4.2.1 / w2k SP2 I test on php 4.2.1 and there are some difference. The exit function seem to not cause bug, but the closelog crash apache (drwatson is started...). This appear when i reload one or two times the script. all works fine when i comment closelog. No problem on linux [2002-03-22 04:29:02] [EMAIL PROTECTED] Crash appear with the php module, not with cgi version. with module and without extensions, apache always crash... So this bugs is related to apache module. I don't test with php 4.1.2 and on linux, it seems to be ok. [2002-03-22 04:01:06] [EMAIL PROTECTED] Does this also happen if you only use the CGI version on command line and as less modules (i.e. no ldp/oci8/whatever) as possible? 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/16217 -- Edit this bug report at http://bugs.php.net/?id=16217edit=1
Bug #17406: the output of cgi version is buggy
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.2.1 PHP Bug Type: Unknown/Other Function Bug description: the output of cgi version is buggy the tag br is buggy in the cgi version of php 4.2.1 on Linux Redhat i get the following output with a script: X-Powered-by: PHP/4.2.1 Content-Type: text/html 4.2.1br / bFatal Error/b: Call to undefined function: toto() in b/tmp/script.php/b on line b3/bbr / i do not test with apache and on windows platform. version 4.1.1 doesn't return this error Thanks -- Edit bug report at http://bugs.php.net/?id=17406edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=17406r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=17406r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17406r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17406r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17406r=support Expected behavior: http://bugs.php.net/fix.php?id=17406r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17406r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17406r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=17406r=globals
Bug #16217: syslog functions and exit functions are buggy
From: [EMAIL PROTECTED] Operating system: windows NT 4/ win2000 pro PHP version: 4.1.1 PHP Bug Type: Reproducible crash Bug description: syslog functions and exit functions are buggy Hello, Apache crash on windows platform when i use syslog functions ( openlog, syslog, closelog) and exit(). the script is: 1: ?php 2: define_syslog_variables(); 3: openlog(Test, LOG_PID | LOG_PERROR, LOG_LOCAL0); 4: syslog(LOG_WARNING,Essai de log); 5: closelog(); 6: exit(); 7: ? if i comment line 5 and 6, it's works fine. if i comment line 3, 4, 5 , apache crash after few reload or navigation between index page and this script. if i comment line 6, apache crash in the same case as above... config: w2k pro sp2 apache 1.3.22 ( start in commmand line or as service ) php 4.1.1 + ldap + oci8 (8.1.7) win nt 4 sp 6 apache 1.3.22 php 4.1.0 + ldap + oci8 (8.1.6) thanks for your comment. -- Edit bug report at http://bugs.php.net/?id=16217edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16217r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16217r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16217r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16217r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16217r=support Expected behavior: http://bugs.php.net/fix.php?id=16217r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16217r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16217r=submittedtwice
