#21576 [NEW]: PHP crashes on mail() using IIS's mail
From: [EMAIL PROTECTED]
Operating system: Windows 2000
PHP version: 4.3.0
PHP Bug Type: Mail related
Bug description: PHP crashes on mail() using IIS's mail
When I use the mail() function, PHP crashes with the following error:
"PHP has encountered an Access Violation at 01AD7BD4"
For my mail server, I'm using the IIS mail server ("default SMTP virtual
server") on localhost.
I'm using IIS 5 (Dont know where to get an exact ver number) for both php
and email and windows 2000 (version 5.00.2195 [service pack 2])
The mail does get sent successfully even with the error.
the same code works fine on my redhat server using sendmail (same php
version)
--
Edit bug report at http://bugs.php.net/?id=21576&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21576&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=21576&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=21576&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21576&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=21576&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21576&r=support
Expected behavior: http://bugs.php.net/fix.php?id=21576&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=21576&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=21576&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=21576&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21576&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=21576&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=21576&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=21576&r=gnused
#21262 [Opn]: crash or fail when outputting large amounts of text quickly
ID: 21262
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Reproducible crash
Operating System: WinXP
PHP Version: 4.3.0
New Comment:
Ridiculous.. how on earth can they look at this:
PHP Fatal error: Allowed memory size of 8388608
bytes exhausted (tried to allocate 10240 bytes)
And say its a bug in IE?
I agree with the first assesment - this is a likely a CRITICAL bug. I
have seen pages fail for no reason on linux too, who knows if this
problem could be responsible. This needs to be looked at by someone at
the top.
Previous Comments:
[2003-01-10 20:58:22] [EMAIL PROTECTED]
I had the exact same problem. I submitted a bug report. Bug smashers
seemed to go off on some random tangent. Then decided all of a sudden
that it was an IE problem (even though in my original report I clearly
stated that there was a problem with Mozilla/Netscape output as well).
My original bug report here:
http://bugs.php.net/bug.php?id=14474
[2002-12-30 15:45:50] [EMAIL PROTECTED]
Well that's strange, can anyone else repro this? You may need to
refresh a few times for it to happen. I have been using PHP from the
command line for the last year because of this issue.
[2002-12-30 10:05:43] [EMAIL PROTECTED]
This does not seem to be a problem. I can not reproduce this crash with
the following code.
for($Loop=0 ; $Loop<1 ; $Loop++)
{
echo "blah $Loop ";
}
I am also using the SAPI version of PHP in Apache under Windows XP.
[2002-12-29 15:26:55] [EMAIL PROTECTED]
Then maybe this should be a doc change: "If you don't call flush() once
in a while, PHP will hang. This is not a bug. Hanging is
intentional."
This is a BUG. If it causes PHP to HANG before outputting the page,
then it is a BUG! FLUSH IS NOT SUPPOSED TO BE MANDATORY.
This also happens when outputting pages under 20K, but this example is
the best way to repro. And as I stated, implicit flushing does not fix
the problem either. Any delay in the loop fixes it.
Every time I submit something here, somebody spends 15 seconds on it
and marks it as bogus. When it is NOT. I WENT TO THE TIME OF
SUBMITTING THIS FOR A REASON, AND I AM NOT A JACKASS. I HAVE BEEN
PROGRAMMING FOR 15 YEARS. If you treat every bug report on here like
an idiot wrote it, only idiots are going to stick around to report
"bugs" for you. Spend a little more than 15 seconds on it.
I gave exact details and the simplest repro on earth, not to mention
the results of possible contributing factors. What else could you
possibly want. Why is it so hard to get problems even acknowledged
here? Maybe I should just mark them as bogus in the beginning to save
a little time. This is as bad as reporting bugs to Microsoft.
[2002-12-29 14:08:46] [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
I think this is not a bug, but simply an issue of running out of
memory, because the data in the buffer simply gets too big. flush()
dumps the data inside the buffer to screen and clears the buffer, which
is why it wouldn't crash when flush() is used.
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/21262
--
Edit this bug report at http://bugs.php.net/?id=21262&edit=1
#14542 [Ver]: register_shutdown_function() timeout problem
ID: 14542 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Verified Bug Type: Scripting Engine problem Operating System: Linux 2.4.5 -PHP Version: 4.3.0-dev +PHP Version: 4.3.0 New Comment: Verified with latest CVS and 4.3.0. Previous Comments: [2002-12-08 10:38:04] [EMAIL PROTECTED] Verified with 4.3.0-dev at this date. [2002-06-16 00:11:57] [EMAIL PROTECTED] reclassified. [2002-04-27 19:09:27] [EMAIL PROTECTED] It's not fixed.. [2002-04-27 10:08:11] [EMAIL PROTECTED] Fixed in CVS [2002-04-25 16:07:25] [EMAIL PROTECTED] The cause of the bug is that the following code is commented out in the timeout handler (zend_timeout() in zend_execute_API): /* is there any point in this? we're terminating the request anyway... PG(connection_status) |= PHP_CONNECTION_TIMEOUT; */ In our case, we need this error status to be set correctly. We want to be able to detect the error when a script is terminated due to timeout. 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/14542 -- Edit this bug report at http://bugs.php.net/?id=14542&edit=1
#21574 [Ver]: $_POST doesn't contain good value
ID: 21574 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Verified Bug Type: Variables related Operating System: RedHat 8 PHP Version: 4CVS-2003-01-10 (stable) New Comment: Verified with Apache2 only. (Latest too). Previous Comments: [2003-01-10 22:00:48] [EMAIL PROTECTED] It looks the same as #21566. And it looks very critical to me? [2003-01-10 20:23:54] [EMAIL PROTECTED] My configuration is : - RedHat8 - Apache 2.0.43 - PHP 4.3.1-dev (same problem with PHP 4.4.0-dev, PHP 5.0.0-dev ; PHP 4.3.0 have another annoying problem) I have IP stored in a db in longint format (with ip2long(...)). I use the following script to obtain the hostname of an IP. "; print ""; print ""; print ""; $ip = long2ip($entier); print $ip; print "".gethostbyaddr($ip); ?> For example, if I type -722987112, I want to obtain 212.232.23.152 with the good hostname. I have this problem : if I perform a print_r($_POST), I obtain : Array ( [entier] => -722987112entier=-722987112 ) The script worked fine with Apache 1.2.27/PHP 4.2.3 -- Edit this bug report at http://bugs.php.net/?id=21574&edit=1
#21248 [Opn->]: first find PQescapeBytea then use it
ID: 21248 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Won\'t fix Bug Type: PostgreSQL related Operating System: Linux2.4 PHP Version: 4.3.0 Assigned To: yohgaki Previous Comments: [2003-01-10 22:00:52] [EMAIL PROTECTED] If you are loading modules(shared objects in general) w/o required lib, it's normal to end up with undefined symbol. Use RPM or like to make sure you don't have such problems. [2003-01-05 06:01:24] [EMAIL PROTECTED] you missunderstood the problem. i wasn't talking about php's own pg_* "interface", functions i was talking about a symbol(excacly PQexcapeString) which php uses, as a shared library and also as a static library for apache, but on some hosts(I, Gergely Czuczy, don't know why) libpq is not containing this symbol. this means when you try to compile apache or load the php module you get an unresolved symbol. and this means you are unable to load the PHP, which means PHP is absolutely, surely unusable. [2003-01-05 05:13:59] [EMAIL PROTECTED] I would not like to add php own libpq function clone for following reasons. - Users are supposed to use libpq that matches backend - There is no use of pg_(un)escape_bytea function prior to 7.2 - Users should be able to use addslashes() to escape strings. (Only a little inefficient and does not work for certain encodings. But these problematic encodings do not work with PHP anyway) Extream case is PostgreSQL 7.3.x. It cannot even connect to older versions of backends. Use the libpq that comes from backend. (Use the same major/minor version at least. You may use different patch level releases between client and backend) Since bytea is almost useless without unescape function, I added pg_unescape_bytea() using locally implemented unescape bytea function for 7.2 users and it's available from 4.3.0. (The unescape function is more efficient than original version, too :) [2002-12-28 10:19:11] [EMAIL PROTECTED] the postgresql module compiles for php, perfectly. but PQescapeBytea and PQescapeString is not available on all system, I don't know why, it's libpq's fault. php is linked dynamically with libpq, and PQescapeBytea is used by php. So apache cannot load the php module, due to an unresolved symbol(PQescapeBytea). if PQescapeBytea doesn't available on a system php should use an own implementation. -- Edit this bug report at http://bugs.php.net/?id=21248&edit=1
#21574 [Opn->Ver]: $_POST doesn't contain good value
ID: 21574 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Verified Bug Type: Variables related Operating System: RedHat 8 PHP Version: 4CVS-2003-01-10 (stable) New Comment: It looks the same as #21566. And it looks very critical to me? Previous Comments: [2003-01-10 20:23:54] [EMAIL PROTECTED] My configuration is : - RedHat8 - Apache 2.0.43 - PHP 4.3.1-dev (same problem with PHP 4.4.0-dev, PHP 5.0.0-dev ; PHP 4.3.0 have another annoying problem) I have IP stored in a db in longint format (with ip2long(...)). I use the following script to obtain the hostname of an IP. "; print ""; print ""; print ""; $ip = long2ip($entier); print $ip; print "".gethostbyaddr($ip); ?> For example, if I type -722987112, I want to obtain 212.232.23.152 with the good hostname. I have this problem : if I perform a print_r($_POST), I obtain : Array ( [entier] => -722987112entier=-722987112 ) The script worked fine with Apache 1.2.27/PHP 4.2.3 -- Edit this bug report at http://bugs.php.net/?id=21574&edit=1
#21248 [Opn]: first find PQescapeBytea then use it
ID: 21248 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: PostgreSQL related Operating System: Linux2.4 PHP Version: 4.3.0 Assigned To: yohgaki New Comment: If you are loading modules(shared objects in general) w/o required lib, it's normal to end up with undefined symbol. Use RPM or like to make sure you don't have such problems. Previous Comments: [2003-01-05 06:01:24] [EMAIL PROTECTED] you missunderstood the problem. i wasn't talking about php's own pg_* "interface", functions i was talking about a symbol(excacly PQexcapeString) which php uses, as a shared library and also as a static library for apache, but on some hosts(I, Gergely Czuczy, don't know why) libpq is not containing this symbol. this means when you try to compile apache or load the php module you get an unresolved symbol. and this means you are unable to load the PHP, which means PHP is absolutely, surely unusable. [2003-01-05 05:13:59] [EMAIL PROTECTED] I would not like to add php own libpq function clone for following reasons. - Users are supposed to use libpq that matches backend - There is no use of pg_(un)escape_bytea function prior to 7.2 - Users should be able to use addslashes() to escape strings. (Only a little inefficient and does not work for certain encodings. But these problematic encodings do not work with PHP anyway) Extream case is PostgreSQL 7.3.x. It cannot even connect to older versions of backends. Use the libpq that comes from backend. (Use the same major/minor version at least. You may use different patch level releases between client and backend) Since bytea is almost useless without unescape function, I added pg_unescape_bytea() using locally implemented unescape bytea function for 7.2 users and it's available from 4.3.0. (The unescape function is more efficient than original version, too :) [2002-12-28 10:19:11] [EMAIL PROTECTED] the postgresql module compiles for php, perfectly. but PQescapeBytea and PQescapeString is not available on all system, I don't know why, it's libpq's fault. php is linked dynamically with libpq, and PQescapeBytea is used by php. So apache cannot load the php module, due to an unresolved symbol(PQescapeBytea). if PQescapeBytea doesn't available on a system php should use an own implementation. -- Edit this bug report at http://bugs.php.net/?id=21248&edit=1
#21575 [Opn->Fbk]: 4.2x to 4.3 Compatibility issue
ID: 21575 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: *General Issues Operating System: Any PHP Version: 4.3.0 New Comment: Environment variables are supplied by the environment under which PHP is running. In most cases this means the webserver. Did you change/upgrade your webserver at the same time? Moreover, what webserver are you running and on what OS? Previous Comments: [2003-01-10 21:01:46] [EMAIL PROTECTED] Environment variable "PATH_INFO" disappeared in PHP4.30, which is presented in 4.1x and 4.2x. I know that I can use PHP_SELF instead, but my old codes now having problems. -- Edit this bug report at http://bugs.php.net/?id=21575&edit=1
#21575 [NEW]: 4.2x to 4.3 Compatibility issue
From: [EMAIL PROTECTED] Operating system: Any PHP version: 4.3.0 PHP Bug Type: *General Issues Bug description: 4.2x to 4.3 Compatibility issue Environment variable "PATH_INFO" disappeared in PHP4.30, which is presented in 4.1x and 4.2x. I know that I can use PHP_SELF instead, but my old codes now having problems. -- Edit bug report at http://bugs.php.net/?id=21575&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21575&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21575&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21575&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21575&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21575&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21575&r=support Expected behavior: http://bugs.php.net/fix.php?id=21575&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21575&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21575&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21575&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21575&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21575&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21575&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21575&r=gnused
#21262 [Com]: crash or fail when outputting large amounts of text quickly
ID: 21262
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Reproducible crash
Operating System: WinXP
PHP Version: 4.3.0
New Comment:
I had the exact same problem. I submitted a bug report. Bug smashers
seemed to go off on some random tangent. Then decided all of a sudden
that it was an IE problem (even though in my original report I clearly
stated that there was a problem with Mozilla/Netscape output as well).
My original bug report here:
http://bugs.php.net/bug.php?id=14474
Previous Comments:
[2002-12-30 15:45:50] [EMAIL PROTECTED]
Well that's strange, can anyone else repro this? You may need to
refresh a few times for it to happen. I have been using PHP from the
command line for the last year because of this issue.
[2002-12-30 10:05:43] [EMAIL PROTECTED]
This does not seem to be a problem. I can not reproduce this crash with
the following code.
for($Loop=0 ; $Loop<1 ; $Loop++)
{
echo "blah $Loop ";
}
I am also using the SAPI version of PHP in Apache under Windows XP.
[2002-12-29 15:26:55] [EMAIL PROTECTED]
Then maybe this should be a doc change: "If you don't call flush() once
in a while, PHP will hang. This is not a bug. Hanging is
intentional."
This is a BUG. If it causes PHP to HANG before outputting the page,
then it is a BUG! FLUSH IS NOT SUPPOSED TO BE MANDATORY.
This also happens when outputting pages under 20K, but this example is
the best way to repro. And as I stated, implicit flushing does not fix
the problem either. Any delay in the loop fixes it.
Every time I submit something here, somebody spends 15 seconds on it
and marks it as bogus. When it is NOT. I WENT TO THE TIME OF
SUBMITTING THIS FOR A REASON, AND I AM NOT A JACKASS. I HAVE BEEN
PROGRAMMING FOR 15 YEARS. If you treat every bug report on here like
an idiot wrote it, only idiots are going to stick around to report
"bugs" for you. Spend a little more than 15 seconds on it.
I gave exact details and the simplest repro on earth, not to mention
the results of possible contributing factors. What else could you
possibly want. Why is it so hard to get problems even acknowledged
here? Maybe I should just mark them as bogus in the beginning to save
a little time. This is as bad as reporting bugs to Microsoft.
[2002-12-29 14:08:46] [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
I think this is not a bug, but simply an issue of running out of
memory, because the data in the buffer simply gets too big. flush()
dumps the data inside the buffer to screen and clears the buffer, which
is why it wouldn't crash when flush() is used.
[2002-12-29 12:01:41] [EMAIL PROTECTED]
Setting implicit_flush to ON does not fix it - so maybe adding flush()
only helps because it slows it down..?
Also, messing with output_buffering has no effect.
This problem has been present ever since I started using PHP. Maybe a
memory overflow?
Can anyone else repro? (note this only happens with the sapi/mod
version)
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/21262
--
Edit this bug report at http://bugs.php.net/?id=21262&edit=1
#21574 [NEW]: $_POST doesn't contain good value
From: [EMAIL PROTECTED] Operating system: RedHat 8 PHP version: 4CVS-2003-01-10 (stable) PHP Bug Type: Variables related Bug description: $_POST doesn't contain good value My configuration is : - RedHat8 - Apache 2.0.43 - PHP 4.3.1-dev (same problem with PHP 4.4.0-dev, PHP 5.0.0-dev ; PHP 4.3.0 have another annoying problem) I have IP stored in a db in longint format (with ip2long(...)). I use the following script to obtain the hostname of an IP. "; print ""; print ""; print ""; $ip = long2ip($entier); print $ip; print "".gethostbyaddr($ip); ?> For example, if I type -722987112, I want to obtain 212.232.23.152 with the good hostname. I have this problem : if I perform a print_r($_POST), I obtain : Array ( [entier] => -722987112entier=-722987112 ) The script worked fine with Apache 1.2.27/PHP 4.2.3 -- Edit bug report at http://bugs.php.net/?id=21574&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21574&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21574&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21574&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21574&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21574&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21574&r=support Expected behavior: http://bugs.php.net/fix.php?id=21574&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21574&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21574&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21574&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21574&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21574&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21574&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21574&r=gnused
#21572 [Bgs]: date gives 0 as a week number of year
ID: 21572
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Date/time related
Operating System: Redhat 8.0
PHP Version: 4.2.2
New Comment:
I should also point out that the behavior you describe in your function
does NOT replicate the proper behavior of determining the ISO-8601 week
number.
Previous Comments:
[2003-01-10 16:53:43] [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.
[2003-01-10 16:50:14] [EMAIL PROTECTED]
This is a function what php needs for option to date function:
function get_a_week( $timestamp )
{
//Look the stamp for 1.1. 00:00:00 for current given stamp
$seeking_stamp = mktime( 0, 0, 0, 1, 1, date( "Y", $timestamp ) );
//Week numbers are 1-52 in practically
for( $i=1; $i < 53; $i++ )
{
//Check if the passed stamp is between monday 00:00:00 and sunday
23:59:59
if( $timestamp => $seeking_stamp and $aika <=
(($seeking_stamp+=7*24*3600)-1) )
return $i; //Found a week between 1-52
}
//Should never get here
return -1;
}
[2003-01-10 16:48:56] [EMAIL PROTECTED]
I cannot replicate this either, marking this as feedback until the user
can test with 4.3.0 or later.
[2003-01-10 16:40:26] [EMAIL PROTECTED]
1) I have not that kind of platform to use right know.
2) I am GMT +02:00 timezone.
[2003-01-10 16:34:37] [EMAIL PROTECTED]
Unable to reproduce with script given, output of date("W") is always >=
1 and <= 53.
(1) Could you try it with 4.3.0 and see if you get the same results?
(2) What timezone are you in?
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/21572
--
Edit this bug report at http://bugs.php.net/?id=21572&edit=1
#21573 [NEW]: fsockopen does not block
From: [EMAIL PROTECTED]
Operating system: Windows XP
PHP version: 4.3.0
PHP Bug Type: Sockets related
Bug description: fsockopen does not block
I have code that would connect to a pop server and retrieve email messages,
without using IMAP functions, which worked fine in PHP 4.0 to PHP 4.2.3,
but no longer works correctly in PHP 4.3.0. From what I can tell it seems
that although the socket shows that it is in blocking mode, it acts as
though it is not in blocking mode. The following code demonstrates the
problem.
With the debug statements added to the code and when it gets to the fgets
function, it loops continuously, without reading data from the stream,
until the time limit is reached.
\n";
socket_set_blocking ($fp, TRUE);
// debug
print_r (socket_get_status ($fp));
echo "\n";
$continue = 1;
while ($continue)
{
$chr = fgets ($fp, 1);
$str .= $chr;
// debug
echo "chr = $chr\n";
$array = explode ("\r\n", $str);
if ($str != $array[0])
{
$continue=0;
}
}
fclose ($fp);
?>
Output from version 4.3.0:
Array ( [stream_type] => socket [unread_bytes] => 0 [timed_out] =>
[blocked] => 1 [eof] => )
Array ( [stream_type] => socket [unread_bytes] => 0 [timed_out] =>
[blocked] => 1 [eof] => )
chr =
chr =
chr =
.
. (Loops continuously)
.
chr =
Fatal error: Maximum execution time of 30 seconds exceeded in
f:\httproot\popcorn0.8.2\includes\popcorn.inc on line 110
Output from version 4.2.3:
Array ( [timed_out] => [blocked] => 1 [eof] => [unread_bytes] => 0 )
Array ( [timed_out] => [blocked] => 1 [eof] => [unread_bytes] => 0 )
chr = +
chr = O
chr = K
chr =
chr = C
chr = u
chr = b
chr = i
chr = c
...
chr = .
chr = n
chr = e
chr = t
chr = >
chr =
chr =
I realize that fsockopen, opens the stream in blocking mode by default,
but I had to use socket_set_blocking prior to version 4.3.0 to get it to
work properly. I tried using stream_set_blocking with the same results.
Also, I have tried connecting to multiple POP mail servers with the same
result. Only when I go back to version 4.2.3, does it work properly.
--
Edit bug report at http://bugs.php.net/?id=21573&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21573&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=21573&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=21573&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21573&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=21573&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21573&r=support
Expected behavior: http://bugs.php.net/fix.php?id=21573&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=21573&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=21573&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=21573&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21573&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=21573&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=21573&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=21573&r=gnused
#21224 [Com]: apache configure fails at php module
ID: 21224 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Compile Failure Operating System: Solaris 8 PHP Version: 4.3.0 New Comment: Same problem as everyone else. ld: fatal: file /path/to/php-4.3.0/sapi/apache/php.sym unknown file type. Solaris8 and Solaris9. GNU gcc 3.2.1 libtool 1.4, automake 1.7.2, autoconf 2.57 Apache 1.3.27. However I will try not using --enable-versioning and see if that works. Because I did use that in my configure. Previous Comments: [2003-01-06 05:02:49] [EMAIL PROTECTED] Problem solved (for me) when removing --enable-versioning from the configure [2002-12-30 09:32:31] [EMAIL PROTECTED] I'm having the same problem building 4.3.0 with Apache on my server, previous builds were ok: RedHat Linux 7.1 kernel 2.4.18-18.7.xsmp gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs gcc version 2.96 2731 (Red Hat Linux 7.2 2.96-112.7.1) ld -v GNU ld version 2.10.91 (with BFD 2.10.91.0.2) libtool --version ltmain.sh (GNU libtool) 1.3.5 (1.385.2.206 2000/05/27 11:12:27) ./configure --prefix=/usr/local/php \ --with-config-file-path=/usr/local/php --with-mysql=/usr/local/mysql \ --with-pgsql=/usr/local/pgsql --with-oci8=/usr/local/oracle \ --with-oracle=/usr/local/oracle --with-sybase-ct=/opt/sybase-12.5/OCS-12_5 \ --with-pdflib=/usr/local/pdflib --with-jpeg --with-tiff --with-zlib \ --with-gd --with-ttf --with-freetype --with-xml --with-gettext \ --enable-ftp --enable-versioning --enable-sockets --enable-calendar \ --enable-sysvsem --enable-sysvshm --enable-track-vars --enable-debugger \ --enable-magic-quotes --enable-rpath --enable-short-tags --enable-posix \ --enable-session --enable-xml --enable-bcmath --enable-ctype --enable-mailparse \ --with-apache=../apache_1.3.27 ./configure --with-layout=Apache --prefix=/usr/local/apache \ --activate-module=src/modules/php4/libphp4.a --enable-module=so \ --enable-module=rewrite --add-module=mod_gzip.c Configuring for Apache, Version 1.3.27 + using installation path layout: Apache (config.layout) + activated php4 module (modules/php4/libphp4.a) + on-the-fly added and activated gzip module (modules/extra/mod_gzip.o) Creating Makefile Creating Configuration.apaci in src Creating Makefile in src + configured for Linux platform + setting C compiler to gcc + setting C pre-processor to gcc -E + checking for system header files + adding selected modules o rewrite_module uses ConfigStart/End + using -lndbm for DBM support enabling DBM support for mod_rewrite o php4_module uses ConfigStart/End + using system Expat + using -ldl for vendor DSO support + checking sizeof various data types + doing sanity check on compiler and options ** A test compilation with your Makefile configuration ** failed. The below error output from the compilation ** test will give you an idea what is failing. Note that ** Apache requires an ANSI C Compiler, such as gcc. Error Output for sanity check cd ..; gcc -DLINUX=22 -I/usr/include/db1 `./apaci` -o helpers/dummy helpers/dummy.c -Wl,-rpath,/usr/local/mysql/lib/mysql -Wl,-rpath,/usr/local/oracle/lib -Wl,-rpath,/lib -Wl,-rpath,/usr/local/pdflib/lib -Wl,-rpath,/usr/local/pgsql/lib -Wl,-rpath,/opt/sybase-12.5/OCS-12_5/lib -rdynamic -L/usr/local/mysql/lib/mysql -L/usr/local/oracle/lib -L/lib -L/usr/local/pdflib/lib -L/usr/local/pgsql/lib -L/opt/sybase-12.5/OCS-12_5/lib -Lmodules/php4 -L../modules/php4 -L../../modules/php4 -lmodphp4 -export-symbols /usr/local/src/php-4.3.0/sapi/apache/php.sym -rdynamic -L/usr/local/mysql/lib/mysql -L/usr/local/oracle/lib -L/lib -L/usr/local/pdflib/lib -L/usr/local/pgsql/lib -L/opt/sybase-12.5/OCS-12_5/lib -lsybtcl -lintl -lcomn -lct -lcs -lpq -lpdf -lz -lpng -lmysqlclient -lttf -lpng -lz -lz -lcrypt -lresolv -lm -ldl -lnsl -lcrypt -ldl -lm -lnsl -lclntsh -ldl -lm -lnsl -lclntsh -lm -lcrypt -lndbm -lexpat -ldl /usr/bin/ld:/usr/local/src/php-4.3.0/sapi/apache/php.sym: file format not recognized; treating as linker script /usr/bin/ld:/usr/local/src/php-4.3.0/sapi/apache/php.sym:2: parse error collect2: ld returned 1 exit status make: *** [dummy] Error 1 = End of Error Report = Aborting! [2002-12-30 05:59:59] [EMAIL PROTECTED] Same problem at Linux RedHat 6.2 machines, some with: GNU ld 2.9.5 ltmain.sh (GNU libtool) 1.4.2 (1.922.2.53 2001/09/11 03:18:52) and others with: GNU ld 2.13.2 ltmain.sh (GNU libtool) 1.4.3 (1.922.2.110 2002/10/23 01:39:54) [2002-12-28 04:33:22] [EMAIL PROTECTED] the libtool on the php distribut
#21532 [Opn->Fbk]: incorrect warning
ID: 21532 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: *Directory/Filesystem functions Operating System: Solaris 8 PHP Version: 4.3.0 New Comment: Is the '20021122' directory owned by user with uid of 405? Previous Comments: [2003-01-08 18:22:19] [EMAIL PROTECTED] /www/user405/data and /www/user405 exist. Both directories are owned by uid 405 with r-x permission for owner. [2003-01-08 18:16:50] [EMAIL PROTECTED] /www/user405/data and /www/user405 exist. Both directories are owned by uid 405 with r-x permission for owner. [2003-01-08 18:05:17] [EMAIL PROTECTED] But /www/user405/data/ does exist? I bet that directory is not accesible by the uid 405.. [2003-01-08 17:18:04] [EMAIL PROTECTED] PHP log: --- [08-Jan-2003 23:54:22] PHP Warning: opendir(): SAFE MODE Restriction in effect. The script whose uid is 405 is not allowed to access /www/user405/data/20021122 owned by uid 0 in /www/user405/stale/table1a_stale_bpl.php on line 3 [08-Jan-2003 23:54:22] PHP Warning: opendir(/www/user405/data/20021122/bpl): failed to open dir: No such file or directory in /www/user405/stale/table1a_stale_bpl.php on line 3 --- First warning is incorrect. Directory /www/user405/data/20021122 doesn't exist. -- Edit this bug report at http://bugs.php.net/?id=21532&edit=1
#21565 [Opn->Fbk]: safe_mode works well with include but not with require
ID: 21565 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Scripting Engine problem Operating System: Tru64Unix 5.1A PHP Version: 4.3.0 New Comment: It is likely that your error reporting level is such that warning messages do not get shown. Unlike require which fails with an error include will only output a warning on failure. Beyond that there is very little difference between the require/include code none of which is the code reponsible for actually openning files. Previous Comments: [2003-01-10 03:35:37] [EMAIL PROTECTED] After upgrade from PHP 4.2.2 to 4.3.0 I encountered the problem with safe_mode in conjunction with require(). Example: [php.ini] safe_mode = On; include_path = ".:./:/path/to/my/app/dir"; safe_mode_include_dir = ".:./:/path/to/my/app/dir"; [/path/to/my/app/dir/index_working.php] - works fine for me [/path/to/my/app/dir/index_buggy.php] - throws error The error: [error] PHP Fatal error: main() [function.main]: Failed opening required 'header.php' (include_path='.:./:/path/to/my/app/dir') in /path/to/my/app/dir/index_buggy.php on line 2 Operating system: Tru64Unix 5.1a Webserver: Apache 1.3.26 -- Edit this bug report at http://bugs.php.net/?id=21565&edit=1
#21572 [Opn->Bgs]: date gives 0 as a week number of year
ID: 21572
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: Date/time related
Operating System: Redhat 8.0
PHP Version: 4.2.2
New Comment:
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.
Thank you for your interest in PHP.
Previous Comments:
[2003-01-10 16:50:14] [EMAIL PROTECTED]
This is a function what php needs for option to date function:
function get_a_week( $timestamp )
{
//Look the stamp for 1.1. 00:00:00 for current given stamp
$seeking_stamp = mktime( 0, 0, 0, 1, 1, date( "Y", $timestamp ) );
//Week numbers are 1-52 in practically
for( $i=1; $i < 53; $i++ )
{
//Check if the passed stamp is between monday 00:00:00 and sunday
23:59:59
if( $timestamp => $seeking_stamp and $aika <=
(($seeking_stamp+=7*24*3600)-1) )
return $i; //Found a week between 1-52
}
//Should never get here
return -1;
}
[2003-01-10 16:48:56] [EMAIL PROTECTED]
I cannot replicate this either, marking this as feedback until the user
can test with 4.3.0 or later.
[2003-01-10 16:40:26] [EMAIL PROTECTED]
1) I have not that kind of platform to use right know.
2) I am GMT +02:00 timezone.
[2003-01-10 16:34:37] [EMAIL PROTECTED]
Unable to reproduce with script given, output of date("W") is always >=
1 and <= 53.
(1) Could you try it with 4.3.0 and see if you get the same results?
(2) What timezone are you in?
[2003-01-10 16:14:17] [EMAIL PROTECTED]
I found out that date("W", $stamp) can gives a zero as output.
Out could be for examble "01.01.2005 00:46 0 1104533193".
I check the ISO-8601 standard (version 2000-12-19
ISO/TC 154 N 362) and it says:
calendar week is represented by two decimal digits. The first calendar
week of a year shall be identified as
[01] and subsequent weeks shall be numbered in ascending sequence.
Futhermore the date function should have a option for 'normally' week
number of the year like most of people does it understand practically:
1.1. is 1 and so on and finally 31.12. is 52.
--
Edit this bug report at http://bugs.php.net/?id=21572&edit=1
#21530 [Opn->Fbk]: date("T") on returns "Standard Time" instead of "Daylight Time"
ID: 21530
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: Date/time related
Operating System: Win32
PHP Version: 4.2.3
New Comment:
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
Seems to work fine in 4.3.0
Previous Comments:
[2003-01-08 16:56:43] [EMAIL PROTECTED]
.
[2003-01-08 15:55:10] [EMAIL PROTECTED]
echo "" | php.exe
Always outputs the "Standard" identifier, regardless of the fact that
the Window's clock returns "Daylight/Standard" correctly.
date("I") correctly returns the correct 1/0 value for ST vs DT.
--
Edit this bug report at http://bugs.php.net/?id=21530&edit=1
#21572 [Fbk->Opn]: date gives 0 as a week number of year
ID: 21572
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: Date/time related
Operating System: Redhat 8.0
PHP Version: 4.2.2
New Comment:
This is a function what php needs for option to date function:
function get_a_week( $timestamp )
{
//Look the stamp for 1.1. 00:00:00 for current given stamp
$seeking_stamp = mktime( 0, 0, 0, 1, 1, date( "Y", $timestamp ) );
//Week numbers are 1-52 in practically
for( $i=1; $i < 53; $i++ )
{
//Check if the passed stamp is between monday 00:00:00 and sunday
23:59:59
if( $timestamp => $seeking_stamp and $aika <=
(($seeking_stamp+=7*24*3600)-1) )
return $i; //Found a week between 1-52
}
//Should never get here
return -1;
}
Previous Comments:
[2003-01-10 16:48:56] [EMAIL PROTECTED]
I cannot replicate this either, marking this as feedback until the user
can test with 4.3.0 or later.
[2003-01-10 16:40:26] [EMAIL PROTECTED]
1) I have not that kind of platform to use right know.
2) I am GMT +02:00 timezone.
[2003-01-10 16:34:37] [EMAIL PROTECTED]
Unable to reproduce with script given, output of date("W") is always >=
1 and <= 53.
(1) Could you try it with 4.3.0 and see if you get the same results?
(2) What timezone are you in?
[2003-01-10 16:14:17] [EMAIL PROTECTED]
I found out that date("W", $stamp) can gives a zero as output.
Out could be for examble "01.01.2005 00:46 0 1104533193".
I check the ISO-8601 standard (version 2000-12-19
ISO/TC 154 N 362) and it says:
calendar week is represented by two decimal digits. The first calendar
week of a year shall be identified as
[01] and subsequent weeks shall be numbered in ascending sequence.
Futhermore the date function should have a option for 'normally' week
number of the year like most of people does it understand practically:
1.1. is 1 and so on and finally 31.12. is 52.
--
Edit this bug report at http://bugs.php.net/?id=21572&edit=1
#21572 [Opn->Fbk]: date gives 0 as a week number of year
ID: 21572
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: Date/time related
Operating System: Redhat 8.0
PHP Version: 4.2.2
New Comment:
I cannot replicate this either, marking this as feedback until the user
can test with 4.3.0 or later.
Previous Comments:
[2003-01-10 16:40:26] [EMAIL PROTECTED]
1) I have not that kind of platform to use right know.
2) I am GMT +02:00 timezone.
[2003-01-10 16:34:37] [EMAIL PROTECTED]
Unable to reproduce with script given, output of date("W") is always >=
1 and <= 53.
(1) Could you try it with 4.3.0 and see if you get the same results?
(2) What timezone are you in?
[2003-01-10 16:14:17] [EMAIL PROTECTED]
I found out that date("W", $stamp) can gives a zero as output.
Out could be for examble "01.01.2005 00:46 0 1104533193".
I check the ISO-8601 standard (version 2000-12-19
ISO/TC 154 N 362) and it says:
calendar week is represented by two decimal digits. The first calendar
week of a year shall be identified as
[01] and subsequent weeks shall be numbered in ascending sequence.
Futhermore the date function should have a option for 'normally' week
number of the year like most of people does it understand practically:
1.1. is 1 and so on and finally 31.12. is 52.
--
Edit this bug report at http://bugs.php.net/?id=21572&edit=1
#21547 [Opn->]: segfault in _erealloc
ID: 21547
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Won\'t fix
Bug Type: Reproducible crash
Operating System: Linux Mandrake Cooker
PHP Version: 4.3.0
New Comment:
Your recusive function causes a stack overflow because PHP does not
have stack protection. This is not likely to be fixed in the near or
even the far future. When using recursive functions add your own checks
to prevent recursion beyond a certain level.
Previous Comments:
[2003-01-10 05:11:35] [EMAIL PROTECTED]
Works fine, even with 12500.
With 10 I get
FATAL: emalloc(): Unable to allocate 11 bytes
[2003-01-09 16:20:34] [EMAIL PROTECTED]
Perphaps you have a system limit on the amount of memory a process make
try to use. Try the following script and see if it crashes:
[2003-01-09 10:23:39] [EMAIL PROTECTED]
The diagnosis is strange as it crashes using about 20MB while the
memory limit is at 128MB and I have more than 200MB free...
[2003-01-09 10:00:04] [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
Simple, PHP has run out of memory and when it fails to allocate it
exits or if you compiled PHP with --enable-debug dies with SIG11
(segmentation fault).
[2003-01-09 07:59:49] [EMAIL PROTECTED]
This quite heavily recursive script produces a segmentation fault :
Array(-1, 0),
'D'=>Array(1, 0),
'B'=>Array(0, 1),
'H'=>Array(0, -1));
$pieces=Array(
Array(Array(0,0),
Array(0,1)),
Array(Array(0,0),
Array(0,1)),
Array(Array(0,0),
Array(0,1)),
Array(Array(0,0),
Array(0,1)),
Array(Array(0,0),
Array(0,1),
Array(1,0),
Array(1,1)),
Array(Array(0,0)),
Array(Array(0,0)),
Array(Array(0,0)),
Array(Array(0,0)),
Array(Array(0,0),
Array(1,0)));
$init=Array(
Array(0,0),
Array(3,0),
Array(1,3),
Array(2,3),
Array(1,0),
Array(0,3),
Array(0,4),
Array(3,3),
Array(3,4),
Array(1,2));
function is_final($situation){
return(($situation[4][0]==1)&&($situation[4][1]==3));
}
function occupable($situation, $x, $y){
global $pieces;
if($x>3) return false;
if($y>4) return false;
if($x<0) return false;
if($y<0) return false;
foreach($situation as $piece=>$pos){
if($pos=="") continue;
$p = $pieces[$piece];
foreach($p as $case){
if(($case[0]+$pos[0]==$x)&&
($case[1]+$pos[1]==$y)) return false;
}
}
return true;
}
function valide($situation, $piece, $mov){
global $pieces;
$p = $pieces[$piece];
$x = $situation[$piece][0];
$y = $situation[$piece][1];
$situation[$piece]="";
foreach($p as $case){
if(!occupable($situation, $x+$case[0]+$mov[0], $y+$case[1]+$mov[1]))
return false;
}
return true;
}
function resolv($situation){
global $tab, $depls, $pieces, $solution;
$d = $depls;
$p = $pieces;
if(is_final($situation)){
$solution = "";
return;
}
foreach($p as $num=>$piece){
foreach($d as $nom=>$mov){
if(valide($situation, $num, $mov)){
$situation2=serialize($situation);
$s3=$situation;
$situation[$num][0]+=$mov[0];
$situation[$num][1]+=$mov[1];
$s=serialize($situation);
if(isset($tab[$s])){
$situation = $s3;
continue;
}
$tab[$s]="";
//echo $num.' '.$nom."\n";
#21572 [Fbk->Opn]: date gives 0 as a week number of year
ID: 21572
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: Date/time related
Operating System: Redhat 8.0
PHP Version: 4.2.2
New Comment:
1) I have not that kind of platform to use right know.
2) I am GMT +02:00 timezone.
Previous Comments:
[2003-01-10 16:34:37] [EMAIL PROTECTED]
Unable to reproduce with script given, output of date("W") is always >=
1 and <= 53.
(1) Could you try it with 4.3.0 and see if you get the same results?
(2) What timezone are you in?
[2003-01-10 16:14:17] [EMAIL PROTECTED]
I found out that date("W", $stamp) can gives a zero as output.
Out could be for examble "01.01.2005 00:46 0 1104533193".
I check the ISO-8601 standard (version 2000-12-19
ISO/TC 154 N 362) and it says:
calendar week is represented by two decimal digits. The first calendar
week of a year shall be identified as
[01] and subsequent weeks shall be numbered in ascending sequence.
Futhermore the date function should have a option for 'normally' week
number of the year like most of people does it understand practically:
1.1. is 1 and so on and finally 31.12. is 52.
--
Edit this bug report at http://bugs.php.net/?id=21572&edit=1
#21540 [Opn->Fbk]: include_path problem
ID: 21540 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Scripting Engine problem Operating System: Linux PHP Version: 4.3.0 New Comment: Do you have include_path specified in your php.ini? Previous Comments: [2003-01-10 01:53:50] [EMAIL PROTECTED] I'm running Apache 1.3.27. I tried include_path both in httpd.conf and .htaccess. Problem existed in both cases. [2003-01-09 19:42:16] [EMAIL PROTECTED] Which Apache are you using and where are you specifying the include_path, httpd.conf (virtual host) or .htaccess? [2003-01-09 03:37:10] [EMAIL PROTECTED] It seems that include_path is not working correctly. When I try to include Mail.php from PEAR I get Warning: sendmail() [function.sendmail]: Failed opening 'Mail.php' for inclusion (include_path='./:/usr/local/src/php-4.3/pear;') in /usr/local/apache/www/htdocs/aircargo.idstudio.pl/funcs.php on line 6 Mail.php IS in directory /usr/local/src/php-4.3/pear My config: php_value include_path ./:/usr/local/src/php-4.3/pear Look at the error - there is ; at the end of include_path, but it is not in my server configuration. When I added another path at the end: php_value include_path ./:/usr/local/src/php-4.3/pear:. script started to work. I think that there is an typo somewhere in the code. -- Edit this bug report at http://bugs.php.net/?id=21540&edit=1
#21572 [Opn->Fbk]: date gives 0 as a week number of year
ID: 21572
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: Date/time related
Operating System: Redhat 8.0
PHP Version: 4.2.2
New Comment:
Unable to reproduce with script given, output of date("W") is always >=
1 and <= 53.
(1) Could you try it with 4.3.0 and see if you get the same results?
(2) What timezone are you in?
Previous Comments:
[2003-01-10 16:14:17] [EMAIL PROTECTED]
I found out that date("W", $stamp) can gives a zero as output.
Out could be for examble "01.01.2005 00:46 0 1104533193".
I check the ISO-8601 standard (version 2000-12-19
ISO/TC 154 N 362) and it says:
calendar week is represented by two decimal digits. The first calendar
week of a year shall be identified as
[01] and subsequent weeks shall be numbered in ascending sequence.
Futhermore the date function should have a option for 'normally' week
number of the year like most of people does it understand practically:
1.1. is 1 and so on and finally 31.12. is 52.
--
Edit this bug report at http://bugs.php.net/?id=21572&edit=1
#11442 [Com]: Random "Warnig: Failed opening" on any php file
ID: 11442 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: No Feedback Bug Type: iPlanet related Operating System: Solaris 7 PHP Version: 4.1 New Comment: I have installed the latest version of php (4.3.2 - Jan2) on Solaris 5.8 , IPlanet, and can verify this problem still exists. In fact, a different server with the same build configuration of php, and same versions of Netscape/Iplanet, php works fine... PHP Version 4.3.0 System SunOS wildcat 5.8 Generic_108528-17 sun4u Build Date Jan 2 2003 16:57:46 Configure Command './configure' '--enable-libgcc' '--prefix=/usr/local' '--with-oci8=/u/ora/app/oracle/product/9.0.1' '--with-nsapi=/u/web/netscape/iplanet/' '--enable-sysvsem' '--enable-discard-path' '--enable-magic-quotes' '--enable-memory-limit' '--enable-versioning' '--enable-track-vars' '--enable-trans-sid' '--enable-sigchild' Server API NSAPI Virtual Directory Support enabled Configuration File (php.ini) Path /usr/local/lib/php.ini PHP API 20020918 PHP Extension 20020429 Zend Extension 20021010 Debug Build no Thread Safety enabled Registered PHP Streams php, http, ftp Have there been any bug patches explicitly related to this? Previous Comments: [2002-12-04 09:38:28] [EMAIL PROTECTED] We are running PHP 4.2.3 with iPlanet Enterprise Web Server 6.0 SP4. We have the same php module used by several server instances, one of which works perfectly. The php module in other instances seems to freeze randomly: one minute the page works, next all we have is an empty page containing nothing more than tags. [2002-09-26 20:04:33] [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-09-09 10:36:57] [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 I know I've said it before, but there was a bug fix in 4.2.3 that dealt with a timing issue. Wondering if this helps any for your systems. [2002-09-05 10:10:57] [EMAIL PROTECTED] I have the same problem under Debian/apache/PHP 4.2.2 Warning: Failed opening '/var/www/HTTP/index.php' for inclusion .. I have read that include_path in php.ini should be set to ".", then that include_path shoul be commented, but nothing helps... [2002-08-29 10:13:08] [EMAIL PROTECTED] I'm experimenting exactly the same problem reported by [EMAIL PROTECTED], but I'm using PHP 4.1.2 and Iplanet WebServer 4.1sp9 over sparc solaris 8. This is a heavy load web server. 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/11442 -- Edit this bug report at http://bugs.php.net/?id=11442&edit=1
#21572 [NEW]: date gives 0 as a week number of year
From: [EMAIL PROTECTED]
Operating system: Redhat 8.0
PHP version: 4.2.2
PHP Bug Type: Date/time related
Bug description: date gives 0 as a week number of year
I found out that date("W", $stamp) can gives a zero as output.
Out could be for examble "01.01.2005 00:46 0 1104533193".
I check the ISO-8601 standard (version 2000-12-19
ISO/TC 154 N 362) and it says:
calendar week is represented by two decimal digits. The first calendar
week of a year shall be identified as
[01] and subsequent weeks shall be numbered in ascending sequence.
Futhermore the date function should have a option for 'normally' week
number of the year like most of people does it understand practically:
1.1. is 1 and so on and finally 31.12. is 52.
--
Edit bug report at http://bugs.php.net/?id=21572&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21572&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=21572&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=21572&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21572&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=21572&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21572&r=support
Expected behavior: http://bugs.php.net/fix.php?id=21572&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=21572&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=21572&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=21572&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21572&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=21572&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=21572&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=21572&r=gnused
#17414 [Com]: Segfaults on restart
ID: 17414
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Apache2 related
Operating System: Linux
PHP Version: 4.3.0
Assigned To: aaron
New Comment:
I am also experiencing this bug. It is annoying because it causes
apache to silently die every night when the logrotate script runs
(installed from the "apache2-common 2.0.43-1" debian package)
install details:
Apache/2.0.43 (Debian GNU/Linux)
PHP/4.3.0RC4
php configure: ./configure --with-mysql=/usr --with-imap
--with-imap-ssl --with-apxs2=/usr/bin/apxs2 --with-gettext --with-xml
running mpm-prefork
error log:
[Fri Jan 10 11:59:41 2003] [notice] seg fault or similar nasty error
detected in the parent proces
"apache2ctl restart" doesn't crash when php module isn't loaded
If I can help, let me know!
Previous Comments:
[2003-01-03 14:35:35] [EMAIL PROTECTED]
Still occurs in 4.3.0
[2002-12-10 16:00:46] [EMAIL PROTECTED]
4.3.0 RC2 configured with:
'./configure' '--enable-experimental-zts'
'--with-apxs2=/usr/local/apache2-php/bin/apxs' '--enable-debug'
the phpinfo() function generates the page that is dumped to:
http://samizdat.positive-internet.com/~thom/phpinfo.html
the sequence is:
in ServerRoot:
bin/apachectl start
make connection to verify the server is running, resulting in the above
page.
bin/apachectl restart
apache dies at this point.
this is the error log:
[Tue Dec 10 21:40:23 2002] [notice] Apache/2.0.44-dev (Unix)
PHP/4.3.0RC2 configured -- resuming normal operations
[Tue Dec 10 21:41:51 2002] [notice] SIGHUP received. Attempting to
restart
[Tue Dec 10 21:41:54 2002] [notice] seg fault or similar nasty error
detected in the parent process
(gdb) where
#0 0x4031e2d9 in php_output_activate (tsrm_ls=0x813c0c0)
at /home/thom/php-4.3.0RC2/main/output.c:85
#1 0x4030e86a in php_module_startup (sf=0x4039c460,
additional_modules=0x4039c640, num_additional_modules=1)
at /home/thom/php-4.3.0RC2/main/main.c:1021
#2 0x4035d65e in php_apache2_startup (sapi_module=0x4039c460)
at /home/thom/php-4.3.0RC2/sapi/apache2filter/sapi_apache2.c:269
#3 0x4035dded in php_apache_server_startup (pconf=0x80b60c8,
plog=0x80ee1a8,
ptemp=0x80b80d0, s=0x80f4a60)
at /home/thom/php-4.3.0RC2/sapi/apache2filter/sapi_apache2.c:551
#4 0x0807c381 in ap_run_post_config (pconf=0x80b60c8, plog=0x80ee1a8,
ptemp=0x80b80d0, s=0x80f4a60) at config.c:130
#5 0x08080bbc in main (argc=3, argv=0xbd54) at main.c:640
(gdb) frame 0
#0 0x4031e2d9 in php_output_activate (tsrm_ls=0x813c0c0)
at /home/thom/php-4.3.0RC2/main/output.c:85
85 OG(php_body_write) = php_ub_body_write;
(gdb) frame 1
#1 0x4030e86a in php_module_startup (sf=0x4039c460,
additional_modules=0x4039c640, num_additional_modules=1)
at /home/thom/php-4.3.0RC2/main/main.c:1021
1021php_output_activate(TSRMLS_C);
(gdb) frame 2
#2 0x4035d65e in php_apache2_startup (sapi_module=0x4039c460)
at /home/thom/php-4.3.0RC2/sapi/apache2filter/sapi_apache2.c:269
269 if (php_module_startup(sapi_module, &php_apache_module,
1)==FAILURE) {
(gdb) frame 3
#3 0x4035dded in php_apache_server_startup (pconf=0x80b60c8,
plog=0x80ee1a8,
ptemp=0x80b80d0, s=0x80f4a60)
at /home/thom/php-4.3.0RC2/sapi/apache2filter/sapi_apache2.c:551
551 apache2_sapi_module.startup(&apache2_sapi_module);
[2002-12-08 17:55:57] [EMAIL PROTECTED]
That´s pure luck as GD is not threadsafe.
[2002-12-08 17:53:10] [EMAIL PROTECTED]
If you are compiling Apache 2.0 with worker model you should've used
the --enable-experimental-zts, which enables threading support in PHP,
you didn't do that.
Did you personally see it crash with prefork? I did not and I am
running Apache 2.0.43 (prefork) with PHP 4.3.0-dev and surprisingly it
served some 10,000 requests to PHP script doing GD image manipulations
without a single crash.
[2002-12-08 17:40:58] [EMAIL PROTECTED]
How else do you explain the fact that all current versions of apache2
segfault reproducibly with no options to php barring --enable-debug and
--with-apxs2?
And the *exact* same install functions *perfectly* when php is not
loaded.
I've been told this is producible with prefork, too.
*Please* reread the back traces i've put on this bug. I'm happy to help
in anyway, just don't close valid bugs as bogus.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the
#21571 [Opn->Csd]: command system(),passthru, etc error
ID: 21571 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Scripting Engine problem Operating System: Redhat 7.3 PHP Version: 4.2.3 New Comment: there some buggy under /etc/php.ini with customize setting and default setting from source :) im sorry for this report thx onOs Previous Comments: [2003-01-10 14:29:49] [EMAIL PROTECTED] #!/usr/bin/php -q output [sono.jalin@www conf]$ ./test.php sh: 1/ls: No such file or directory [sono.jalin@www conf]$ list modules : [sono.jalin@www conf]$ php -m Running PHP 4.2.3 Zend Engine v1.2.0, Copyright (c) 1998-2002 Zend Technologies [PHP Modules] yp xml wddx sysvshm sysvsem standard sockets shmop session pspell posix pcre openssl ncurses iconv gmp gettext ftp exif domxml dio dbx dba curl ctype calendar bz2 bcmath zlib session mm mysql snmp pdf gd [Zend Modules] information compile php-4.2.3 include # Patch to get around a dumb assumption that size_t is always 4 bytes Patch0: php-4.2.1-64bit-iconv.patch # Argh! openldap 2.1.x changed it's API! This is needed only for openldap 2.1.x and higher Patch1: php-4.2.1-ldap-TSRM.patch # Patch to tweak the default php.ini to something a little more unix like Patch2: php-4.2.1-php.ini-dist.patch # Patch to pass in -DUCD_COMPATIBLE to the net-snmp package Patch3: php-4.2.1-snmp.patch # Patch to prevent zts being compiled in Patch7: php-4.2.2-disable-zts.patch all patch based redhat patch no gdb backtrace since this php is not core dump or something :) note : php-4.2.2 under my system is working perfectly with command system(), passthru, etc thx onOs -- Edit this bug report at http://bugs.php.net/?id=21571&edit=1
#21245 [Com]: Windows Extensions can't load php_domxml.dll
ID: 21245 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: DOM XML related Operating System: XP PHP Version: 4.3.0 New Comment: Yep, is indeed bogus. Have put libxml2.dll version 2.4.30 for win32 in in /windows/system32/ folder and still get the same error message. Adding the same libxml2.dll in the windows/system/ also creates the exact same error. Even adding this libxml2.dll to the windows/php.ini as an extension creates the same error. The problem was that I started out with the windows installer version of PHP 4.3.0 and then just copied the libxml2 and php_domxml from the windows4.3.0.zip file to their locations. I completely forgot to copy the other DLL's from the php_install_dir/dlls/ folder to windows/system32. This solved the problem. sorry for all this. Previous Comments: [2003-01-10 14:34:23] [EMAIL PROTECTED] Yep, is indeed bogus. Have put libxml2.dll version 2.4.30 for win32 in in /windows/system32/ folder and still get the same error message. Adding the same libxml2.dll in the windows/system/ also creates the exact same error. Even adding this libxml2.dll to the windows/php.ini as an extension creates the same error. The problem was that I started out with the windows installer version of PHP 4.3.0 and then just copied the libxml2 and php_domxml from the windows4.3.0.zip file to their locations. I completely forgot to copy the other DLL's from the php_install_dir/dlls/ folder to windows/system32. This solved the problem. sorry for all this. [2003-01-08 17:03:15] [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. If you look at: http://www.php.net/manual/en/install.windows.php you'll notice that for some extensions to work under windows additional dlls must be copied to the correct location. In your case libxml2.dll must be copied from the /extensions folder in your PHP distribution ZIP to your C:\WINDOWS\SYSTEM32 folder. [2003-01-08 16:44:03] [EMAIL PROTECTED] loading the php_domxml.dll library supplied with the PHP 4.3.0 zip package is impossible. Activating the librabry in the php.ini file by removing out the ";" will result in the following "warning" alert popup: "Unknown(): Unable to load dynamic library 'c:\php\ext\php_domxml.dll" - Can't find the ... module (OK button) and the following message on the loaded PHP page itself: "Content-type: text/html X-Powered-By: PHP/4.3.0 Fatal error: Call to undefined function: domxml_open_file() in c:\inetpub\wwwroot\build\aimledit\testxml.php on line 12 PHP Warning: Unknown(): Unable to load dynamic library 'c:\php\ext\php_domxml.dll' - Kan opgegeven module niet vinden. in Unknown on line 0 " Hope this will help you track the problem. [2002-12-28 09:15:10] [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. [2002-12-28 09:12:48] [EMAIL PROTECTED] can't load php_domxml.dll only! -_- -- Edit this bug report at http://bugs.php.net/?id=21245&edit=1
#21245 [Com]: Windows Extensions can't load php_domxml.dll
ID: 21245 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: DOM XML related Operating System: XP PHP Version: 4.3.0 New Comment: Yep, is indeed bogus. Have put libxml2.dll version 2.4.30 for win32 in in /windows/system32/ folder and still get the same error message. Adding the same libxml2.dll in the windows/system/ also creates the exact same error. Even adding this libxml2.dll to the windows/php.ini as an extension creates the same error. The problem was that I started out with the windows installer version of PHP 4.3.0 and then just copied the libxml2 and php_domxml from the windows4.3.0.zip file to their locations. I completely forgot to copy the other DLL's from the php_install_dir/dlls/ folder to windows/system32. This solved the problem. sorry for all this. Previous Comments: [2003-01-08 17:03:15] [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. If you look at: http://www.php.net/manual/en/install.windows.php you'll notice that for some extensions to work under windows additional dlls must be copied to the correct location. In your case libxml2.dll must be copied from the /extensions folder in your PHP distribution ZIP to your C:\WINDOWS\SYSTEM32 folder. [2003-01-08 16:44:03] [EMAIL PROTECTED] loading the php_domxml.dll library supplied with the PHP 4.3.0 zip package is impossible. Activating the librabry in the php.ini file by removing out the ";" will result in the following "warning" alert popup: "Unknown(): Unable to load dynamic library 'c:\php\ext\php_domxml.dll" - Can't find the ... module (OK button) and the following message on the loaded PHP page itself: "Content-type: text/html X-Powered-By: PHP/4.3.0 Fatal error: Call to undefined function: domxml_open_file() in c:\inetpub\wwwroot\build\aimledit\testxml.php on line 12 PHP Warning: Unknown(): Unable to load dynamic library 'c:\php\ext\php_domxml.dll' - Kan opgegeven module niet vinden. in Unknown on line 0 " Hope this will help you track the problem. [2002-12-28 09:15:10] [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. [2002-12-28 09:12:48] [EMAIL PROTECTED] can't load php_domxml.dll only! -_- -- Edit this bug report at http://bugs.php.net/?id=21245&edit=1
#16411 [Com]: CGI application misbehaved by not returning a complete set of
ID: 16411 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: MSSQL related Operating System: Windows 2000 PHP Version: 4.3.0 New Comment: I can also verify the problem. MSSQL_ call followed by a header redirect produces this problem more often than it doesn't. IIS5 with php 4.2.x. Since I've been fighting this problem off and on over the last few months, I've had to switch to ODBC to meet an upcoming launch date. However, I'll continue to follow and contribute any info I can when time allows. Previous Comments: [2003-01-06 12:03:30] [EMAIL PROTECTED] Updating version [2003-01-06 12:02:13] [EMAIL PROTECTED] What version of the MDAC are all of you using? I've heard that the latest MDAC causes a lot of problems and that many users are downgrading to the last version. Just wondering if this might be true or not for any of you. [2003-01-02 09:27:17] [EMAIL PROTECTED] I have experienced the same bug when running Win2000 Server and MS Sql 2000. MS SQL 7 would not produce this error. The error has been reproduced in all PHP versions I've tried up to 4.3.0. I've tried to use delays and change preformance parameters in MSSQL, but no luck there. A temporary solution would be to rewrite the code to use ODBC for database calls. This cannot be considered a acceptable solution, but it does work for us until this bug is corrected. [2002-12-25 01:53:11] [EMAIL PROTECTED] Looks like feedback exists -> open [2002-12-24 01:00:03] [EMAIL PROTECTED] 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". 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/16411 -- Edit this bug report at http://bugs.php.net/?id=16411&edit=1
#21571 [NEW]: command system(),passthru, etc error
From: [EMAIL PROTECTED] Operating system: Redhat 7.3 PHP version: 4.2.3 PHP Bug Type: Scripting Engine problem Bug description: command system(),passthru, etc error #!/usr/bin/php -q output [sono.jalin@www conf]$ ./test.php sh: 1/ls: No such file or directory [sono.jalin@www conf]$ list modules : [sono.jalin@www conf]$ php -m Running PHP 4.2.3 Zend Engine v1.2.0, Copyright (c) 1998-2002 Zend Technologies [PHP Modules] yp xml wddx sysvshm sysvsem standard sockets shmop session pspell posix pcre openssl ncurses iconv gmp gettext ftp exif domxml dio dbx dba curl ctype calendar bz2 bcmath zlib session mm mysql snmp pdf gd [Zend Modules] information compile php-4.2.3 include # Patch to get around a dumb assumption that size_t is always 4 bytes Patch0: php-4.2.1-64bit-iconv.patch # Argh! openldap 2.1.x changed it's API! This is needed only for openldap 2.1.x and higher Patch1: php-4.2.1-ldap-TSRM.patch # Patch to tweak the default php.ini to something a little more unix like Patch2: php-4.2.1-php.ini-dist.patch # Patch to pass in -DUCD_COMPATIBLE to the net-snmp package Patch3: php-4.2.1-snmp.patch # Patch to prevent zts being compiled in Patch7: php-4.2.2-disable-zts.patch all patch based redhat patch no gdb backtrace since this php is not core dump or something :) note : php-4.2.2 under my system is working perfectly with command system(), passthru, etc thx onOs -- Edit bug report at http://bugs.php.net/?id=21571&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21571&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21571&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21571&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21571&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21571&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21571&r=support Expected behavior: http://bugs.php.net/fix.php?id=21571&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21571&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21571&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21571&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21571&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21571&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21571&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21571&r=gnused
#21570 [Opn->Csd]: Could you publish a changelog for PHP Manual
ID: 21570 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Feature/Change Request Operating System: Any PHP Version: 4.3.0 New Comment: Not likely that that will happen, but you can use this too: http://news.php.net/group.php?group=php.doc Previous Comments: [2003-01-10 14:03:35] [EMAIL PROTECTED] It's really hard to track changes in the PHP Manual without dowloading it on a daily/weekly/... basis. So it'd be nice if something like daily changelog (with the changed/updated manual page names) will appear on the php.net site. Thanks in advance! -- Edit this bug report at http://bugs.php.net/?id=21570&edit=1
#21559 [Opn->Fbk]: Fatal error: Nesting level too deep - recursive dependency? in Unknown on line
ID: 21559 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: *General Issues Operating System: redhat 8 PHP Version: 4.3.0 Previous Comments: [2003-01-10 14:12:42] [EMAIL PROTECTED] so it's not PDF related at all..? Can you try and reduce those configure options to minimum to see what actually is causing this. [2003-01-10 13:50:00] [EMAIL PROTECTED] ./configure' '--with-pdflib=/usr/local' '--with-snmp=shared,/usr' '--with-snmp=shared' '--enable-ucd-snmp-hack' '--with-tiff-dir=/usr/local/' '--host=i686-pc-linux-gnu' '--build=i686-pc-linux-gnu' '--target=i386-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/usr/com' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--prefix=/usr' '--with-config-file-path=/etc' '--enable-force-cgi-redirect' '--disable-debug' '--enable-pic' '--disable-rpath' '--enable-inline-optimization' '--with-bz2' '--with-db3' '--with-curl' '--with-dom=/usr' '--with-exec-dir=/usr/bin' '--with-freetype-dir=/usr' '--with-png-dir=/usr' '--with-gd' '--enable-gd-native-ttf' '--with-ttf' '--with-gdbm' '--with-gettext' '--with-ncurses' '--with-gmp' '--with-iconv' '--with-jpeg-dir=/usr' '--with-openssl' '--with-png' '--with-pspell' '--with-regex=system' '--with-xml' '--with-expat-dir=/usr' '--with-zlib' '--with-layout=GNU' '--enable-bcmath' '--enable-exif' '--enable-ftp' '--enable-magic-quotes' '--enable-safe-mode' '--enable-sockets' '--enable-sysvsem' '--enable-sysvshm' '--enable-discard-path' '--enable-track-vars' '--enable-trans-sid' '--enable-yp' '--enable-wddx' '--without-oci8' '--with-pear=/usr/share/pear' '--with-imap=shared' '--with-imap-ssl' '--with-kerberos=/usr/kerberos' '--with-ldap=shared' '--with-mysql=shared,/usr' '--with-pgsql=shared' '--with-unixODBC=shared' '--enable-memory-limit' '--enable-bcmath' '--enable-shmop' '--enable-versioning' '--enable-calendar' '--enable-dbx' '--enable-dio' '--enable-mcal' '--with-apxs2=/usr/sbin/apxs' I get Nesting Level Too Deep on everything, I tried downloading the snap shot you mentioned, but it gave errors on the configure -- everything works, just a nasty error. [2003-01-09 19:33:30] [EMAIL PROTECTED] I can not reproduce this with latest stable snapshot (from http://snaps.php.net) and using PDFlib 4.0.3. How did you configure both PHP and pdflib? [2003-01-09 18:38:38] [EMAIL PROTECTED] Fatal error: Nesting level too deep - recursive dependency? in Unknown on line 0 Perhaps it does not deal with php? but i do get this error creating any pdf document Running the example from the documentation web site will produce the error in 4.3 php pdflib-4.0.3 is what i have installed -- it will still create the document, and that is fine, but it gives this nasty error... no matter what i have tried .. it spits it out when creating a pdf... finished"; ?> -- Edit this bug report at http://bugs.php.net/?id=21559&edit=1
#21559 [Opn]: Fatal error: Nesting level too deep - recursive dependency? in Unknown on line
ID: 21559 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open -Bug Type: *Compile Issues +Bug Type: *General Issues Operating System: redhat 8 PHP Version: 4.3.0 New Comment: so it's not PDF related at all..? Can you try and reduce those configure options to minimum to see what actually is causing this. Previous Comments: [2003-01-10 13:50:00] [EMAIL PROTECTED] ./configure' '--with-pdflib=/usr/local' '--with-snmp=shared,/usr' '--with-snmp=shared' '--enable-ucd-snmp-hack' '--with-tiff-dir=/usr/local/' '--host=i686-pc-linux-gnu' '--build=i686-pc-linux-gnu' '--target=i386-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/usr/com' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--prefix=/usr' '--with-config-file-path=/etc' '--enable-force-cgi-redirect' '--disable-debug' '--enable-pic' '--disable-rpath' '--enable-inline-optimization' '--with-bz2' '--with-db3' '--with-curl' '--with-dom=/usr' '--with-exec-dir=/usr/bin' '--with-freetype-dir=/usr' '--with-png-dir=/usr' '--with-gd' '--enable-gd-native-ttf' '--with-ttf' '--with-gdbm' '--with-gettext' '--with-ncurses' '--with-gmp' '--with-iconv' '--with-jpeg-dir=/usr' '--with-openssl' '--with-png' '--with-pspell' '--with-regex=system' '--with-xml' '--with-expat-dir=/usr' '--with-zlib' '--with-layout=GNU' '--enable-bcmath' '--enable-exif' '--enable-ftp' '--enable-magic-quotes' '--enable-safe-mode' '--enable-sockets' '--enable-sysvsem' '--enable-sysvshm' '--enable-discard-path' '--enable-track-vars' '--enable-trans-sid' '--enable-yp' '--enable-wddx' '--without-oci8' '--with-pear=/usr/share/pear' '--with-imap=shared' '--with-imap-ssl' '--with-kerberos=/usr/kerberos' '--with-ldap=shared' '--with-mysql=shared,/usr' '--with-pgsql=shared' '--with-unixODBC=shared' '--enable-memory-limit' '--enable-bcmath' '--enable-shmop' '--enable-versioning' '--enable-calendar' '--enable-dbx' '--enable-dio' '--enable-mcal' '--with-apxs2=/usr/sbin/apxs' I get Nesting Level Too Deep on everything, I tried downloading the snap shot you mentioned, but it gave errors on the configure -- everything works, just a nasty error. [2003-01-09 19:33:30] [EMAIL PROTECTED] I can not reproduce this with latest stable snapshot (from http://snaps.php.net) and using PDFlib 4.0.3. How did you configure both PHP and pdflib? [2003-01-09 18:38:38] [EMAIL PROTECTED] Fatal error: Nesting level too deep - recursive dependency? in Unknown on line 0 Perhaps it does not deal with php? but i do get this error creating any pdf document Running the example from the documentation web site will produce the error in 4.3 php pdflib-4.0.3 is what i have installed -- it will still create the document, and that is fine, but it gives this nasty error... no matter what i have tried .. it spits it out when creating a pdf... finished"; ?> -- Edit this bug report at http://bugs.php.net/?id=21559&edit=1
#21230 [Bgs]: Refresh Problem
ID: 21230
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Apache2 related
Operating System: Windows 2000 Server
PHP Version: 4.3.0
New Comment:
I know some people with whom it does work with the same configuration
as me and even with internet explorer, so there must be something that
makes it work, I have been back and forth with the configuration files
and can not notice anything. I'm afraid i've had to go with IIS (I'm
Ashamed) as apache 1.3 dosen't have certain features I need. If any1
finds anything let me know
Previous Comments:
[2003-01-10 11:43:33] [EMAIL PROTECTED]
phpBB has seen this issue, but points the finger back at php instead.
It looks like ie caches the php files in temporary internet files.
Setting your temp int files to only cache 1MB is the only work around I
have found so far.
I found a bit of code that forces the browser not to cache the php
files, but I have yet to get it to work.
header("Cache-Control: post-check=0, pre-check=0", false);
header("Pragma: no-cache");
header("Expires: Mon, 26 Jul 1997 05:00:00 GMT");
/* Date in the past*/
header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT");
/* always modified*/
header("Cache-Control: no-cache, no-store, must-revalidate");
/* HTTP/1.1 */read
Anywho, here is the snip from phpBB.
- Posted by adrien at 8:27 AM on 11-26-2002 -
when "refreshing" a page css gets printed on page using ie. i thought
this was a problem with my site only, but also phpbb.com is
experiencing it!!
- Posted by psoTFX at 7:43 AM on 11-27-2002 -
This happens randomly for most, we've never been able to track down
where the problem may be coming from ... some have suggested it's the
browser, others the server, others phpBB ... given it's lack of
repeatability I'm afraid there isn't much we can do. It may be another
bug is causing this and thus fixing it will solve the problem ...
otherwise ... we welcome information on how to replicate the problem
consistently
- Posted by adrien at 12:37 AM on 12-20-2002 -
Not sure if this helps, but this problem occours to me even when using
the back button in phpmyadmin 2.3.0 and only when using IE, opera,
mozilla and netscape seem immune to this on win2k.
hope this helps
adrien
- Posted by psoTFX at 5:29 AM on 12-20-2002 -
This would therefore seem to indicate it's a "browser" problem given
it's existence on something other than phpBB.
- Posted by adrien at 5:32 AM on 12-20-2002 -
yes, my thoughts as well
[2002-12-27 22:10:25] [EMAIL PROTECTED]
This sounds like a question for the phpbb guys. And by the way,
Apache2+PHP is still very much experimental. I would suggest going
back to Apache 1.3.
[2002-12-27 21:40:32] [EMAIL PROTECTED]
I have been using PHP for a phpbb forum. Until recently i have been
using apache 1.3 with version 4.23 of PHP, which has been working fine,
but today I upgraded to Apache 2 with version 4.30 of PHP, and have
experienced some problems, although the forum actually works, it has
trouble refreshing, for example when i post a message it accepts that
i've posted the message, but however when i return to the forum, the
message has not appeared. Even clicking refresh on my browser does not
work, The only way to refresh the page is to delete my history and
offline files, and then press refresh again. I do not think this is a
problem with the forum itself as I have not touched any of the files
since I have upgraded.
--
Edit this bug report at http://bugs.php.net/?id=21230&edit=1
#21570 [NEW]: Could you publish a changelog for PHP Manual
From: [EMAIL PROTECTED] Operating system: Any PHP version: 4.3.0 PHP Bug Type: Feature/Change Request Bug description: Could you publish a changelog for PHP Manual It's really hard to track changes in the PHP Manual without dowloading it on a daily/weekly/... basis. So it'd be nice if something like daily changelog (with the changed/updated manual page names) will appear on the php.net site. Thanks in advance! -- Edit bug report at http://bugs.php.net/?id=21570&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21570&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21570&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21570&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21570&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21570&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21570&r=support Expected behavior: http://bugs.php.net/fix.php?id=21570&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21570&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21570&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21570&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21570&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21570&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21570&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21570&r=gnused
#21516 [Com]: sessions, its seams a bug
ID: 21516
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Session related
Operating System: FreeBSD 4.5
PHP Version: 4.3.0
New Comment:
yes i ck @register_globals on@
and tell me please what means "syperglobal" and why in php are so many
ways to registered sessions ?? :)
=
1/ session_register("barney");
2/ $_SESSION["barney"] = "something";
3/ $HTTP_SESSION_VARS["barney"] = "something";
===
ok. tell me pls how differs first way from 2(3) ..
if u test this example .. u will see that this works with a bug.. but
in php under win is works without bug (under win it works nice/perfect
&& and under *nix but in php 4.0.2 (also in older versions ))
PS. php-developers!!! can u tell me one thing. why i must post this bug
at a period of 2-months and YOU erase my post every time after i
posted.
this is very polite and nice. if it was a lame question i have
understood, but.
but u have not ever test this :(
PSS. have a nice php.develper.2003.year
Previous Comments:
[2003-01-08 09:32:25] [EMAIL PROTECTED]
Is you register_globals on? Also try using the $_SESSION superglobal to
register session variables instead of session_register.
[2003-01-08 05:12:42] [EMAIL PROTECTED]
$one is empty too
$rr = session_register(one); //then registered $one in session (one is
empty)
$rr = "example"; // then for example $rr = "example";
echo $fff; // end here we print $fff (but $fff have
been empty, we did not defined it )
echo $fsdf;
echo $empty;
//but this echoÂ’s example... WHY ??? this is small BUG
?>
==
$rf = session_start(); //begin session
$one = $two; //when $tho is empty --> $one is empty too
$rr = session_register(one); //then registered $one in session (one is
empty)
$rr = "example"; // then for example $rr = "example";
echo $fff; // end here we print $fff (but $fff have
been empty, we did not defined it )
echo $fsdf;
echo $empty;
//but this echoÂ’s example... WHY ??? this is small BUG
echo $fff;
echo $fsdf;
echo $empty; //this echoe nothing becouse $empty $fsdf $fff; is empty
// test this 2 //
--
Edit this bug report at http://bugs.php.net/?id=21516&edit=1
#21559 [Fbk->Opn]: Fatal error: Nesting level too deep - recursive dependency? in Unknown on line
ID: 21559 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open -Bug Type: PDF related +Bug Type: *Compile Issues Operating System: redhat 8 PHP Version: 4.3.0 New Comment: ./configure' '--with-pdflib=/usr/local' '--with-snmp=shared,/usr' '--with-snmp=shared' '--enable-ucd-snmp-hack' '--with-tiff-dir=/usr/local/' '--host=i686-pc-linux-gnu' '--build=i686-pc-linux-gnu' '--target=i386-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/usr/com' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--prefix=/usr' '--with-config-file-path=/etc' '--enable-force-cgi-redirect' '--disable-debug' '--enable-pic' '--disable-rpath' '--enable-inline-optimization' '--with-bz2' '--with-db3' '--with-curl' '--with-dom=/usr' '--with-exec-dir=/usr/bin' '--with-freetype-dir=/usr' '--with-png-dir=/usr' '--with-gd' '--enable-gd-native-ttf' '--with-ttf' '--with-gdbm' '--with-gettext' '--with-ncurses' '--with-gmp' '--with-iconv' '--with-jpeg-dir=/usr' '--with-openssl' '--with-png' '--with-pspell' '--with-regex=system' '--with-xml' '--with-expat-dir=/usr' '--with-zlib' '--with-layout=GNU' '--enable-bcmath' '--enable-exif' '--enable-ftp' '--enable-magic-quotes' '--enable-safe-mode' '--enable-sockets' '--enable-sysvsem' '--enable-sysvshm' '--enable-discard-path' '--enable-track-vars' '--enable-trans-sid' '--enable-yp' '--enable-wddx' '--without-oci8' '--with-pear=/usr/share/pear' '--with-imap=shared' '--with-imap-ssl' '--with-kerberos=/usr/kerberos' '--with-ldap=shared' '--with-mysql=shared,/usr' '--with-pgsql=shared' '--with-unixODBC=shared' '--enable-memory-limit' '--enable-bcmath' '--enable-shmop' '--enable-versioning' '--enable-calendar' '--enable-dbx' '--enable-dio' '--enable-mcal' '--with-apxs2=/usr/sbin/apxs' I get Nesting Level Too Deep on everything, I tried downloading the snap shot you mentioned, but it gave errors on the configure -- everything works, just a nasty error. Previous Comments: [2003-01-09 19:33:30] [EMAIL PROTECTED] I can not reproduce this with latest stable snapshot (from http://snaps.php.net) and using PDFlib 4.0.3. How did you configure both PHP and pdflib? [2003-01-09 18:38:38] [EMAIL PROTECTED] Fatal error: Nesting level too deep - recursive dependency? in Unknown on line 0 Perhaps it does not deal with php? but i do get this error creating any pdf document Running the example from the documentation web site will produce the error in 4.3 php pdflib-4.0.3 is what i have installed -- it will still create the document, and that is fine, but it gives this nasty error... no matter what i have tried .. it spits it out when creating a pdf... finished"; ?> -- Edit this bug report at http://bugs.php.net/?id=21559&edit=1
#21477 [Bgs->Ana]: $node->dump_node($node) crashes with libxml2-2.4.30
ID: 21477 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Analyzed Bug Type: DOM XML related Operating System: linux; kernel 2.4.18 PHP Version: 4.3.0 New Comment: This is a valid bug, by initial conclusion as to the nature of this bug was wrong. Previous Comments: [2003-01-10 12:54:57] [EMAIL PROTECTED] You're not in position to decide what is bogus and what is not. This is bogus. [2003-01-10 12:50:17] [EMAIL PROTECTED] Thanks for identifying the problem, chregu. But your comment didn't specify WHICH $root in the sample code was causing the problem. Here's an example: hi eot; $doc = domxml_open_mem($xml); $root=$doc->document_element(); //This won't work: //$nodeDump =$doc->dump_node($doc); //This crashes: //$nodeDump =$root->dump_node($root); //This works: $nodeDump =$doc->dump_node($root); echo htmlentities($nodeDump); ?> I have re-opened the bug for integrity of the bug database: a bug is not 'Bogus' if PHP crashes due to scripting errors. For the sake of others who get bitten, this should stay open until fixed, then set it to 'Closed'. [2003-01-10 11:56:45] [EMAIL PROTECTED] The error is here: $nodeContent =$root->dump_node($root); $root has to be a DOM_DOCUMENT and in your case it's DOM_ELEMENT. I'll fix the code, so it will throw an error, if it's not a DOM_DOCUMENT chregu [2003-01-10 04:44:37] [EMAIL PROTECTED] modified bug title to be more specific [2003-01-10 00:35:58] [EMAIL PROTECTED] Re-opening this bug. I'd be happy to work on it if some dom xml developers could give me a start. 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/21477 -- Edit this bug report at http://bugs.php.net/?id=21477&edit=1
#20782 [Opn->Fbk]: Segmentation fault using oracle 8.1.7
ID: 20782 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: OCI8 related Operating System: Linux RH7.3 (ker:2.4.18-3smp) PHP Version: 4.3.0RC2 New Comment: And if you're using Apache, is it linked with libpthread? Instructions here: http://www.php.net/manual/en/ref.oci8.php Previous Comments: [2003-01-10 13:06:09] [EMAIL PROTECTED] I have the same problem. I am using PHP v4.1.2 with Oracle 8.1.7. Even doing a simple insert or select causes this problem. [2002-12-03 06:18:35] [EMAIL PROTECTED] The only one that is not set is LD_PRELOAD. All the other are ok. I'm sending u a backtrace. [2002-12-03 03:48:31] [EMAIL PROTECTED] Just to make sure..did you have all the environment vars set? Check this: http://www.php.net/manual/en/ref.oci8.php [2002-12-03 03:08:50] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. [2002-12-03 03:07:59] [EMAIL PROTECTED] Hi: When using php in command line with oracle OCI 8 (Oracle version 8.1.7), I have a segmentation fault at the end of the program. (ocilogoff works fine, segm fault appear at the end tag of php ie. ?> ). This problem does not exist (or is not visible) when I use php through apache. Thanks for your answer ! -- Edit this bug report at http://bugs.php.net/?id=20782&edit=1
#21569 [Com]: PHP can't set cookies after a test with an unset variable
ID: 21569 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Unknown/Other Function Operating System: Windows 2000 only PHP Version: 4.3.0 New Comment: I've submitted a specific bug. It depends either from PHP or Windows 2000 itself in some way, because I've tested it deeply in many configurations of operating systems, Apache and PHP versions. The sample code provided is a proof of concept, not a code I'm asking advice about. Previous Comments: [2003-01-10 12:56:40] [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. [2003-01-10 12:55:06] [EMAIL PROTECTED] PHP can't set cookies on Windows 2000 systems after testing a non-existing variable. This problem was reported in the following conditions: - Windows 2000 server SP-3 (IIS not installed) - Apache v2.0.43 (confirmed on Apache v1.3.27 as well) - PHP 4.3.0 (confirmed on 4.2.2 and 4.2.3 as well) The problem happens with Windows 2000 only. On Windows 98 with the very same configuration, or on Linux, everything works fine. Try the following code: w2k/PHP setcookie bug test BEGIN "; ?> END When $test is not set, the cookie "debug" remains set to 1, while when $test is set to any value (including "", an empty string), cookie will be eventually properly set to 3. -- Edit this bug report at http://bugs.php.net/?id=21569&edit=1
#20782 [Com]: Segmentation fault using oracle 8.1.7
ID: 20782 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: OCI8 related Operating System: Linux RH7.3 (ker:2.4.18-3smp) PHP Version: 4.3.0RC2 New Comment: I have the same problem. I am using PHP v4.1.2 with Oracle 8.1.7. Even doing a simple insert or select causes this problem. Previous Comments: [2002-12-03 06:18:35] [EMAIL PROTECTED] The only one that is not set is LD_PRELOAD. All the other are ok. I'm sending u a backtrace. [2002-12-03 03:48:31] [EMAIL PROTECTED] Just to make sure..did you have all the environment vars set? Check this: http://www.php.net/manual/en/ref.oci8.php [2002-12-03 03:08:50] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. [2002-12-03 03:07:59] [EMAIL PROTECTED] Hi: When using php in command line with oracle OCI 8 (Oracle version 8.1.7), I have a segmentation fault at the end of the program. (ocilogoff works fine, segm fault appear at the end tag of php ie. ?> ). This problem does not exist (or is not visible) when I use php through apache. Thanks for your answer ! -- Edit this bug report at http://bugs.php.net/?id=20782&edit=1
#21569 [Opn->Bgs]: PHP can't set cookies after a test with an unset variable
ID: 21569 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Unknown/Other Function Operating System: Windows 2000 only PHP Version: 4.3.0 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. Previous Comments: [2003-01-10 12:55:06] [EMAIL PROTECTED] PHP can't set cookies on Windows 2000 systems after testing a non-existing variable. This problem was reported in the following conditions: - Windows 2000 server SP-3 (IIS not installed) - Apache v2.0.43 (confirmed on Apache v1.3.27 as well) - PHP 4.3.0 (confirmed on 4.2.2 and 4.2.3 as well) The problem happens with Windows 2000 only. On Windows 98 with the very same configuration, or on Linux, everything works fine. Try the following code: w2k/PHP setcookie bug test BEGIN "; ?> END When $test is not set, the cookie "debug" remains set to 1, while when $test is set to any value (including "", an empty string), cookie will be eventually properly set to 3. -- Edit this bug report at http://bugs.php.net/?id=21569&edit=1
#15374 [Com]: include_path loses value when executed
ID: 15374
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: No Feedback
Bug Type: PHP options/info functions
Operating System: Solaris 8
PHP Version: 4.2.1
New Comment:
I am experiencing the same issue with my hosting provider! Plaform is:
* FreeBSD 4.6-STABLE
* Apache/1.3.27 (Unix) FrontPage/5.0.2.2510 mod_ssl/2.8.11
OpenSSL/0.9.6a
* PHP 4.2.3
I have to do the ini_set('include_path', ini_get('include_path'));
trick to pick up any PEAR classes.
It seems, however, that if I set the include_path in an .htaccess
directive, the problem completely goes away...
If I can help diagnose this, I'd be happy to.
Patrick
Previous Comments:
[2002-09-11 01:00:02] [EMAIL PROTECTED]
No feedback was provided for this bug for over a month, 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-08-10 09:37:23] [EMAIL PROTECTED]
Any chance you can try the non-stable, development branch of this?
[2002-08-08 14:34:48] [EMAIL PROTECTED]
php4-STABLE-latest.tar.gz > 08-Aug-2002 09:02 3.3M
still appears that the include_path value doesn't get dropped, but it
also doesn't get used.
[2002-08-08 09:16:18] [EMAIL PROTECTED]
here is more information on that snapshot we installed; in particular
the requirement of absolute paths. it seems to not drop the
'include_path' information - which is good, but it also doesn't seem to
use the value either.
Warning: main("Class.php") - No such file or directory in
/usr/local/http-data/htdocs/foo/foo.php on line 2
Fatal error: Failed opening required 'Class.php'
(include_path='.:/usr/local/lib/php') in
/usr/local/http-data/htdocs/foo/foo.php on line 2
[2002-07-19 15:51:25] [EMAIL PROTECTED]
that snapshot seems to require absolute pathnames, or atleast rejust
relative paths?
i haven't noticed a warning being generated. but this is on our
non-production and "less stressed" test web server.
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/15374
--
Edit this bug report at http://bugs.php.net/?id=15374&edit=1
#21552 [Opn->Bgs]: re2c: command not found
ID: 21552 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Compile Failure Operating System: Solaris 2.8 PHP Version: 4.3.0 New Comment: bugs in 3rd party tools are not bugs in PHP. Bogus. Previous Comments: [2003-01-10 09:02:58] [EMAIL PROTECTED] Wez- On the solaris box I am using: $ tar --version tar (GNU tar) 1.13 On the linux box: erik@oslo:~$ tar --version tar (GNU tar) 1.13.25 Interestingly enough, my dates matched each other perfectly even though they were different than yours. I wonder why they are different? Also, the problem I found (with my stem script that clobbers the dates) doesn't necessarily explain the problem that [EMAIL PROTECTED] was having, though it seems likely that it is date related. Perhaps this should still be open. [2003-01-10 08:55:59] [EMAIL PROTECTED] The problem was with a piece of software we use here to manage our source tree, called stem. Stem takes as input a directory of source files (such as php-4.3.0) and copies them into our main source directory, then makes a nest of symlinks to support building with different object directories for different platforms. The problem was that stem clobbers the file dates when it copies the files. When the dates aren't perfect make tries to call re2c and dies. Apoligies for causing a ruckus with this bug which is the fault of one of our scripts. Installation / compiling would, however, be somewhat more robust if dates weren't critical to the success of make. Perhaps by changing the makefile to never compile .re files in release distributions, or moving the .re files to an 'original source' directory that isn't operated on by make. This problem could crop up not just with my script but potentially with anyone who moves the files around before compiling and manages to clobber the dates. thanks to all who provided help / comments. [2003-01-10 08:48:29] [EMAIL PROTECTED] And for completeness: -rw-r--r-- andrei/andrei 16718 2002-12-27 04:51 php-4.3.0/ext/standard/var_unserializer.c -rw-r--r-- andrei/andrei 8276 2002-08-19 20:45 php-4.3.0/ext/standard/var_unserializer.re [2003-01-10 08:47:04] [EMAIL PROTECTED] tar tvf php-4.3.0.tar | grep url_scanner_ex -rw-r--r-- andrei/andrei 26762 2002-12-27 04:51 php-4.3.0/ext/standard/url_scanner_ex.c -rw-r--r-- andrei/andrei 12566 2002-09-30 05:56 php-4.3.0/ext/standard/url_scanner_ex.re Are you using GNU tar or Solaris tar? Because it sounds like your tar tool is at fault. [2003-01-10 08:35:35] [EMAIL PROTECTED] directory info from freshly un-tarred downloads from the official website, no other changes made or commands issued. The dates on solaris and linux are the same. The dates on the .c files are later than on the .re files. On Solaris: $ pwd /tmp/erik_tmp/php-4.3.0/ext/standard $ ls -l *.re -rw- ed2019 staff 12566 Sep 30 00:56 url_scanner_ex.re -rw- ed2019 staff 8276 Aug 19 15:45 var_unserializer.re $ ls -l url_scanner.c; ls -l url_scanner_ex.c; ls -l var_unserializer.c -rw- ed2019 staff 8279 Aug 28 02:13 url_scanner.c -rw- ed2019 staff 26762 Dec 26 23:51 url_scanner_ex.c -rw- ed2019 staff 16718 Dec 26 23:51 var_unserializer.c On Linux (debian): erik@oslo:~/phptemp/php-4.3.0/ext/standard$ -rw-r--r-- erik erik 12566 Sep 30 00:56 url_scanner_ex.re -rw-r--r-- erik erik 8276 Aug 19 15:45 var_unserializer.re erik@oslo:~/phptemp/php-4.3.0/ext/standard$ ls -l url_scanner.c; ls -l url_scanner_ex.c; ls -l var_unserializer.c -rw-r--r-- 1 erik erik 8279 Aug 28 02:13 url_scanner.c -rw-r--r-- 1 erik erik 26762 Dec 26 23:51 url_scanner_ex.c -rw-r--r-- 1 erik erik 16718 Dec 26 23:51 var_unserializer.c using: $ make -v GNU Make version 3.79.1, by Richard Stallman and Roland McGrath. Built for sparc-sun-solaris2.8 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/21552 -- Edit this bug report at http://bugs.php.net/?id=21552&edit=1
#21569 [NEW]: PHP can't set cookies after a test with an unset variable
From: [EMAIL PROTECTED] Operating system: Windows 2000 only PHP version: 4.3.0 PHP Bug Type: Unknown/Other Function Bug description: PHP can't set cookies after a test with an unset variable PHP can't set cookies on Windows 2000 systems after testing a non-existing variable. This problem was reported in the following conditions: - Windows 2000 server SP-3 (IIS not installed) - Apache v2.0.43 (confirmed on Apache v1.3.27 as well) - PHP 4.3.0 (confirmed on 4.2.2 and 4.2.3 as well) The problem happens with Windows 2000 only. On Windows 98 with the very same configuration, or on Linux, everything works fine. Try the following code: w2k/PHP setcookie bug test BEGIN "; ?> END When $test is not set, the cookie "debug" remains set to 1, while when $test is set to any value (including "", an empty string), cookie will be eventually properly set to 3. -- Edit bug report at http://bugs.php.net/?id=21569&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21569&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21569&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21569&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21569&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21569&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21569&r=support Expected behavior: http://bugs.php.net/fix.php?id=21569&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21569&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21569&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21569&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21569&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21569&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21569&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21569&r=gnused
#21477 [Opn->Bgs]: $node->dump_node($node) crashes with libxml2-2.4.30
ID: 21477 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: DOM XML related Operating System: linux; kernel 2.4.18 PHP Version: 4.3.0 New Comment: You're not in position to decide what is bogus and what is not. This is bogus. Previous Comments: [2003-01-10 12:50:17] [EMAIL PROTECTED] Thanks for identifying the problem, chregu. But your comment didn't specify WHICH $root in the sample code was causing the problem. Here's an example: hi eot; $doc = domxml_open_mem($xml); $root=$doc->document_element(); //This won't work: //$nodeDump =$doc->dump_node($doc); //This crashes: //$nodeDump =$root->dump_node($root); //This works: $nodeDump =$doc->dump_node($root); echo htmlentities($nodeDump); ?> I have re-opened the bug for integrity of the bug database: a bug is not 'Bogus' if PHP crashes due to scripting errors. For the sake of others who get bitten, this should stay open until fixed, then set it to 'Closed'. [2003-01-10 11:56:45] [EMAIL PROTECTED] The error is here: $nodeContent =$root->dump_node($root); $root has to be a DOM_DOCUMENT and in your case it's DOM_ELEMENT. I'll fix the code, so it will throw an error, if it's not a DOM_DOCUMENT chregu [2003-01-10 04:44:37] [EMAIL PROTECTED] modified bug title to be more specific [2003-01-10 00:35:58] [EMAIL PROTECTED] Re-opening this bug. I'd be happy to work on it if some dom xml developers could give me a start. [2003-01-10 00:34:31] [EMAIL PROTECTED] It almost certainly is a PHP bug, according to Daniel Veillard, author of libxml2. It is an incompatibility with libxml2 version libxml2-2.4.30 or better, maybe earlier too. Ilia only tested with libxml2-2.4.25. Daniel has analyzed the backtrace, which follows, with comments: > Here is some more gdb output that might help. > > (gdb) info stack > #0 xmlStrEqual (str1=0x3 , > str2=0x401632e0 "-//W3C//DTD XHTML 1.0 Strict//EN") at parser.c:1293 > #1 0x4010d834 in xmlIsXHTML (systemID=0x4015e9c0 "text", > publicID=0x3 ) at tree.c:6728 > #2 0x4010d586 in xmlNodeDumpOutput (buf=0x81eadf8, doc=0x81f78a8, > cur=0x81f78a8, level=0, format=0, encoding=0x0) at tree.c:6599 > #3 0x4010cc72 in xmlNodeDump (buf=0x81eeaa0, doc=0x81f78a8, cur=0x81f78a8, > level=0, format=0) at tree.c:6164 > #4 0x080706ab in zif_domxml_dump_node (ht=1, return_value=0x81f584c, > this_ptr=0x81f3104, return_value_used=1) > at > /home/greg/new/php4-STABLE-200301070230/ext/domxml/php_domxml.c:3697 #5 > 0x0815576f in execute (op_array=0x81f27ac) > at /home/greg/new/php4-STABLE-200301070230/Zend/zend_execute.c:1596 > #6 0x08145756 in zend_execute_scripts (type=8, retval=0x0, file_count=3) > at /home/greg/new/php4-STABLE-200301070230/Zend/zend.c:864 > #7 0x08115afd in php_execute_script (primary_file=0xb880) > at /home/greg/new/php4-STABLE-200301070230/main/main.c:1573 > #8 0x0815b134 in main (argc=3, argv=0xb924) > at /home/greg/new/php4-STABLE-200301070230/sapi/cli/php_cli.c:746 > #9 0x401a0507 in __libc_start_main (main=0x815a83c , argc=3, > ubp_av=0xb924, init=0x8061588 <_init>, fini=0x815b7d0 <_fini>, > rtld_fini=0x4000dc14 <_dl_fini>, stack_end=0xb91c) > at ../sysdeps/generic/libc-start.c:129 > (gdb) > > Daniel said: The DTD node for the document was not properly initialized. The call made by xmlNodeDumpOutput is : is_xhtml = xmlIsXHTML(dtd->SystemID, dtd->ExternalID); the DTD is looked for based on the document passed to xmlNodeDumpOutput(). And the pointer stored in the DTD for the system ID is invalid. Go back to the PHP maintainer and ask him to fix the code making that xmlDtdPtr node. That DTD node was not generated by libxml2 as part of the parsed document since there is NO DOCTYPE entries in the parsed examples. I have no idea what the PHP code looks like but getting an invalid DTD node for a document which did not contained any initially doesn't give me a good opinion of that code quality honnestly. I have no idea of what's going on there, but this doesn't sound good, really. Daniel On Wed, Jan 08, 2003 at 10:42:54AM -0800, gk wrote: > I don't understand why, if this is a PHP issue, the bug is not reproducible > with the same version of PHP and different versions of libxml2. I will go > back to the same version of libxml2 that Ilia tested with and see if I can > reproduce it on m
#21477 [Bgs->Opn]: $node->dump_node($node) crashes with libxml2-2.4.30
ID: 21477 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open Bug Type: DOM XML related Operating System: linux; kernel 2.4.18 PHP Version: 4.3.0 New Comment: Thanks for identifying the problem, chregu. But your comment didn't specify WHICH $root in the sample code was causing the problem. Here's an example: hi eot; $doc = domxml_open_mem($xml); $root=$doc->document_element(); //This won't work: //$nodeDump =$doc->dump_node($doc); //This crashes: //$nodeDump =$root->dump_node($root); //This works: $nodeDump =$doc->dump_node($root); echo htmlentities($nodeDump); ?> I have re-opened the bug for integrity of the bug database: a bug is not 'Bogus' if PHP crashes due to scripting errors. For the sake of others who get bitten, this should stay open until fixed, then set it to 'Closed'. Previous Comments: [2003-01-10 11:56:45] [EMAIL PROTECTED] The error is here: $nodeContent =$root->dump_node($root); $root has to be a DOM_DOCUMENT and in your case it's DOM_ELEMENT. I'll fix the code, so it will throw an error, if it's not a DOM_DOCUMENT chregu [2003-01-10 04:44:37] [EMAIL PROTECTED] modified bug title to be more specific [2003-01-10 00:35:58] [EMAIL PROTECTED] Re-opening this bug. I'd be happy to work on it if some dom xml developers could give me a start. [2003-01-10 00:34:31] [EMAIL PROTECTED] It almost certainly is a PHP bug, according to Daniel Veillard, author of libxml2. It is an incompatibility with libxml2 version libxml2-2.4.30 or better, maybe earlier too. Ilia only tested with libxml2-2.4.25. Daniel has analyzed the backtrace, which follows, with comments: > Here is some more gdb output that might help. > > (gdb) info stack > #0 xmlStrEqual (str1=0x3 , > str2=0x401632e0 "-//W3C//DTD XHTML 1.0 Strict//EN") at parser.c:1293 > #1 0x4010d834 in xmlIsXHTML (systemID=0x4015e9c0 "text", > publicID=0x3 ) at tree.c:6728 > #2 0x4010d586 in xmlNodeDumpOutput (buf=0x81eadf8, doc=0x81f78a8, > cur=0x81f78a8, level=0, format=0, encoding=0x0) at tree.c:6599 > #3 0x4010cc72 in xmlNodeDump (buf=0x81eeaa0, doc=0x81f78a8, cur=0x81f78a8, > level=0, format=0) at tree.c:6164 > #4 0x080706ab in zif_domxml_dump_node (ht=1, return_value=0x81f584c, > this_ptr=0x81f3104, return_value_used=1) > at > /home/greg/new/php4-STABLE-200301070230/ext/domxml/php_domxml.c:3697 #5 > 0x0815576f in execute (op_array=0x81f27ac) > at /home/greg/new/php4-STABLE-200301070230/Zend/zend_execute.c:1596 > #6 0x08145756 in zend_execute_scripts (type=8, retval=0x0, file_count=3) > at /home/greg/new/php4-STABLE-200301070230/Zend/zend.c:864 > #7 0x08115afd in php_execute_script (primary_file=0xb880) > at /home/greg/new/php4-STABLE-200301070230/main/main.c:1573 > #8 0x0815b134 in main (argc=3, argv=0xb924) > at /home/greg/new/php4-STABLE-200301070230/sapi/cli/php_cli.c:746 > #9 0x401a0507 in __libc_start_main (main=0x815a83c , argc=3, > ubp_av=0xb924, init=0x8061588 <_init>, fini=0x815b7d0 <_fini>, > rtld_fini=0x4000dc14 <_dl_fini>, stack_end=0xb91c) > at ../sysdeps/generic/libc-start.c:129 > (gdb) > > Daniel said: The DTD node for the document was not properly initialized. The call made by xmlNodeDumpOutput is : is_xhtml = xmlIsXHTML(dtd->SystemID, dtd->ExternalID); the DTD is looked for based on the document passed to xmlNodeDumpOutput(). And the pointer stored in the DTD for the system ID is invalid. Go back to the PHP maintainer and ask him to fix the code making that xmlDtdPtr node. That DTD node was not generated by libxml2 as part of the parsed document since there is NO DOCTYPE entries in the parsed examples. I have no idea what the PHP code looks like but getting an invalid DTD node for a document which did not contained any initially doesn't give me a good opinion of that code quality honnestly. I have no idea of what's going on there, but this doesn't sound good, really. Daniel On Wed, Jan 08, 2003 at 10:42:54AM -0800, gk wrote: > I don't understand why, if this is a PHP issue, the bug is not reproducible > with the same version of PHP and different versions of libxml2. I will go > back to the same version of libxml2 that Ilia tested with and see if I can > reproduce it on my machine, with same PHP and sample code. I'm very sorry, but I do not have the time to fix the PHP code. Your documents from your example did NOT have any DOCTYPE. The doc xmlDocPtr passed
#21568 [Opn->Fbk]: The memory could not be "read".
ID: 21568 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Apache related Operating System: Windows 2000 SP3 PHP Version: 4.3.0 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-01-10 09:53:34] [EMAIL PROTECTED] I have Windows 2000 SP3 & Apache 1.3.27. When I starting php.exe without starting Apache or Apache without PHP (as additional module) they both working properly. BUT when I starting Apache with PHP (as additional module) : Apache.exe - application error The instruction at "0x012110c3" referenced memory at "0x". The memory could not be "read". Click on OK to terminate the program. HELP ME PLEASE! My life without PHP - isn't normally life. Devils_advocatE, mailto: [EMAIL PROTECTED] -- Edit this bug report at http://bugs.php.net/?id=21568&edit=1
#19201 [Com]: htmlspecialchars, et al crashes when called with quote_style
ID: 19201 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Reproducible crash Operating System: Digital Unix 4.0G PHP Version: 4.2.2 New Comment: % gcc -v Reading specs from /usr/local/lib/gcc-lib/alphaev56-dec-osf4.0g/3.2/specs Configured with: ../gcc-3.2/configure Thread model: single gcc version 3.2 Previous Comments: [2003-01-10 12:23:44] [EMAIL PROTECTED] Which compiler (and version) did you use to build the PHP binary? Some old compilers may produce bogus codes that cause unaligned access. [2003-01-10 10:48:48] [EMAIL PROTECTED] Still crashes with PHP 4.3.0. I do not have a license for dbx so I can't provide a backtrace, but running the example above from the command line against the cgi binary produces the following: Unaligned access pid=25896 va=0x1400c4cec pc=0x120244758 ra=0x1200bda78 inst=0xb429 Unaligned access pid=25896 va=0x11fffdb7c pc=0x120236d64 ra=0x120237408 inst=0xb42c Segmentation fault [2002-09-23 08:09:20] [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. [2002-08-30 13:18:04] [EMAIL PROTECTED] Forgot to say that I can not reproduce this with php 4.2.0-dev (march 7) or php 4.3.0-dev (august 25). They both show this result: &"'<> [2002-08-30 13:15:55] [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/19201 -- Edit this bug report at http://bugs.php.net/?id=19201&edit=1
#16676 [Com]: ob_implicit_flush not turning off ob
ID: 16676 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Won\'t fix Bug Type: Output Control Operating System: Slackware 8.0 PHP Version: 4.2.0 New Comment: Now I'm getting a PHP notice in Windows XP using PHP 4.3.0 from the cmd line. PHP Notice: ob_end_flush() [ref.outcontrol]: failed to delete buffer default output handler. in C:\Apache\cgi-bin\mybot.php on line 58 In previous versions, ob_end_flush was my workaround to ob_implicit_flush not working. In 4.3.0 ob_end_flush isn't working for me and it does work in 4.2.3. Could someone make at least one of the two work again instead of keeping the "Won't fix" status? Previous Comments: [2002-12-27 08:35:57] [EMAIL PROTECTED] Should have been won't fix [2002-12-27 08:16:53] [EMAIL PROTECTED] It is easy to make it actually flush output. Difficult part is make it work always. Some output buffers shouldn't be deleted and cannot be deleted. i.e. Some browsers will freeze if server send malformed compressed output. Thus ob_end_flush() wouldn't and shouldn't work in some cases. If it works, it's a bug should be fixed. Fix is simple, but you have to live with that. If you are interested, search php-dev archive. BTW, ob_implicit_flush() simply enable SAPI level auto flushing even if its name imply PHP output buffer flushing. Don't blame me, I'm for fixing it ;) [2002-12-24 21:39:37] [EMAIL PROTECTED] You can solve your problem by putting @ob_end_flush(); on top of your command line scripts. [2002-12-24 16:25:58] [EMAIL PROTECTED] iliaa, I appreciate you trying to point me to help, but I still think I'm right about this bug report. I've tried it on several machines with each stable version of PHP since the report. Now still with 4.2.3 I'm seeing the same thing. Again, I'm not using zlib output compression cause I let mod_gzip do that in apache. This is for a php shell script. As you said, flush would send the output, but according to the documentation, ob_implicit_flush() should "result in a flush operation after every output call, so that explicit calls to flush() will no longer be needed". I'm saying ob_implicit_flush is broken in 4.2.x and does not call flush() after each echo, or if it does, it's still not outputting to STDOUT. By default, php.ini has 4k of output buffering. I want to leave that for the rest of the applications I'm running and since you can't modify the ini value with ini_set(), I'm resorting to the ob_* functions. Instead of calling ob_end_flush() at the start of the script cause according to the docs on that, as part of its functionality, it turns off ob. Either way, I'm getting output buffering turned off while leaving 4k buffering in php.ini, but I doesn't mean that ob_implicit_flush() might still be not working right. I guess I'll just wait a few more days for 4.3.0 and try that out. [2002-09-26 16:47:23] [EMAIL PROTECTED] Sorry, but the bug system is not the appropriate forum for asking support questions. 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 Thank you for your interest in PHP. if you are not using ob and do not have gzip compression enabled, then by simply doing flush(); you'll get the data your are outputing sent to screen without any output buffering. 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/16676 -- Edit this bug report at http://bugs.php.net/?id=16676&edit=1
#19201 [NoF->Fbk]: htmlspecialchars, et al crashes when called with quote_style
ID: 19201 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: No Feedback +Status: Feedback Bug Type: Reproducible crash Operating System: Digital Unix 4.0G PHP Version: 4.2.2 Previous Comments: [2003-01-10 12:23:44] [EMAIL PROTECTED] Which compiler (and version) did you use to build the PHP binary? Some old compilers may produce bogus codes that cause unaligned access. [2003-01-10 10:48:48] [EMAIL PROTECTED] Still crashes with PHP 4.3.0. I do not have a license for dbx so I can't provide a backtrace, but running the example above from the command line against the cgi binary produces the following: Unaligned access pid=25896 va=0x1400c4cec pc=0x120244758 ra=0x1200bda78 inst=0xb429 Unaligned access pid=25896 va=0x11fffdb7c pc=0x120236d64 ra=0x120237408 inst=0xb42c Segmentation fault [2002-09-23 08:09:20] [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. [2002-08-30 13:18:04] [EMAIL PROTECTED] Forgot to say that I can not reproduce this with php 4.2.0-dev (march 7) or php 4.3.0-dev (august 25). They both show this result: &"'<> [2002-08-30 13:15:55] [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/19201 -- Edit this bug report at http://bugs.php.net/?id=19201&edit=1
#19201 [NoF]: htmlspecialchars, et al crashes when called with quote_style
ID: 19201 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: No Feedback Bug Type: Reproducible crash Operating System: Digital Unix 4.0G PHP Version: 4.2.2 New Comment: Which compiler (and version) did you use to build the PHP binary? Some old compilers may produce bogus codes that cause unaligned access. Previous Comments: [2003-01-10 10:48:48] [EMAIL PROTECTED] Still crashes with PHP 4.3.0. I do not have a license for dbx so I can't provide a backtrace, but running the example above from the command line against the cgi binary produces the following: Unaligned access pid=25896 va=0x1400c4cec pc=0x120244758 ra=0x1200bda78 inst=0xb429 Unaligned access pid=25896 va=0x11fffdb7c pc=0x120236d64 ra=0x120237408 inst=0xb42c Segmentation fault [2002-09-23 08:09:20] [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. [2002-08-30 13:18:04] [EMAIL PROTECTED] Forgot to say that I can not reproduce this with php 4.2.0-dev (march 7) or php 4.3.0-dev (august 25). They both show this result: &"'<> [2002-08-30 13:15:55] [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-08-30 13:09:37] [EMAIL PROTECTED] The htmlspecialchars and htmlentities functions crash php(typical "document contains no data" error) when called with the second parameter, quote_style (ENT_COMPAT, ENT_QUOTES, ENT_NOQUOTES). If called without the second parameter, these functions return the expected results. May be related to Bug #18048. Sample Script: "; $temp = htmlspecialchars($string,ENT_QUOTES); echo $temp; ?> Configuration Command: '--with-apache=/usr/src/apache_1.3.26' '--with-mysql' '--with-gd=/usr/local' '--with-freetype-dir=/usr/local' '--with-t1lib=/usr/local' '--with-jpeg-dir=/usr/local' '--with-png-dir=/usr/local' '--with-pdflib=/usr/local' '--with-openssl=/usr/local/ssl' '--with-zlib-dir=/usr/local' '--with-java=/usr/opt/java131' '--with-ldap=/usr/local' '--with-imap=/usr/local/lib' '--with-mcrypt=/usr/local/lib/libmcrypt' '--enable-track-vars' '--enable-ftp' '--enable-sockets' '--enable-trans-sid' -- Edit this bug report at http://bugs.php.net/?id=19201&edit=1
#21477 [Opn->Bgs]: $node->dump_node($node) crashes with libxml2-2.4.30
ID: 21477 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: DOM XML related Operating System: linux; kernel 2.4.18 PHP Version: 4.3.0 New Comment: The error is here: $nodeContent =$root->dump_node($root); $root has to be a DOM_DOCUMENT and in your case it's DOM_ELEMENT. I'll fix the code, so it will throw an error, if it's not a DOM_DOCUMENT chregu Previous Comments: [2003-01-10 04:44:37] [EMAIL PROTECTED] modified bug title to be more specific [2003-01-10 00:35:58] [EMAIL PROTECTED] Re-opening this bug. I'd be happy to work on it if some dom xml developers could give me a start. [2003-01-10 00:34:31] [EMAIL PROTECTED] It almost certainly is a PHP bug, according to Daniel Veillard, author of libxml2. It is an incompatibility with libxml2 version libxml2-2.4.30 or better, maybe earlier too. Ilia only tested with libxml2-2.4.25. Daniel has analyzed the backtrace, which follows, with comments: > Here is some more gdb output that might help. > > (gdb) info stack > #0 xmlStrEqual (str1=0x3 , > str2=0x401632e0 "-//W3C//DTD XHTML 1.0 Strict//EN") at parser.c:1293 > #1 0x4010d834 in xmlIsXHTML (systemID=0x4015e9c0 "text", > publicID=0x3 ) at tree.c:6728 > #2 0x4010d586 in xmlNodeDumpOutput (buf=0x81eadf8, doc=0x81f78a8, > cur=0x81f78a8, level=0, format=0, encoding=0x0) at tree.c:6599 > #3 0x4010cc72 in xmlNodeDump (buf=0x81eeaa0, doc=0x81f78a8, cur=0x81f78a8, > level=0, format=0) at tree.c:6164 > #4 0x080706ab in zif_domxml_dump_node (ht=1, return_value=0x81f584c, > this_ptr=0x81f3104, return_value_used=1) > at > /home/greg/new/php4-STABLE-200301070230/ext/domxml/php_domxml.c:3697 #5 > 0x0815576f in execute (op_array=0x81f27ac) > at /home/greg/new/php4-STABLE-200301070230/Zend/zend_execute.c:1596 > #6 0x08145756 in zend_execute_scripts (type=8, retval=0x0, file_count=3) > at /home/greg/new/php4-STABLE-200301070230/Zend/zend.c:864 > #7 0x08115afd in php_execute_script (primary_file=0xb880) > at /home/greg/new/php4-STABLE-200301070230/main/main.c:1573 > #8 0x0815b134 in main (argc=3, argv=0xb924) > at /home/greg/new/php4-STABLE-200301070230/sapi/cli/php_cli.c:746 > #9 0x401a0507 in __libc_start_main (main=0x815a83c , argc=3, > ubp_av=0xb924, init=0x8061588 <_init>, fini=0x815b7d0 <_fini>, > rtld_fini=0x4000dc14 <_dl_fini>, stack_end=0xb91c) > at ../sysdeps/generic/libc-start.c:129 > (gdb) > > Daniel said: The DTD node for the document was not properly initialized. The call made by xmlNodeDumpOutput is : is_xhtml = xmlIsXHTML(dtd->SystemID, dtd->ExternalID); the DTD is looked for based on the document passed to xmlNodeDumpOutput(). And the pointer stored in the DTD for the system ID is invalid. Go back to the PHP maintainer and ask him to fix the code making that xmlDtdPtr node. That DTD node was not generated by libxml2 as part of the parsed document since there is NO DOCTYPE entries in the parsed examples. I have no idea what the PHP code looks like but getting an invalid DTD node for a document which did not contained any initially doesn't give me a good opinion of that code quality honnestly. I have no idea of what's going on there, but this doesn't sound good, really. Daniel On Wed, Jan 08, 2003 at 10:42:54AM -0800, gk wrote: > I don't understand why, if this is a PHP issue, the bug is not reproducible > with the same version of PHP and different versions of libxml2. I will go > back to the same version of libxml2 that Ilia tested with and see if I can > reproduce it on my machine, with same PHP and sample code. I'm very sorry, but I do not have the time to fix the PHP code. Your documents from your example did NOT have any DOCTYPE. The doc xmlDocPtr passed to the serialization routine had an xmlDtdNode. That xmlDtdNode will NOT be generated by libxml2 (any version) when passing the sample examples your provided within your PHP. Moreover that xmlDtdNode is buggy because one of the pointers is 0x3 which leads to the crash. I don't have the time to find in the PHP code - what code generated that xmlDtdNode. - why it has buggy pointers - why it's passed to the serialization routine while obviously the document asked for serialization should NOT have an xmlDtdNode Again I can't debug this. This sounds completely broken to stay polite. The fact that the bug doesn't show up with other versions is simply that earlier version don't have the XHTML1 detection code looking for the DTD System ID in order to adjust the serializations accordingly. Daniel -
#21230 [Com]: Refresh Problem
ID: 21230
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Apache2 related
Operating System: Windows 2000 Server
PHP Version: 4.3.0
New Comment:
phpBB has seen this issue, but points the finger back at php instead.
It looks like ie caches the php files in temporary internet files.
Setting your temp int files to only cache 1MB is the only work around I
have found so far.
I found a bit of code that forces the browser not to cache the php
files, but I have yet to get it to work.
header("Cache-Control: post-check=0, pre-check=0", false);
header("Pragma: no-cache");
header("Expires: Mon, 26 Jul 1997 05:00:00 GMT");
/* Date in the past*/
header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT");
/* always modified*/
header("Cache-Control: no-cache, no-store, must-revalidate");
/* HTTP/1.1 */read
Anywho, here is the snip from phpBB.
- Posted by adrien at 8:27 AM on 11-26-2002 -
when "refreshing" a page css gets printed on page using ie. i thought
this was a problem with my site only, but also phpbb.com is
experiencing it!!
- Posted by psoTFX at 7:43 AM on 11-27-2002 -
This happens randomly for most, we've never been able to track down
where the problem may be coming from ... some have suggested it's the
browser, others the server, others phpBB ... given it's lack of
repeatability I'm afraid there isn't much we can do. It may be another
bug is causing this and thus fixing it will solve the problem ...
otherwise ... we welcome information on how to replicate the problem
consistently
- Posted by adrien at 12:37 AM on 12-20-2002 -
Not sure if this helps, but this problem occours to me even when using
the back button in phpmyadmin 2.3.0 and only when using IE, opera,
mozilla and netscape seem immune to this on win2k.
hope this helps
adrien
- Posted by psoTFX at 5:29 AM on 12-20-2002 -
This would therefore seem to indicate it's a "browser" problem given
it's existence on something other than phpBB.
- Posted by adrien at 5:32 AM on 12-20-2002 -
yes, my thoughts as well
Previous Comments:
[2002-12-27 22:10:25] [EMAIL PROTECTED]
This sounds like a question for the phpbb guys. And by the way,
Apache2+PHP is still very much experimental. I would suggest going
back to Apache 1.3.
[2002-12-27 21:40:32] [EMAIL PROTECTED]
I have been using PHP for a phpbb forum. Until recently i have been
using apache 1.3 with version 4.23 of PHP, which has been working fine,
but today I upgraded to Apache 2 with version 4.30 of PHP, and have
experienced some problems, although the forum actually works, it has
trouble refreshing, for example when i post a message it accepts that
i've posted the message, but however when i return to the forum, the
message has not appeared. Even clicking refresh on my browser does not
work, The only way to refresh the page is to delete my history and
offline files, and then press refresh again. I do not think this is a
problem with the forum itself as I have not touched any of the files
since I have upgraded.
--
Edit this bug report at http://bugs.php.net/?id=21230&edit=1
#6566 [Com]: Function default argmnt. doesn't accept variable
ID: 6566 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Variables related Operating System: Redhat Linux 6.2 PHP Version: 4.0.2 New Comment: Still apparant in PHP 4.2.3 and 4.3.0 As stated this behaviour is documented and will not change. Why is this? Would Incompatibility with PHP3, being it only the minority of PHP servers are still running PHP3, be the issue? Previous Comments: [2000-09-05 23:51:21] [EMAIL PROTECTED] Forgot to close. [2000-09-05 23:50:25] [EMAIL PROTECTED] Documented incompatibility between PHP3 & PHP4, probably will not change. [2000-09-05 23:31:13] [EMAIL PROTECTED] Default function argument doesn't accept variable. function echoname ($name = 'bob') works fine but $bob = 'bob'; function echoname ($name = $bob) will produce error. I'm not sure either this is a bug or limitation but I guess its useful if variable is allowed as default function argument. regards, amri [2000-09-05 23:28:42] [EMAIL PROTECTED] Default function argument doesn't accept variable. function echoname ($name = 'bob') works fine but $him = 'bob'; function echoname ($name = $bob) will produce error. I'm not sure either this is a bug or limitation but I guess its useful if variable is allowed as default function argument. regards, amri -- Edit this bug report at http://bugs.php.net/?id=6566&edit=1
#17958 [Com]: loses $_POST vars
ID: 17958 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Apache2 related Operating System: Linux 2.4.18 PHP Version: 4.2.3 New Comment: I'm sorry, the bug still appears with PHP 4.3.0. --- System Windows NT localhost 5.1 build 2600 Build Date Dec 27 2002 05:28:00 PHP API 20020918 PHP Extension 20020429 Zend Extension 20021010 Apache Version Apache/1.3.24 Apache Release 10324100 Apache API Version 19990320 SERVER_SOFTWARE Apache/1.3.23 (Win32) PHP/4.3.0 mod_gzip/1.3.19.1a mod_ssl/2.8.6 OpenSSL/0.9.6c User-Agent Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Q312461; .NET CLR 1.0.3705) --- It doesn't matter if I use Mozilla instead. Previous Comments: [2002-12-29 05:03:53] [EMAIL PROTECTED] Thank you for your bug report. This issue has already been fixed in the latest released version of PHP, which you can download at http://www.php.net/downloads.php [2002-12-28 19:17:07] [EMAIL PROTECTED] When I change in (php.ini) register_globals = On and restart Apache everythings looks to work OK Ps. Sorry - my english is terrible but I want help :) [2002-12-23 12:07:30] [EMAIL PROTECTED] @[EMAIL PROTECTED] No, it doesn't. The problem is that the whole $_POST-Array is empty if the data is submited as multipart/form-data. [2002-12-12 21:27:38] [EMAIL PROTECTED] Use $_FILES to access the the file specs. Use $_POST for all others. -taken from phpinfo()-- $_POST["user"] (gives me) ryan $_FILES["userfile"] (gives me) Array ( [name] => Test.class [type] => application/octet-stream [tmp_name] => /tmp/phpyXUyr7 [error] => 0 [size] => 444 ) PHP Version 4.2.2 Apache/1.3.12 Hope this helps [2002-10-14 19:26:51] [EMAIL PROTECTED] No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/17958 -- Edit this bug report at http://bugs.php.net/?id=17958&edit=1
#15566 [Com]: Application Failed to Initialize Popup Message
ID: 15566 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: IIS related Operating System: Windows 2000 Advanced Server PHP Version: 4.1.1 New Comment: Event Type: Information Event Source: Application Popup Event Category: None Event ID: 26 Date: 1/10/2003 Time: 10:41:28 AM User: N/A Computer: WHITESTAR Description: Application popup: php.exe - Application Error : The instruction at "0x77f83a59" referenced memory at "0x0c84". The memory could not be "read". Click on OK to terminate the program This follows another error message such as this: Event Type: Error Event Source: W3SVC Event Category: None Event ID: 16 Date: 1/10/2003 Time: 10:30:50 AM User: N/A Computer: WHITESTAR Description: The script started from the URL '/phpbb/search.php' with parameters 'search_id=unanswered&sid=a2c4961fcfd33f1008d3abf936cfa284' has not responded within the configured timeout period. The HTTP server is terminating the script. For additional information specific to this message please visit the Microsoft Online Support site located at: http://www.microsoft.com/contentredirect.asp. This did not start happening until I upgraded to PHP 4.2.2 from 4.2.1, I cannot run 4.3 due to incompatibilities of certain software. Previous Comments: [2002-02-15 13:02:29] [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". [2002-02-15 08:26:12] [EMAIL PROTECTED] I get a popup dialog often in Windows 2000 Advanced Server (and on all servers running PHP) using the CGI (not ISAPI) system, the following message: title bar "php.exe - Application Error" Message: The application failed to initialize properly (0xc142). Click on OK to terminate the application. Thank you. Neal Culiner NC Software, Inc. http://www.nc-software.com -- Edit this bug report at http://bugs.php.net/?id=15566&edit=1
#21561 [Bgs]: connection_status() returns 0 even after script times out
ID: 21561
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Unknown/Other Function
Operating System: Red Hat Linux 7.2
PHP Version: 4.3.0
New Comment:
#14542
Previous Comments:
[2003-01-10 00:26:01] [EMAIL PROTECTED]
Ok. Can you tell me bug # what this is a duplicate of so I can track
it? I searched but could find a similar bug.
Thanks!
[2003-01-10 00:19:33] [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.
[2003-01-09 23:33:53] [EMAIL PROTECTED]
The following code times out, PHP throws an error saying the code has
timed out, *but* calling connection_status() says the code did *not*
time out!
connection_status() returns 0 when it should return 2 ...
My code:
set_time_limit(2);
echo "set execution limit to 2 seconds ";
register_shutdown_function("timed_out");
require_once("db_functions/sql_query.inc");
$sql = "BEGIN;";
$res = sql_query($sql);
$sql = "insert into test(test) values('testing 4');";
$res = sql_query($sql);
//This will cause the script to time out
$i = 0;
while(true) {$i++;}
$sql = "COMMIT;";
$res = sql_query($sql);
function timed_out() {
$status = connection_status();
if ($status == 2) {
echo "the script timed out ";
}
else echo "no time out. Connection status is $status ";
}
The OUPUT:
set execution limit to 2 seconds
Fatal error: Maximum execution time of 2 seconds exceeded in
/www/htdocs/jc/shut.php on line 16
no time out. Connection status is 0
--
Edit this bug report at http://bugs.php.net/?id=21561&edit=1
#19201 [Com]: htmlspecialchars, et al crashes when called with quote_style
ID: 19201 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: No Feedback Bug Type: Reproducible crash Operating System: Digital Unix 4.0G PHP Version: 4.2.2 New Comment: Still crashes with PHP 4.3.0. I do not have a license for dbx so I can't provide a backtrace, but running the example above from the command line against the cgi binary produces the following: Unaligned access pid=25896 va=0x1400c4cec pc=0x120244758 ra=0x1200bda78 inst=0xb429 Unaligned access pid=25896 va=0x11fffdb7c pc=0x120236d64 ra=0x120237408 inst=0xb42c Segmentation fault Previous Comments: [2002-09-23 08:09:20] [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. [2002-08-30 13:18:04] [EMAIL PROTECTED] Forgot to say that I can not reproduce this with php 4.2.0-dev (march 7) or php 4.3.0-dev (august 25). They both show this result: &"'<> [2002-08-30 13:15:55] [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-08-30 13:09:37] [EMAIL PROTECTED] The htmlspecialchars and htmlentities functions crash php(typical "document contains no data" error) when called with the second parameter, quote_style (ENT_COMPAT, ENT_QUOTES, ENT_NOQUOTES). If called without the second parameter, these functions return the expected results. May be related to Bug #18048. Sample Script: "; $temp = htmlspecialchars($string,ENT_QUOTES); echo $temp; ?> Configuration Command: '--with-apache=/usr/src/apache_1.3.26' '--with-mysql' '--with-gd=/usr/local' '--with-freetype-dir=/usr/local' '--with-t1lib=/usr/local' '--with-jpeg-dir=/usr/local' '--with-png-dir=/usr/local' '--with-pdflib=/usr/local' '--with-openssl=/usr/local/ssl' '--with-zlib-dir=/usr/local' '--with-java=/usr/opt/java131' '--with-ldap=/usr/local' '--with-imap=/usr/local/lib' '--with-mcrypt=/usr/local/lib/libmcrypt' '--enable-track-vars' '--enable-ftp' '--enable-sockets' '--enable-trans-sid' -- Edit this bug report at http://bugs.php.net/?id=19201&edit=1
#21538 [Opn->Csd]: GTK: ctree insert_node segfaults with too many element in text array
ID: 21538 Updated by: [EMAIL PROTECTED] -Summary: GTK: possible memory leak in ctree insert_node code. Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Reproducible crash Operating System: linux debian PHP Version: 4.3.0 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. change title & fix it. Previous Comments: [2003-01-09 01:44:25] [EMAIL PROTECTED] PHP-GTK 0.5.1 (I dont think anything major changed in this area on 0.5.2) to reproduce try pear install http://devel.akbkhome.com/GTK_VarDump-0.1.tgz the package includes a test file test1.php, just run it with php test1.php it attempts to var_dump globals (dont worry recursion is handled..)... try expanding the globals recursive element a few times, then press the OK button - I get the following segfault... if somebody can reproduce it, it would atleast prove im not mad here :) I tested this on another machine, which had the zend memory lead debugging on (and an earlier dev version of PHP4.3), indicating there was a 4 byte leak in in gtk+.overides in the gtk_ctree_insert_node section at this line.. text = emalloc(sizeof(gchar *) * columns); however couldnt get it to crash :( (gdb) run /usr/share/pear/tests/GTK_VarDump/tests/test1.php Starting program: /usr/bin/php /usr/share/pear/tests/GTK_VarDump/tests/test1.php Program received signal SIGSEGV, Segmentation fault. 0x402a8e5a in free () from /lib/libc.so.6 (gdb) bt #0 0x402a8e5a in free () from /lib/libc.so.6 #1 0x08129ad9 in _efree (ptr=0x8520cf4) at /usr/src/php/php-4.3.0/Zend/zend_alloc.c:235 #2 0x0813d360 in zend_hash_apply_deleter (ht=0x81b5460, p=0x8520cf4) at /usr/src/php/php-4.3.0/Zend/zend_hash.c:633 #3 0x0813d51b in zend_hash_apply_with_argument (ht=0x81b5460, apply_func=0x813e644 , argument=0x8476270) at /usr/src/php/php-4.3.0/Zend/zend_hash.c:708 #4 0x0813e6a8 in zend_clean_module_rsrc_dtors_cb (ld=0x8476258, module_number=0xb320) at /usr/src/php/php-4.3.0/Zend/zend_list.c:249 #5 0x0813d50a in zend_hash_apply_with_argument (ht=0x81b1080, apply_func=0x813e660 , argument=0xb320) at /usr/src/php/php-4.3.0/Zend/zend_hash.c:707 #6 0x0813e6f5 in zend_clean_module_rsrc_dtors (module_number=28) at /usr/src/php/php-4.3.0/Zend/zend_list.c:260 #7 0x0813b6b0 in module_destructor (module=0x823e5f0) at /usr/src/php/php-4.3.0/Zend/zend_API.c:1117 #8 0x0813d2ac in zend_hash_apply_deleter (ht=0x81b5600, p=0x823e5c0) at /usr/src/php/php-4.3.0/Zend/zend_hash.c:598 #9 0x0813d493 in zend_hash_apply (ht=0x81b5600, apply_func=0x813b78c ) at /usr/src/php/php-4.3.0/Zend/zend_hash.c:689 #10 0x08138a40 in zend_deactivate_modules () at /usr/src/php/php-4.3.0/Zend/zend.c:634 #11 0x0810fdcd in php_request_shutdown (dummy=0x0) at /usr/src/php/php-4.3.0/main/main.c:928 #12 0x0815267d in main (argc=2, argv=0xba94) at /usr/src/php/php-4.3.0/sapi/cli/php_cli.c:803 (gdb) -- Edit this bug report at http://bugs.php.net/?id=21538&edit=1
#21568 [NEW]: The memory could not be "read".
From: [EMAIL PROTECTED] Operating system: Windows 2000 SP3 PHP version: 4.3.0 PHP Bug Type: Apache related Bug description: The memory could not be "read". I have Windows 2000 SP3 & Apache 1.3.27. When I starting php.exe without starting Apache or Apache without PHP (as additional module) they both working properly. BUT when I starting Apache with PHP (as additional module) : Apache.exe - application error The instruction at "0x012110c3" referenced memory at "0x". The memory could not be "read". Click on OK to terminate the program. HELP ME PLEASE! My life without PHP - isn't normally life. Devils_advocatE, mailto: [EMAIL PROTECTED] -- Edit bug report at http://bugs.php.net/?id=21568&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21568&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21568&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21568&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21568&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21568&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21568&r=support Expected behavior: http://bugs.php.net/fix.php?id=21568&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21568&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21568&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21568&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21568&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21568&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21568&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21568&r=gnused
#13561 [Asn]: --without-pear prevent install of php-config,phpize,...
ID: 13561 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Assigned Bug Type: *Configuration Issues Operating System: i686-pc-linux-gnu PHP Version: 4.0CVS-2001-10-05 Assigned To: ssb New Comment: Still applies to current CVS and 4.3. Previous Comments: [2002-10-05 06:36:04] [EMAIL PROTECTED] Still applies to current CVS. [2002-06-28 03:52:56] [EMAIL PROTECTED] Let's annoy Stig with the emails too. :) [2002-06-22 10:04:33] [EMAIL PROTECTED] Any news on this? [2001-10-21 02:56:50] [EMAIL PROTECTED] Currently, phpize and php-config are considered part of pear. :-) We'll fix this one in the 4.2.0 release, there's going to be more build system changes there. [2001-10-20 20:05:47] [EMAIL PROTECTED] Confirmed with PHP 4.1.0RC1. These files should be installed always. Assigned to Stig. --Jani 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/13561 -- Edit this bug report at http://bugs.php.net/?id=13561&edit=1
#21552 [Csd->Opn]: re2c: command not found
ID: 21552 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Closed +Status: Open Bug Type: Compile Failure Operating System: Solaris 2.8 PHP Version: 4.3.0 New Comment: Wez- On the solaris box I am using: $ tar --version tar (GNU tar) 1.13 On the linux box: erik@oslo:~$ tar --version tar (GNU tar) 1.13.25 Interestingly enough, my dates matched each other perfectly even though they were different than yours. I wonder why they are different? Also, the problem I found (with my stem script that clobbers the dates) doesn't necessarily explain the problem that [EMAIL PROTECTED] was having, though it seems likely that it is date related. Perhaps this should still be open. Previous Comments: [2003-01-10 08:55:59] [EMAIL PROTECTED] The problem was with a piece of software we use here to manage our source tree, called stem. Stem takes as input a directory of source files (such as php-4.3.0) and copies them into our main source directory, then makes a nest of symlinks to support building with different object directories for different platforms. The problem was that stem clobbers the file dates when it copies the files. When the dates aren't perfect make tries to call re2c and dies. Apoligies for causing a ruckus with this bug which is the fault of one of our scripts. Installation / compiling would, however, be somewhat more robust if dates weren't critical to the success of make. Perhaps by changing the makefile to never compile .re files in release distributions, or moving the .re files to an 'original source' directory that isn't operated on by make. This problem could crop up not just with my script but potentially with anyone who moves the files around before compiling and manages to clobber the dates. thanks to all who provided help / comments. [2003-01-10 08:48:29] [EMAIL PROTECTED] And for completeness: -rw-r--r-- andrei/andrei 16718 2002-12-27 04:51 php-4.3.0/ext/standard/var_unserializer.c -rw-r--r-- andrei/andrei 8276 2002-08-19 20:45 php-4.3.0/ext/standard/var_unserializer.re [2003-01-10 08:47:04] [EMAIL PROTECTED] tar tvf php-4.3.0.tar | grep url_scanner_ex -rw-r--r-- andrei/andrei 26762 2002-12-27 04:51 php-4.3.0/ext/standard/url_scanner_ex.c -rw-r--r-- andrei/andrei 12566 2002-09-30 05:56 php-4.3.0/ext/standard/url_scanner_ex.re Are you using GNU tar or Solaris tar? Because it sounds like your tar tool is at fault. [2003-01-10 08:35:35] [EMAIL PROTECTED] directory info from freshly un-tarred downloads from the official website, no other changes made or commands issued. The dates on solaris and linux are the same. The dates on the .c files are later than on the .re files. On Solaris: $ pwd /tmp/erik_tmp/php-4.3.0/ext/standard $ ls -l *.re -rw- ed2019 staff 12566 Sep 30 00:56 url_scanner_ex.re -rw- ed2019 staff 8276 Aug 19 15:45 var_unserializer.re $ ls -l url_scanner.c; ls -l url_scanner_ex.c; ls -l var_unserializer.c -rw- ed2019 staff 8279 Aug 28 02:13 url_scanner.c -rw- ed2019 staff 26762 Dec 26 23:51 url_scanner_ex.c -rw- ed2019 staff 16718 Dec 26 23:51 var_unserializer.c On Linux (debian): erik@oslo:~/phptemp/php-4.3.0/ext/standard$ -rw-r--r-- erik erik 12566 Sep 30 00:56 url_scanner_ex.re -rw-r--r-- erik erik 8276 Aug 19 15:45 var_unserializer.re erik@oslo:~/phptemp/php-4.3.0/ext/standard$ ls -l url_scanner.c; ls -l url_scanner_ex.c; ls -l var_unserializer.c -rw-r--r-- 1 erik erik 8279 Aug 28 02:13 url_scanner.c -rw-r--r-- 1 erik erik 26762 Dec 26 23:51 url_scanner_ex.c -rw-r--r-- 1 erik erik 16718 Dec 26 23:51 var_unserializer.c using: $ make -v GNU Make version 3.79.1, by Richard Stallman and Roland McGrath. Built for sparc-sun-solaris2.8 [2003-01-10 05:17:42] [EMAIL PROTECTED] Is solaris incorrectly untaring the data stamp on the var_unserializer.c ? or is make file date check failing? the work around would be to touch var_unserializer.c before building.. but try untaring 4.3.0 and look at the date stamp to see if the .c is later than the .re file... 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/21552 -- Edit this bug report at http://bugs.php.net/?id=21552&edit=1
#21552 [Fbk->Csd]: re2c: command not found
ID: 21552 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Closed Bug Type: Compile Failure Operating System: Solaris 2.8 PHP Version: 4.3.0 New Comment: The problem was with a piece of software we use here to manage our source tree, called stem. Stem takes as input a directory of source files (such as php-4.3.0) and copies them into our main source directory, then makes a nest of symlinks to support building with different object directories for different platforms. The problem was that stem clobbers the file dates when it copies the files. When the dates aren't perfect make tries to call re2c and dies. Apoligies for causing a ruckus with this bug which is the fault of one of our scripts. Installation / compiling would, however, be somewhat more robust if dates weren't critical to the success of make. Perhaps by changing the makefile to never compile .re files in release distributions, or moving the .re files to an 'original source' directory that isn't operated on by make. This problem could crop up not just with my script but potentially with anyone who moves the files around before compiling and manages to clobber the dates. thanks to all who provided help / comments. Previous Comments: [2003-01-10 08:48:29] [EMAIL PROTECTED] And for completeness: -rw-r--r-- andrei/andrei 16718 2002-12-27 04:51 php-4.3.0/ext/standard/var_unserializer.c -rw-r--r-- andrei/andrei 8276 2002-08-19 20:45 php-4.3.0/ext/standard/var_unserializer.re [2003-01-10 08:47:04] [EMAIL PROTECTED] tar tvf php-4.3.0.tar | grep url_scanner_ex -rw-r--r-- andrei/andrei 26762 2002-12-27 04:51 php-4.3.0/ext/standard/url_scanner_ex.c -rw-r--r-- andrei/andrei 12566 2002-09-30 05:56 php-4.3.0/ext/standard/url_scanner_ex.re Are you using GNU tar or Solaris tar? Because it sounds like your tar tool is at fault. [2003-01-10 08:35:35] [EMAIL PROTECTED] directory info from freshly un-tarred downloads from the official website, no other changes made or commands issued. The dates on solaris and linux are the same. The dates on the .c files are later than on the .re files. On Solaris: $ pwd /tmp/erik_tmp/php-4.3.0/ext/standard $ ls -l *.re -rw- ed2019 staff 12566 Sep 30 00:56 url_scanner_ex.re -rw- ed2019 staff 8276 Aug 19 15:45 var_unserializer.re $ ls -l url_scanner.c; ls -l url_scanner_ex.c; ls -l var_unserializer.c -rw- ed2019 staff 8279 Aug 28 02:13 url_scanner.c -rw- ed2019 staff 26762 Dec 26 23:51 url_scanner_ex.c -rw- ed2019 staff 16718 Dec 26 23:51 var_unserializer.c On Linux (debian): erik@oslo:~/phptemp/php-4.3.0/ext/standard$ -rw-r--r-- erik erik 12566 Sep 30 00:56 url_scanner_ex.re -rw-r--r-- erik erik 8276 Aug 19 15:45 var_unserializer.re erik@oslo:~/phptemp/php-4.3.0/ext/standard$ ls -l url_scanner.c; ls -l url_scanner_ex.c; ls -l var_unserializer.c -rw-r--r-- 1 erik erik 8279 Aug 28 02:13 url_scanner.c -rw-r--r-- 1 erik erik 26762 Dec 26 23:51 url_scanner_ex.c -rw-r--r-- 1 erik erik 16718 Dec 26 23:51 var_unserializer.c using: $ make -v GNU Make version 3.79.1, by Richard Stallman and Roland McGrath. Built for sparc-sun-solaris2.8 [2003-01-10 05:17:42] [EMAIL PROTECTED] Is solaris incorrectly untaring the data stamp on the var_unserializer.c ? or is make file date check failing? the work around would be to touch var_unserializer.c before building.. but try untaring 4.3.0 and look at the date stamp to see if the .c is later than the .re file... [2003-01-10 00:37:14] [EMAIL PROTECTED] If he did something wrong, then I must have as well because I'm having the exact same problem on a clean copy of PHP 4.3.0, too. Solaris 8, Apache 1.3.x. ./configure --with-apxs=/usr/local/apache/bin/apxs --with- flatfile 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/21552 -- Edit this bug report at http://bugs.php.net/?id=21552&edit=1
#21552 [Fbk]: re2c: command not found
ID: 21552 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Compile Failure Operating System: Solaris 2.8 PHP Version: 4.3.0 New Comment: And for completeness: -rw-r--r-- andrei/andrei 16718 2002-12-27 04:51 php-4.3.0/ext/standard/var_unserializer.c -rw-r--r-- andrei/andrei 8276 2002-08-19 20:45 php-4.3.0/ext/standard/var_unserializer.re Previous Comments: [2003-01-10 08:47:04] [EMAIL PROTECTED] tar tvf php-4.3.0.tar | grep url_scanner_ex -rw-r--r-- andrei/andrei 26762 2002-12-27 04:51 php-4.3.0/ext/standard/url_scanner_ex.c -rw-r--r-- andrei/andrei 12566 2002-09-30 05:56 php-4.3.0/ext/standard/url_scanner_ex.re Are you using GNU tar or Solaris tar? Because it sounds like your tar tool is at fault. [2003-01-10 08:35:35] [EMAIL PROTECTED] directory info from freshly un-tarred downloads from the official website, no other changes made or commands issued. The dates on solaris and linux are the same. The dates on the .c files are later than on the .re files. On Solaris: $ pwd /tmp/erik_tmp/php-4.3.0/ext/standard $ ls -l *.re -rw- ed2019 staff 12566 Sep 30 00:56 url_scanner_ex.re -rw- ed2019 staff 8276 Aug 19 15:45 var_unserializer.re $ ls -l url_scanner.c; ls -l url_scanner_ex.c; ls -l var_unserializer.c -rw- ed2019 staff 8279 Aug 28 02:13 url_scanner.c -rw- ed2019 staff 26762 Dec 26 23:51 url_scanner_ex.c -rw- ed2019 staff 16718 Dec 26 23:51 var_unserializer.c On Linux (debian): erik@oslo:~/phptemp/php-4.3.0/ext/standard$ -rw-r--r-- erik erik 12566 Sep 30 00:56 url_scanner_ex.re -rw-r--r-- erik erik 8276 Aug 19 15:45 var_unserializer.re erik@oslo:~/phptemp/php-4.3.0/ext/standard$ ls -l url_scanner.c; ls -l url_scanner_ex.c; ls -l var_unserializer.c -rw-r--r-- 1 erik erik 8279 Aug 28 02:13 url_scanner.c -rw-r--r-- 1 erik erik 26762 Dec 26 23:51 url_scanner_ex.c -rw-r--r-- 1 erik erik 16718 Dec 26 23:51 var_unserializer.c using: $ make -v GNU Make version 3.79.1, by Richard Stallman and Roland McGrath. Built for sparc-sun-solaris2.8 [2003-01-10 05:17:42] [EMAIL PROTECTED] Is solaris incorrectly untaring the data stamp on the var_unserializer.c ? or is make file date check failing? the work around would be to touch var_unserializer.c before building.. but try untaring 4.3.0 and look at the date stamp to see if the .c is later than the .re file... [2003-01-10 00:37:14] [EMAIL PROTECTED] If he did something wrong, then I must have as well because I'm having the exact same problem on a clean copy of PHP 4.3.0, too. Solaris 8, Apache 1.3.x. ./configure --with-apxs=/usr/local/apache/bin/apxs --with- flatfile [2003-01-09 18:52:57] [EMAIL PROTECTED] re2c is not required (just tested). You've just done something wrong between unpacking the tar archive and 'make' command. 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/21552 -- Edit this bug report at http://bugs.php.net/?id=21552&edit=1
#21552 [Opn->Fbk]: re2c: command not found
ID: 21552 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: Solaris 2.8 PHP Version: 4.3.0 New Comment: tar tvf php-4.3.0.tar | grep url_scanner_ex -rw-r--r-- andrei/andrei 26762 2002-12-27 04:51 php-4.3.0/ext/standard/url_scanner_ex.c -rw-r--r-- andrei/andrei 12566 2002-09-30 05:56 php-4.3.0/ext/standard/url_scanner_ex.re Are you using GNU tar or Solaris tar? Because it sounds like your tar tool is at fault. Previous Comments: [2003-01-10 08:35:35] [EMAIL PROTECTED] directory info from freshly un-tarred downloads from the official website, no other changes made or commands issued. The dates on solaris and linux are the same. The dates on the .c files are later than on the .re files. On Solaris: $ pwd /tmp/erik_tmp/php-4.3.0/ext/standard $ ls -l *.re -rw- ed2019 staff 12566 Sep 30 00:56 url_scanner_ex.re -rw- ed2019 staff 8276 Aug 19 15:45 var_unserializer.re $ ls -l url_scanner.c; ls -l url_scanner_ex.c; ls -l var_unserializer.c -rw- ed2019 staff 8279 Aug 28 02:13 url_scanner.c -rw- ed2019 staff 26762 Dec 26 23:51 url_scanner_ex.c -rw- ed2019 staff 16718 Dec 26 23:51 var_unserializer.c On Linux (debian): erik@oslo:~/phptemp/php-4.3.0/ext/standard$ -rw-r--r-- erik erik 12566 Sep 30 00:56 url_scanner_ex.re -rw-r--r-- erik erik 8276 Aug 19 15:45 var_unserializer.re erik@oslo:~/phptemp/php-4.3.0/ext/standard$ ls -l url_scanner.c; ls -l url_scanner_ex.c; ls -l var_unserializer.c -rw-r--r-- 1 erik erik 8279 Aug 28 02:13 url_scanner.c -rw-r--r-- 1 erik erik 26762 Dec 26 23:51 url_scanner_ex.c -rw-r--r-- 1 erik erik 16718 Dec 26 23:51 var_unserializer.c using: $ make -v GNU Make version 3.79.1, by Richard Stallman and Roland McGrath. Built for sparc-sun-solaris2.8 [2003-01-10 05:17:42] [EMAIL PROTECTED] Is solaris incorrectly untaring the data stamp on the var_unserializer.c ? or is make file date check failing? the work around would be to touch var_unserializer.c before building.. but try untaring 4.3.0 and look at the date stamp to see if the .c is later than the .re file... [2003-01-10 00:37:14] [EMAIL PROTECTED] If he did something wrong, then I must have as well because I'm having the exact same problem on a clean copy of PHP 4.3.0, too. Solaris 8, Apache 1.3.x. ./configure --with-apxs=/usr/local/apache/bin/apxs --with- flatfile [2003-01-09 18:52:57] [EMAIL PROTECTED] re2c is not required (just tested). You've just done something wrong between unpacking the tar archive and 'make' command. [2003-01-09 12:27:32] [EMAIL PROTECTED] After configuring a fresh download of PHP 4.3.0, I attempted to compile with the following configure line: ./configure --with-apxs=/opt/apache1327/bin/apxs --with-mysql Configure complted successfully, and make halted partway through with the following message: re2c -b php-4.3.0/ext/standard/var_unserializer.re > php-4.3.0/ext/standard/var_unserializer.c /bin/sh: re2c: not found make: *** [php-4.3.0/ext/standard/var_unserializer.c] Error 1 I expected that if configure completed successfully, my system had everything it needed to build. Is re2c a required build tool? If so why didn't configure complain? -- Edit this bug report at http://bugs.php.net/?id=21552&edit=1
#21567 [Bgs]: die(__LINE__); gives no output
ID: 21567
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: *Programming Data Structures
Operating System: Windows XP
PHP Version: 4.2.3
New Comment:
Not a bug. __LINE__ is an integer. If you give die() or exit() an
integer, PHP will exit with that status. Using die((string) __LINE__)
should work.
Previous Comments:
[2003-01-10 08:43:41] [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
die(number) will make PHP exit with exit code "number" and not show any
message in this case. This is expected behavior and documented @
http://www.php.net/manual/en/function.exit.php
Derick
[2003-01-10 08:40:22] [EMAIL PROTECTED]
Dying like this:
die(__LINE__);
Doesn't work, i.e the script dies without any output.
Still, this works as expected:
die(__FILE__);
As does this:
die('Gone to sleep at line: '.__LINE__);
Chen
--
Edit this bug report at http://bugs.php.net/?id=21567&edit=1
#21566 [Opn->Csd]: problem with $_POST
ID: 21566 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed -Bug Type: Unknown/Other Function +Bug Type: Apache2 related Operating System: Linux Red Hat 8 PHP Version: 4.2.2 New Comment: This is probably caused by a bug in older versions of PHP in combination with Apache 2. Please upgrade to the latest version of PHP and Apache 2. Previous Comments: [2003-01-10 06:11:35] [EMAIL PROTECTED] I submit data using form ... ..in page2.php I have "; ?> .. I submit myname as 'Jack' .. I get this.. My name is Jackmyname=Jack My PHP came and installed with Linux Red Hat 8. -- Edit this bug report at http://bugs.php.net/?id=21566&edit=1
#21567 [Opn->Bgs]: die(__LINE__); gives no output
ID: 21567
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: *Programming Data Structures
Operating System: Windows XP
PHP Version: 4.2.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
die(number) will make PHP exit with exit code "number" and not show any
message in this case. This is expected behavior and documented @
http://www.php.net/manual/en/function.exit.php
Derick
Previous Comments:
[2003-01-10 08:40:22] [EMAIL PROTECTED]
Dying like this:
die(__LINE__);
Doesn't work, i.e the script dies without any output.
Still, this works as expected:
die(__FILE__);
As does this:
die('Gone to sleep at line: '.__LINE__);
Chen
--
Edit this bug report at http://bugs.php.net/?id=21567&edit=1
#21567 [NEW]: die(__LINE__); gives no output
From: [EMAIL PROTECTED]
Operating system: Windows XP
PHP version: 4.2.3
PHP Bug Type: *Programming Data Structures
Bug description: die(__LINE__); gives no output
Dying like this:
die(__LINE__);
Doesn't work, i.e the script dies without any output.
Still, this works as expected:
die(__FILE__);
As does this:
die('Gone to sleep at line: '.__LINE__);
Chen
--
Edit bug report at http://bugs.php.net/?id=21567&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21567&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=21567&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=21567&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21567&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=21567&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21567&r=support
Expected behavior: http://bugs.php.net/fix.php?id=21567&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=21567&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=21567&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=21567&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21567&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=21567&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=21567&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=21567&r=gnused
#21552 [Bgs->Opn]: re2c: command not found
ID: 21552 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open Bug Type: Compile Failure Operating System: Solaris 2.8 PHP Version: 4.3.0 New Comment: directory info from freshly un-tarred downloads from the official website, no other changes made or commands issued. The dates on solaris and linux are the same. The dates on the .c files are later than on the .re files. On Solaris: $ pwd /tmp/erik_tmp/php-4.3.0/ext/standard $ ls -l *.re -rw- ed2019 staff 12566 Sep 30 00:56 url_scanner_ex.re -rw- ed2019 staff 8276 Aug 19 15:45 var_unserializer.re $ ls -l url_scanner.c; ls -l url_scanner_ex.c; ls -l var_unserializer.c -rw- ed2019 staff 8279 Aug 28 02:13 url_scanner.c -rw- ed2019 staff 26762 Dec 26 23:51 url_scanner_ex.c -rw- ed2019 staff 16718 Dec 26 23:51 var_unserializer.c On Linux (debian): erik@oslo:~/phptemp/php-4.3.0/ext/standard$ -rw-r--r-- erik erik 12566 Sep 30 00:56 url_scanner_ex.re -rw-r--r-- erik erik 8276 Aug 19 15:45 var_unserializer.re erik@oslo:~/phptemp/php-4.3.0/ext/standard$ ls -l url_scanner.c; ls -l url_scanner_ex.c; ls -l var_unserializer.c -rw-r--r-- 1 erik erik 8279 Aug 28 02:13 url_scanner.c -rw-r--r-- 1 erik erik 26762 Dec 26 23:51 url_scanner_ex.c -rw-r--r-- 1 erik erik 16718 Dec 26 23:51 var_unserializer.c using: $ make -v GNU Make version 3.79.1, by Richard Stallman and Roland McGrath. Built for sparc-sun-solaris2.8 Previous Comments: [2003-01-10 05:17:42] [EMAIL PROTECTED] Is solaris incorrectly untaring the data stamp on the var_unserializer.c ? or is make file date check failing? the work around would be to touch var_unserializer.c before building.. but try untaring 4.3.0 and look at the date stamp to see if the .c is later than the .re file... [2003-01-10 00:37:14] [EMAIL PROTECTED] If he did something wrong, then I must have as well because I'm having the exact same problem on a clean copy of PHP 4.3.0, too. Solaris 8, Apache 1.3.x. ./configure --with-apxs=/usr/local/apache/bin/apxs --with- flatfile [2003-01-09 18:52:57] [EMAIL PROTECTED] re2c is not required (just tested). You've just done something wrong between unpacking the tar archive and 'make' command. [2003-01-09 12:27:32] [EMAIL PROTECTED] After configuring a fresh download of PHP 4.3.0, I attempted to compile with the following configure line: ./configure --with-apxs=/opt/apache1327/bin/apxs --with-mysql Configure complted successfully, and make halted partway through with the following message: re2c -b php-4.3.0/ext/standard/var_unserializer.re > php-4.3.0/ext/standard/var_unserializer.c /bin/sh: re2c: not found make: *** [php-4.3.0/ext/standard/var_unserializer.c] Error 1 I expected that if configure completed successfully, my system had everything it needed to build. Is re2c a required build tool? If so why didn't configure complain? -- Edit this bug report at http://bugs.php.net/?id=21552&edit=1
#21310 [Com]: no such file (paths)
ID: 21310 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: *Directory/Filesystem functions Operating System: Solaris 8 PHP Version: 4.3.0 New Comment: I also think it is a bugg. On ours servers all directories have only eXecute access to other. Give read access to other on all level is realy a problem. Cordialy. Previous Comments: [2003-01-06 12:02:18] [EMAIL PROTECTED] yes, same thing for me. if HTTP server has permission to read all directories in path to the file, all users can read directories of other user and it's really not secure ... [2003-01-05 16:59:45] [EMAIL PROTECTED] In my humble opinion it is a bug, because: 1. Previous version of PHP (4.0) could read file without full path, even if PHP couldnt read "." or higher directory. 2. PHP reads several directories (why?) when includes each file without full path. 2. There is no technical reason to give PHP access to read all directories from "/" to directories with PHP scripts. [2003-01-05 16:41:43] [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 [2003-01-05 16:37:36] [EMAIL PROTECTED] Module PHP can't find files (eg. includes them) if HTTP server hasn't permission to read all directories in path to the file. [2002-12-31 05:10:31] [EMAIL PROTECTED] After upgrading to 4.3.0 version some PHP scripts stop working. I have checked, that the reason is problem with opening and including files. FIRST EXAMPLE: I had to change variable: $blocked_list["kom.pl"] = "blockkom.txt"; ---> $blocked_list["kom.pl"] = "blockkom.txt"; SECOND EXAMPLE: --- Warning: main(main/linie.php) [function.main]: failed to create stream: No such file or directory in /www/klient34/start/dolacz.php on line 5 Warning: main() [function.main]: Failed opening 'main/linie.php' for inclusion (include_path=''.:..:/usr/local/lib/php'') in /www/klient34/start/dolacz.php on line 5 -- Edit this bug report at http://bugs.php.net/?id=21310&edit=1
#17039 [Csd]: re2c: command not found
ID: 17039 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Compile Failure Operating System: Linux PHP Version: 4.0CVS-2002-05-06 New Comment: it is the .c file that needs touching, not the .re file .c is generated from .re using re2c, and if the .re is newer make wants to create a new .c while a newer .c is thought to be up to date ... Previous Comments: [2003-01-08 11:23:46] [EMAIL PROTECTED] I had this same problem on Solaris, but with the 'stable' download 4.3.0 . touching ext/standard/url_scanner_ex.re did not allow it to compile all the way through, as suggested by [EMAIL PROTECTED] . Is re2c a required build tool? [2002-05-06 09:55:08] [EMAIL PROTECTED] Yes, that's fixed it. Seems to happen a lot recently (.re and .c commited in the wrong order). :-) [2002-05-06 08:18:42] [EMAIL PROTECTED] Either install re2c (http://www.tildeslash.org/re2c/ afaik) or just touch the url_scanner_ex.re file (seems someone forgot to touch it in CVS). [2002-05-06 08:15:27] [EMAIL PROTECTED] re2c -b /root/cvs/cvsphp/ext/standard/url_scanner_ex.re > /root/cvs/cvsphp/ext/standard/url_scanner_ex.c /bin/sh: re2c: command not found -- Edit this bug report at http://bugs.php.net/?id=17039&edit=1
#21291 [Com]: make failure
ID: 21291 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Servlet related Operating System: Linux Redhat 8 PHP Version: 4.3.0 New Comment: Solved, I sent a patch to php-dev mailing list, with this and other fix for unix/linux. please apply. Previous Comments: [2003-01-02 18:01:45] [EMAIL PROTECTED] This may be the same issue affecting my use of the servlet within tomcat. The JNI call to this servlet dll causes tomcat to crater. I managed to get the release candidate to work correctly. [2003-01-02 05:00:09] [EMAIL PROTECTED] I see there is a problem during configure, $(builddir) and $(srcdir) in sapi/servlet/Makefile.frag are ignored in the final Makefile also seems that when confiring with --with-java and --with-servlet, java got disabled. Unfortunatelly I do not know enougth the new build system to propose a patch [2002-12-30 07:58:56] [EMAIL PROTECTED] hi, servlet SAPI do not compile. I get this error: /usr/local/src/php4-STABLE-200212301230/sapi/servlet/servlet.c: In function `Java_net_php_servlet_startup': /usr/local/src/php4-STABLE-200212301230/sapi/servlet/servlet.c:264: warning: passing arg 2 of `php_module_startup' from incompatible pointer type make: *** No rule to make target `sapi/servlet/java.c', needed by `sapi/servlet/java.lo'. Stop. thanks -- Edit this bug report at http://bugs.php.net/?id=21291&edit=1
#21566 [NEW]: problem with $_POST
From: [EMAIL PROTECTED] Operating system: Linux Red Hat 8 PHP version: 4.2.2 PHP Bug Type: Unknown/Other Function Bug description: problem with $_POST I submit data using form ... ..in page2.php I have "; ?> .. I submit myname as 'Jack' .. I get this.. My name is Jackmyname=Jack My PHP came and installed with Linux Red Hat 8. -- Edit bug report at http://bugs.php.net/?id=21566&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21566&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21566&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21566&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21566&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21566&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21566&r=support Expected behavior: http://bugs.php.net/fix.php?id=21566&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21566&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21566&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21566&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21566&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21566&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21566&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21566&r=gnused
#21547 [Fbk->Opn]: segfault in _erealloc
ID: 21547
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: Reproducible crash
Operating System: Linux Mandrake Cooker
PHP Version: 4.3.0
New Comment:
Works fine, even with 12500.
With 10 I get
FATAL: emalloc(): Unable to allocate 11 bytes
Previous Comments:
[2003-01-09 16:20:34] [EMAIL PROTECTED]
Perphaps you have a system limit on the amount of memory a process make
try to use. Try the following script and see if it crashes:
[2003-01-09 10:23:39] [EMAIL PROTECTED]
The diagnosis is strange as it crashes using about 20MB while the
memory limit is at 128MB and I have more than 200MB free...
[2003-01-09 10:00:04] [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
Simple, PHP has run out of memory and when it fails to allocate it
exits or if you compiled PHP with --enable-debug dies with SIG11
(segmentation fault).
[2003-01-09 07:59:49] [EMAIL PROTECTED]
This quite heavily recursive script produces a segmentation fault :
Array(-1, 0),
'D'=>Array(1, 0),
'B'=>Array(0, 1),
'H'=>Array(0, -1));
$pieces=Array(
Array(Array(0,0),
Array(0,1)),
Array(Array(0,0),
Array(0,1)),
Array(Array(0,0),
Array(0,1)),
Array(Array(0,0),
Array(0,1)),
Array(Array(0,0),
Array(0,1),
Array(1,0),
Array(1,1)),
Array(Array(0,0)),
Array(Array(0,0)),
Array(Array(0,0)),
Array(Array(0,0)),
Array(Array(0,0),
Array(1,0)));
$init=Array(
Array(0,0),
Array(3,0),
Array(1,3),
Array(2,3),
Array(1,0),
Array(0,3),
Array(0,4),
Array(3,3),
Array(3,4),
Array(1,2));
function is_final($situation){
return(($situation[4][0]==1)&&($situation[4][1]==3));
}
function occupable($situation, $x, $y){
global $pieces;
if($x>3) return false;
if($y>4) return false;
if($x<0) return false;
if($y<0) return false;
foreach($situation as $piece=>$pos){
if($pos=="") continue;
$p = $pieces[$piece];
foreach($p as $case){
if(($case[0]+$pos[0]==$x)&&
($case[1]+$pos[1]==$y)) return false;
}
}
return true;
}
function valide($situation, $piece, $mov){
global $pieces;
$p = $pieces[$piece];
$x = $situation[$piece][0];
$y = $situation[$piece][1];
$situation[$piece]="";
foreach($p as $case){
if(!occupable($situation, $x+$case[0]+$mov[0], $y+$case[1]+$mov[1]))
return false;
}
return true;
}
function resolv($situation){
global $tab, $depls, $pieces, $solution;
$d = $depls;
$p = $pieces;
if(is_final($situation)){
$solution = "";
return;
}
foreach($p as $num=>$piece){
foreach($d as $nom=>$mov){
if(valide($situation, $num, $mov)){
$situation2=serialize($situation);
$s3=$situation;
$situation[$num][0]+=$mov[0];
$situation[$num][1]+=$mov[1];
$s=serialize($situation);
if(isset($tab[$s])){
$situation = $s3;
continue;
}
$tab[$s]="";
//echo $num.' '.$nom."\n";
//print_r($situation);
$tab[$situation2][$s]=Array($num=>$nom);
resolv($situation);
if($tab[$s]=="") unset($tab[$s]);
if(isset($solution)){
$solution=$num.' '.$nom."\n".$solution;
return;
}
$situation = $s3;
}
#21552 [Com]: re2c: command not found
ID: 21552 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Compile Failure Operating System: Solaris 2.8 PHP Version: 4.3.0 New Comment: Is solaris incorrectly untaring the data stamp on the var_unserializer.c ? or is make file date check failing? the work around would be to touch var_unserializer.c before building.. but try untaring 4.3.0 and look at the date stamp to see if the .c is later than the .re file... Previous Comments: [2003-01-10 00:37:14] [EMAIL PROTECTED] If he did something wrong, then I must have as well because I'm having the exact same problem on a clean copy of PHP 4.3.0, too. Solaris 8, Apache 1.3.x. ./configure --with-apxs=/usr/local/apache/bin/apxs --with- flatfile [2003-01-09 18:52:57] [EMAIL PROTECTED] re2c is not required (just tested). You've just done something wrong between unpacking the tar archive and 'make' command. [2003-01-09 12:27:32] [EMAIL PROTECTED] After configuring a fresh download of PHP 4.3.0, I attempted to compile with the following configure line: ./configure --with-apxs=/opt/apache1327/bin/apxs --with-mysql Configure complted successfully, and make halted partway through with the following message: re2c -b php-4.3.0/ext/standard/var_unserializer.re > php-4.3.0/ext/standard/var_unserializer.c /bin/sh: re2c: not found make: *** [php-4.3.0/ext/standard/var_unserializer.c] Error 1 I expected that if configure completed successfully, my system had everything it needed to build. Is re2c a required build tool? If so why didn't configure complain? -- Edit this bug report at http://bugs.php.net/?id=21552&edit=1
#14071 [Com]: 'admin-values' php.ini also for CGI-binary
ID: 14071 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Feature/Change Request Operating System: Linux/FreeBSD PHP Version: 4.0.6 New Comment: Guess I'm the only one who'd like this behaviour :) Previous Comments: [2001-11-15 13:12:05] [EMAIL PROTECTED] The problem I ran into while using PHP as CGI-binary under for example Apache instead of mod_php, is that you can't simply allow restrictive overrides of certain values. If you for example put a 'php.ini' file in a directory, PHP will read that file...completely ignoring the /usr/local/lib/php.ini Let's say we have a malicious user who wants to upload files of 100MB, he could simply do that by allowing this in his 'own' php.ini (post_max_size). I don't think this is a wanted situation. The restriction I'm using now (thanks to Mathieu), is by an edited php_ini.c that reads only the php.ini from PHP_CONFIG_FILE_PATH. Why not using the same guidelines as with the ini_set() function ? Or an option in the 'default' .ini, to turn this behaviour on...:)) -- Edit this bug report at http://bugs.php.net/?id=14071&edit=1
#21563 [Opn->Bgs]: Unidentified with mysql_pconnect()
ID: 21563 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: MySQL related Operating System: FreeBSD 4.5 PHP Version: 4.3.0 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 bug is fixed in CVS Previous Comments: [2003-01-10 02:52:09] [EMAIL PROTECTED] When I changed php version from 4.2.3 to 4.3.0 mysql_pconnect() function started to work in a strange way. For about 9 of 10 connections everything is ok, by 1 time of 10 calls, function returns an error. I cannot find any error information in mysqld.log or in any other place. When I change mysql_pchonnect() to mysql_connect() problem disapeares. Sorry for my english. Adam -- Edit this bug report at http://bugs.php.net/?id=21563&edit=1
#21489 [Com]: Excel hangs after creation via COM
ID: 21489
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: COM related
Operating System: Win 2K Server
PHP Version: 4.3.0
New Comment:
I solved the problem changing the default printer on the server! It
seems strange (and it is not) but if I change the printer and put a
simple (native and not plugged to the server...) printer as the default
printer, rather than a hand-installed one, EXCEL seems to act in the
right way. (the printer in question is a Canon Laser SHOT LBP-1210)
EXCEL does not show any strange behavior if it run normally by opening
it via the menu. But if it is run via PHP and COM the thing happens
Previous Comments:
[2003-01-08 21:17:35] [EMAIL PROTECTED]
I see this behaviour on 4.2.3 but not with 4.3.0 on Win2Kpro SP3 Apache
1.3.27 (PHP running as module).
On 4.2.3 the same Excel.exe is reused each time I run a
script very similar to this one. I end up with one Excel.exe left in
taskmanager after running this script "1 to n" times.
In 4.3.0 Excel.exe appears for a moment while the script runs then
disappears.
I get exactly the same behaviour on Win2k server SP2.
[2003-01-07 07:52:30] [EMAIL PROTECTED]
This is the code I always used with PHP prior to 4.2.X and 4.3.0:
function ExcelSheet($filein,$tmpdir) {
$fileout = substr(tempnam($tmpdir, "tmp"), 0, -4);
$ex = new COM("Excel.sheet") or Die ("Cannot find excel!");
$ex->Application->Visible = 0;
$wkb = $ex->Application->Workbooks->Open($filein) or Die ("Cannot
open excel!");
$ex->Application->ActiveWorkbook->SaveAs($fileout, -4143);
$ex->application->ActiveWorkbook->Close("False");
unset($ex);
return($fileout . ".xls");
}
The excel function works, but afterwards the excel process remains in
memory, as other people have already argued.
--
Edit this bug report at http://bugs.php.net/?id=21489&edit=1
#21477 [Opn]: $node->dump_node($node) crashes with libxml2-2.4.30
ID: 21477 User updated by: [EMAIL PROTECTED] -Summary: $node->dump_node($node) crashes when node has any attribute Reported By: [EMAIL PROTECTED] Status: Open Bug Type: DOM XML related Operating System: linux; kernel 2.4.18 PHP Version: 4.3.0 New Comment: modified bug title to be more specific Previous Comments: [2003-01-10 00:35:58] [EMAIL PROTECTED] Re-opening this bug. I'd be happy to work on it if some dom xml developers could give me a start. [2003-01-10 00:34:31] [EMAIL PROTECTED] It almost certainly is a PHP bug, according to Daniel Veillard, author of libxml2. It is an incompatibility with libxml2 version libxml2-2.4.30 or better, maybe earlier too. Ilia only tested with libxml2-2.4.25. Daniel has analyzed the backtrace, which follows, with comments: > Here is some more gdb output that might help. > > (gdb) info stack > #0 xmlStrEqual (str1=0x3 , > str2=0x401632e0 "-//W3C//DTD XHTML 1.0 Strict//EN") at parser.c:1293 > #1 0x4010d834 in xmlIsXHTML (systemID=0x4015e9c0 "text", > publicID=0x3 ) at tree.c:6728 > #2 0x4010d586 in xmlNodeDumpOutput (buf=0x81eadf8, doc=0x81f78a8, > cur=0x81f78a8, level=0, format=0, encoding=0x0) at tree.c:6599 > #3 0x4010cc72 in xmlNodeDump (buf=0x81eeaa0, doc=0x81f78a8, cur=0x81f78a8, > level=0, format=0) at tree.c:6164 > #4 0x080706ab in zif_domxml_dump_node (ht=1, return_value=0x81f584c, > this_ptr=0x81f3104, return_value_used=1) > at > /home/greg/new/php4-STABLE-200301070230/ext/domxml/php_domxml.c:3697 #5 > 0x0815576f in execute (op_array=0x81f27ac) > at /home/greg/new/php4-STABLE-200301070230/Zend/zend_execute.c:1596 > #6 0x08145756 in zend_execute_scripts (type=8, retval=0x0, file_count=3) > at /home/greg/new/php4-STABLE-200301070230/Zend/zend.c:864 > #7 0x08115afd in php_execute_script (primary_file=0xb880) > at /home/greg/new/php4-STABLE-200301070230/main/main.c:1573 > #8 0x0815b134 in main (argc=3, argv=0xb924) > at /home/greg/new/php4-STABLE-200301070230/sapi/cli/php_cli.c:746 > #9 0x401a0507 in __libc_start_main (main=0x815a83c , argc=3, > ubp_av=0xb924, init=0x8061588 <_init>, fini=0x815b7d0 <_fini>, > rtld_fini=0x4000dc14 <_dl_fini>, stack_end=0xb91c) > at ../sysdeps/generic/libc-start.c:129 > (gdb) > > Daniel said: The DTD node for the document was not properly initialized. The call made by xmlNodeDumpOutput is : is_xhtml = xmlIsXHTML(dtd->SystemID, dtd->ExternalID); the DTD is looked for based on the document passed to xmlNodeDumpOutput(). And the pointer stored in the DTD for the system ID is invalid. Go back to the PHP maintainer and ask him to fix the code making that xmlDtdPtr node. That DTD node was not generated by libxml2 as part of the parsed document since there is NO DOCTYPE entries in the parsed examples. I have no idea what the PHP code looks like but getting an invalid DTD node for a document which did not contained any initially doesn't give me a good opinion of that code quality honnestly. I have no idea of what's going on there, but this doesn't sound good, really. Daniel On Wed, Jan 08, 2003 at 10:42:54AM -0800, gk wrote: > I don't understand why, if this is a PHP issue, the bug is not reproducible > with the same version of PHP and different versions of libxml2. I will go > back to the same version of libxml2 that Ilia tested with and see if I can > reproduce it on my machine, with same PHP and sample code. I'm very sorry, but I do not have the time to fix the PHP code. Your documents from your example did NOT have any DOCTYPE. The doc xmlDocPtr passed to the serialization routine had an xmlDtdNode. That xmlDtdNode will NOT be generated by libxml2 (any version) when passing the sample examples your provided within your PHP. Moreover that xmlDtdNode is buggy because one of the pointers is 0x3 which leads to the crash. I don't have the time to find in the PHP code - what code generated that xmlDtdNode. - why it has buggy pointers - why it's passed to the serialization routine while obviously the document asked for serialization should NOT have an xmlDtdNode Again I can't debug this. This sounds completely broken to stay polite. The fact that the bug doesn't show up with other versions is simply that earlier version don't have the XHTML1 detection code looking for the DTD System ID in order to adjust the serializations accordingly. Daniel - On Wed, Jan 08, 2003 at 11:48:07AM -0800, gk wrote: > I have never debugged PHP sources either but looking in > /ext/domxml.c I found this: > The "FIX ME" comment seems to suggest a problem :--) > > /* FIXME: nodes of type XML_DTD_NODE us
#19292 [Ctl]: random error: open_basedir restriction in effect. File is in wrong directory
ID: 19292 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Critical Bug Type: Apache related Operating System: linux -PHP Version: 4.3.0-dev,4.2.3 +PHP Version: 4.2.3,4.3.0 New Comment: Update version. Bug confirmed in 4.3.0 - final. Previous Comments: [2003-01-10 03:17:18] [EMAIL PROTECTED] Is somebody working on this critical bug in php 4.3.0?? Bug was opened 8 sep and now it isn't even the same year... This is a severe problem for all hosting companies since they have to turn of open_basedir to get things going without errors. [2003-01-09 12:42:13] [EMAIL PROTECTED] I have just tried to EXPLICITLY set "php_admin_flag safe_mode off" to ALL virtual hosts, which should not be restricted with safe mode and it seems to help. So the problem is here only when I rely on the default setting in php.ini file (where I have safe mode off by default) and when there is AT LEAST one virtual host with safe_mode enabled. [2003-01-09 12:36:48] [EMAIL PROTECTED] If a have one virt. host with safe_mode turned on and the other one with safe_mode off, the SECOND one (with safe_mode off from default ini setting) sometimes seems to have safe_mode turned on, until next reload. When I tried to replace safe_mode with open_basedir restrictions, this problem was the same one, which is described above. [2003-01-09 04:36:33] [EMAIL PROTECTED] I wrote regression tests for safe mode recently which trigger this bug reliably when upgrading to 4.3.0 from 4.2.2 on Apache 2.0.40. In the Apache config I use: (erring on the side of verbosity) php_admin_value safe_mode 1 php_admin_value safe_mode_exec_dir /bin php_admin_value open_basedir / php_admin_value display_errors 0 php_admin_value log_errors 1 php_admin_value safe_mode_allowed_env_vars FOO_ php_admin_value safe_mode_protected_env_vars FOO_FEE Then: /local/qa/perl-framework/t/htdocs/php/safemode/readfile.php contains: The server error log gets this output for the script: PHP Warning: Unknown(): open_basedir restriction in effect. File(/local/qa/perl-framework/t/htdocs/php/safemode/readfile.php) is not within the allowed path(s): (/) in Unknown on line 0 PHP Warning: Unknown(/local/qa/perl-framework/t/htdocs/php/safemode/readfile.php): failed to create stream: Operation not permitted in Unknown on line 0 PHP Warning: Unknown(): Failed opening '/local/qa/perl-framework/t/htdocs/php/safemode/readfile.php' for inclusion (include_path='.:/usr/share/pear') in Unknown on line 0 [2003-01-06 11:29:06] [EMAIL PROTECTED] Getting totally wrong dir in the output of the error mess open_basedir restriction in effect. File(index.php) is not within the allowed path(s): (/home/userB) Getting this error when surfing to userA which has open_basedir set to /home/userA in apache virthost, one gets that access to userB home isn't granted. This might not be a fault in the open_basedir code, but for some reason it get's the wrong open_basedir dir from the calling function. If someone could take a deeper look at this it would be nice, hard to explain to all customers that this problem is out of our hands to fix. 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/19292 -- Edit this bug report at http://bugs.php.net/?id=19292&edit=1
#21565 [NEW]: safe_mode works well with include but not with require
From: [EMAIL PROTECTED] Operating system: Tru64Unix 5.1A PHP version: 4.3.0 PHP Bug Type: *General Issues Bug description: safe_mode works well with include but not with require After upgrade from PHP 4.2.2 to 4.3.0 I encountered the problem with safe_mode in conjunction with require(). Example: [php.ini] safe_mode = On; include_path = ".:./:/path/to/my/app/dir"; safe_mode_include_dir = ".:./:/path/to/my/app/dir"; [/path/to/my/app/dir/index_working.php] - works fine for me [/path/to/my/app/dir/index_buggy.php] - throws error The error: [error] PHP Fatal error: main() [function.main]: Failed opening required 'header.php' (include_path='.:./:/path/to/my/app/dir') in /path/to/my/app/dir/index_buggy.php on line 2 Operating system: Tru64Unix 5.1a Webserver: Apache 1.3.26 -- Edit bug report at http://bugs.php.net/?id=21565&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21565&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21565&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21565&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21565&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21565&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21565&r=support Expected behavior: http://bugs.php.net/fix.php?id=21565&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21565&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21565&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21565&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21565&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21565&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21565&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21565&r=gnused
#21564 [Opn->Bgs]: corrupted paths coming to open_basedir
ID: 21564 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Apache related Operating System: freebsd 4.6 PHP Version: 4.3.0 New Comment: Duplicate of #19292. Previous Comments: [2003-01-10 03:32:20] [EMAIL PROTECTED] If one is having open_basedir on in one virtualhost, that open_basedir is sometimes applied to another virtualhost without open_basedir restriction. This is NOT a bug in the open_basedir code, but the open_basedir function is feed with the wrong path, and triggers on that one. Looks like some mem corruption or init problem that doesn't clean the variables correctly before serving a new request. Problem occours when a apache child that has served a open_basedir restriced virtualhost, and the next request doesn't have open_basedir on or does have a different open_basedir path. Looks like this only applies to newly started apache childs also. This is critical. './configure' '--with-apxs=/usr/local/sbin/apxs' '--with-config-file-path=/usr/local/etc' '--enable-versioning' '--with-regex=system' '--without-gd' '--without-mysql' '--with-gd=/usr/local' '--enable-gd-native-ttf' '--with-freetype-dir=/usr/local' '--with-jpeg-dir=/usr/local' '--with-png-dir=/usr/local' '--with-zlib' '--with-mysql=/usr/local' '--with-pspell=/usr/local' '--prefix=/usr/local' 'i386-portbld-freebsd4.6' -- Edit this bug report at http://bugs.php.net/?id=21564&edit=1
#21564 [NEW]: corrupted paths coming to open_basedir
From: [EMAIL PROTECTED] Operating system: freebsd 4.6 PHP version: 4.3.0 PHP Bug Type: Apache related Bug description: corrupted paths coming to open_basedir If one is having open_basedir on in one virtualhost, that open_basedir is sometimes applied to another virtualhost without open_basedir restriction. This is NOT a bug in the open_basedir code, but the open_basedir function is feed with the wrong path, and triggers on that one. Looks like some mem corruption or init problem that doesn't clean the variables correctly before serving a new request. Problem occours when a apache child that has served a open_basedir restriced virtualhost, and the next request doesn't have open_basedir on or does have a different open_basedir path. Looks like this only applies to newly started apache childs also. This is critical. './configure' '--with-apxs=/usr/local/sbin/apxs' '--with-config-file-path=/usr/local/etc' '--enable-versioning' '--with-regex=system' '--without-gd' '--without-mysql' '--with-gd=/usr/local' '--enable-gd-native-ttf' '--with-freetype-dir=/usr/local' '--with-jpeg-dir=/usr/local' '--with-png-dir=/usr/local' '--with-zlib' '--with-mysql=/usr/local' '--with-pspell=/usr/local' '--prefix=/usr/local' 'i386-portbld-freebsd4.6' -- Edit bug report at http://bugs.php.net/?id=21564&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21564&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21564&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21564&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21564&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21564&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21564&r=support Expected behavior: http://bugs.php.net/fix.php?id=21564&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21564&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21564&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21564&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21564&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21564&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21564&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21564&r=gnused
#19292 [Com]: random error: open_basedir restriction in effect. File is in wrong directory
ID: 19292 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Critical Bug Type: Apache related Operating System: linux PHP Version: 4.3.0-dev,4.2.3 New Comment: Is somebody working on this critical bug in php 4.3.0?? Bug was opened 8 sep and now it isn't even the same year... This is a severe problem for all hosting companies since they have to turn of open_basedir to get things going without errors. Previous Comments: [2003-01-09 12:42:13] [EMAIL PROTECTED] I have just tried to EXPLICITLY set "php_admin_flag safe_mode off" to ALL virtual hosts, which should not be restricted with safe mode and it seems to help. So the problem is here only when I rely on the default setting in php.ini file (where I have safe mode off by default) and when there is AT LEAST one virtual host with safe_mode enabled. [2003-01-09 12:36:48] [EMAIL PROTECTED] If a have one virt. host with safe_mode turned on and the other one with safe_mode off, the SECOND one (with safe_mode off from default ini setting) sometimes seems to have safe_mode turned on, until next reload. When I tried to replace safe_mode with open_basedir restrictions, this problem was the same one, which is described above. [2003-01-09 04:36:33] [EMAIL PROTECTED] I wrote regression tests for safe mode recently which trigger this bug reliably when upgrading to 4.3.0 from 4.2.2 on Apache 2.0.40. In the Apache config I use: (erring on the side of verbosity) php_admin_value safe_mode 1 php_admin_value safe_mode_exec_dir /bin php_admin_value open_basedir / php_admin_value display_errors 0 php_admin_value log_errors 1 php_admin_value safe_mode_allowed_env_vars FOO_ php_admin_value safe_mode_protected_env_vars FOO_FEE Then: /local/qa/perl-framework/t/htdocs/php/safemode/readfile.php contains: The server error log gets this output for the script: PHP Warning: Unknown(): open_basedir restriction in effect. File(/local/qa/perl-framework/t/htdocs/php/safemode/readfile.php) is not within the allowed path(s): (/) in Unknown on line 0 PHP Warning: Unknown(/local/qa/perl-framework/t/htdocs/php/safemode/readfile.php): failed to create stream: Operation not permitted in Unknown on line 0 PHP Warning: Unknown(): Failed opening '/local/qa/perl-framework/t/htdocs/php/safemode/readfile.php' for inclusion (include_path='.:/usr/share/pear') in Unknown on line 0 [2003-01-06 11:29:06] [EMAIL PROTECTED] Getting totally wrong dir in the output of the error mess open_basedir restriction in effect. File(index.php) is not within the allowed path(s): (/home/userB) Getting this error when surfing to userA which has open_basedir set to /home/userA in apache virthost, one gets that access to userB home isn't granted. This might not be a fault in the open_basedir code, but for some reason it get's the wrong open_basedir dir from the calling function. If someone could take a deeper look at this it would be nice, hard to explain to all customers that this problem is out of our hands to fix. [2003-01-06 10:33:12] [EMAIL PROTECTED] Bug confirmed on FreeBSD 4.6 with php 4.3.0. Totally random it seems. 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/19292 -- Edit this bug report at http://bugs.php.net/?id=19292&edit=1
#21563 [NEW]: Unidentified with mysql_pconnect()
From: [EMAIL PROTECTED] Operating system: FreeBSD 4.5 PHP version: 4.3.0 PHP Bug Type: MySQL related Bug description: Unidentified with mysql_pconnect() When I changed php version from 4.2.3 to 4.3.0 mysql_pconnect() function started to work in a strange way. For about 9 of 10 connections everything is ok, by 1 time of 10 calls, function returns an error. I cannot find any error information in mysqld.log or in any other place. When I change mysql_pchonnect() to mysql_connect() problem disapeares. Sorry for my english. Adam -- Edit bug report at http://bugs.php.net/?id=21563&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21563&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21563&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21563&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21563&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21563&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21563&r=support Expected behavior: http://bugs.php.net/fix.php?id=21563&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21563&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21563&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21563&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21563&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21563&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21563&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21563&r=gnused
#20155 [Opn->Csd]: xmlrpc compile problem with zendengine2
ID: 20155
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: Zend Engine 2 problem
Operating System: Linux
PHP Version: 4CVS-2002-10-29
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:
[2002-10-29 16:56:38] [EMAIL PROTECTED]
gcc
-I/home/weigon/projects/in-cvs/php4/ext/xmlrpc/libxmlrpc
-DVERSION=0.50 -Iext/xmlrpc/
-I/home/weigon/projects/in-cvs/php4/ext/xmlrpc/
-DPHP_ATOM_INC -I/home/weigon/projects/in-cvs/php4/include
-I/home/weigon/projects/in-cvs/php4/main
-I/home/weigon/projects/in-cvs/php4
-I/home/weigon/projects/in-cvs/php4/Zend
-I/usr/include/freetype2 -I/usr//include
-I/home/weigon/projects/in-cvs/php4/TSRM -g -O2 -c
/home/weigon/projects/in-cvs/php4/ext/xmlrpc/xmlrpc-epi-php.c
-o ext/xmlrpc/xmlrpc-epi-php.o && echo >
ext/xmlrpc/xmlrpc-epi-php.lo
/home/weigon/projects/in-cvs/php4/ext/xmlrpc/xmlrpc-epi-php.c:
In function `set_zval_xmlrpc_type':
/home/weigon/projects/in-cvs/php4/ext/xmlrpc/xmlrpc-epi-php.c:1348:
structure has no member named `properties'
/home/weigon/projects/in-cvs/php4/ext/xmlrpc/xmlrpc-epi-php.c:1349:
structure has no member named `properties'
make: *** [ext/xmlrpc/xmlrpc-epi-php.lo] Fehler 1
Line 1348:
if(SUCCESS ==
zend_hash_update(value->value.obj.properties,
OBJECT_TYPE_ATTR, sizeof(OBJECT_TYPE_ATTR), (void *)
&type, sizeof(zval *), NULL)) {
bSuccess =
zend_hash_update(value->value.obj.properties,
OBJECT_VALUE_TS_ATTR, sizeof(OBJECT_VALUE_TS_ATTR), (void
*) &ztimestamp, sizeof(zval *), NULL);
}
value.obj.properties is not available in ZendEngine2.
--
Edit this bug report at http://bugs.php.net/?id=20155&edit=1
