Bug #14529 Updated: script doesn't always finish output
ID: 14529
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Critical
Bug Type: Output Control
Operating System: Linux RH 7.2
PHP Version: 4.3.0-dev
New Comment:
I did the same thing a while back and things appeared to work again.
My screens were not getting cut off on every page load. But apache
still crashed on almost every page viewed. Somehow, IE was able to
display the page (I'm thinking though cache but it caught some of the
newer info - but not always) but Netscape, Opera and some linux
browsers simply displayed an error that they could not connect and
eventually even in IE the pages started getting cut off again.
It's as if apache crashed anyways for me only crashed sooner if the
session read function returned false instead of an empty string.
I've cut my program very small and eliminated all include/require
statements thinking I'd add them until the problem occured, only as a
base program (still fairly complex) the problem still occurs. Yet I've
written some very simple pages and they don't crash. It's almost like
it's a combination of tasks that cause it.
Previous Comments:
[2002-03-26 18:22:30] [EMAIL PROTECTED]
YEAH! IT WORKS! I've solved my problem! It was related to my
session_handling and the session_read function. When I forced the
function to ALWAYS return a string, even if it was an empty one apache
stopped crashing!
return (string)$value;
Previously I sometimes returned other values such as the boolean false.
This didn't make apache crash with 4.0.6 but it does with the later
versions.
*happy happy happy*
The page works like a charm again! No cut off pages! No messed up
posted forms! No more weird sessions that doesn't register! I LOVE IT!
[2002-03-20 06:18:03] [EMAIL PROTECTED]
http://www.php.net/manual/en/function.session-set-save-handler.php
On this page are a lot of comments, one of them was striking:
quote
04-Mar-2002 02:57
I just want to mention, that it's critical to return a string value
with
the read function, because there can be strange errors if - for example
-
the return value is null. In my case the php program stopped in the
middle
of an echo command, so it was really hard to find, that the
real problem was with that session read callback function.
The easyest way to handle this, that you should cast the return value
before return. For example:
function read ($id) {
/* code here to produce $retval */
return (string)$retval;
}
/quote
Weird, isn't it, but maybe it helps getting more close to solving the
problem.
ps: we've got php4.1.2 now installed as a CGI,
session.save_handler=files, still using the session_set_save_handler
function (although it doesn't say so in the tutorial -explicitly- it
does override the 'files'-setting, see one of the other comments) and I
don't have any problems anymore. At least, not until now, fingers
crossed.
[2002-03-19 16:28:14] [EMAIL PROTECTED]
Responding to albert.
My system also needed to have session.save_handler set to user for load
balancing. However, I tried using files instead and at first I thought
it worked fine but it turned out it still crashed, only less often and
at different points. (Previously code output always stopped at
specific spots when it crashed and only on some pages, this just
changed the point at which it would crash and other pages that before
had no problems didn't appear correctly.
Some have suggested they removed sessions all together and still had
the problem and others claim the problems stop if sessions are not
used. (Maybe there is two completely different bugs causing similar
problems).
It seems as if this bug has nothing that anyone has been able to narrow
down as what causes the problem.
Besides apache crashing (Segmentation fault)I have noticed that other
small things don't opperate properly since version 4.0.6 that should.
Here are two other things I've seen give problems and confirmed through
test scripts.
4.2.x (or 4.3.x) unserialize() does not recognizing values set by
serialize() in PHP 4.0.x. My system stores arrays using the
serialize() function into a database (such as a color scheme). When I
upgrade to 4.2.x or new snaps, when those strings are pulled from the
database, the unserialize() function will gives an error that it
couldn't read the string (this is not a magic_quote issue as settings
are the same).
Session variable values getting corrupted:
For example at one point I had a transparent graphic shim.gif used on a
page to keep columns widths in line. That graphic was moved to a new
location but a php's script was not updated from img src=shim.gif to
img src=/images/shim.gif. This meant the HTML
Bug #14529 Updated: script doesn't always finish output
ID: 14529
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Critical
Bug Type: Output Control
Operating System: Linux RH 7.2
PHP Version: 4.3.0-dev
New Comment:
http://www.php.net/manual/en/function.session-set-save-handler.php
On this page are a lot of comments, one of them was striking:
quote
04-Mar-2002 02:57
I just want to mention, that it's critical to return a string value
with
the read function, because there can be strange errors if - for example
-
the return value is null. In my case the php program stopped in the
middle
of an echo command, so it was really hard to find, that the
real problem was with that session read callback function.
The easyest way to handle this, that you should cast the return value
before return. For example:
function read ($id) {
/* code here to produce $retval */
return (string)$retval;
}
/quote
Weird, isn't it, but maybe it helps getting more close to solving the
problem.
ps: we've got php4.1.2 now installed as a CGI,
session.save_handler=files, still using the session_set_save_handler
function (although it doesn't say so in the tutorial -explicitly- it
does override the 'files'-setting, see one of the other comments) and I
don't have any problems anymore. At least, not until now, fingers
crossed.
Previous Comments:
[2002-03-19 16:28:14] [EMAIL PROTECTED]
Responding to albert.
My system also needed to have session.save_handler set to user for load
balancing. However, I tried using files instead and at first I thought
it worked fine but it turned out it still crashed, only less often and
at different points. (Previously code output always stopped at
specific spots when it crashed and only on some pages, this just
changed the point at which it would crash and other pages that before
had no problems didn't appear correctly.
Some have suggested they removed sessions all together and still had
the problem and others claim the problems stop if sessions are not
used. (Maybe there is two completely different bugs causing similar
problems).
It seems as if this bug has nothing that anyone has been able to narrow
down as what causes the problem.
Besides apache crashing (Segmentation fault)I have noticed that other
small things don't opperate properly since version 4.0.6 that should.
Here are two other things I've seen give problems and confirmed through
test scripts.
4.2.x (or 4.3.x) unserialize() does not recognizing values set by
serialize() in PHP 4.0.x. My system stores arrays using the
serialize() function into a database (such as a color scheme). When I
upgrade to 4.2.x or new snaps, when those strings are pulled from the
database, the unserialize() function will gives an error that it
couldn't read the string (this is not a magic_quote issue as settings
are the same).
Session variable values getting corrupted:
For example at one point I had a transparent graphic shim.gif used on a
page to keep columns widths in line. That graphic was moved to a new
location but a php's script was not updated from img src=shim.gif to
img src=/images/shim.gif. This meant the HTML that PHP returned to
the visitors browser had a simple invalid link in it and the page
should load normally with just an empty placeholder where the image
shim.gif was to be. However, even though this did happen it also did
mess up session variable values. A simple test created that had the
HTML code with the invalid location for shim.gif in the image tag along
with the lines:
echo $HTTP_SERVER_VARS['PHP_SELF'].'br';
$HTTP_SESSION_VAR['lastpage']=$HTTP_SERVER_VARS['PHP_SELF'];
echo $HTTP_SERVER_VARS['PHP_SELF'].'br';
would output correctly:
pagename.php
pagename.php
BUT the session $HTTP_SESSION_VAR['lastpage'] upon the next page load
would be equal to 'shim.gif' and not 'pagename.php' like you'd expect.
So even though $HTTP_SERVER_VARS['PHP_SELF'] returned (and must have
set the correct value), setting it into a session changed the value of
it.
These problems did not happen in version 4.0.6 or older, so they may
have something to do with the bug of shutting down apache but I don't
know enough of how PHP is written to really know.
Hope this helps.
[2002-03-19 10:03:48] [EMAIL PROTECTED]
Check out bug-report #15940, talking about propably the same problems
there
[2002-03-19 10:00:27] [EMAIL PROTECTED]
Read the whole thread, concluded that I've got the same problems as
described by jay1
First we thought that it maybe was an Apacheproblem, so we installed an
older version than 1.3.23, namely 1.3.20
This didn't help, same bugs appeared.
Fiddled around with fopen, nothing there.
Read this thread and came to the idea to
Bug #14529 Updated: script doesn't always finish output
ID: 14529 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Critical Bug Type: Output Control Operating System: Linux RH 7.2 PHP Version: 4.3.0-dev New Comment: My problem isn't ftp-related either. Previous Comments: [2002-03-18 13:55:46] [EMAIL PROTECTED] My problems are definately not ftp, I run all my scripts first here on my local test server where they are created in the first place. My scripts ran fine on PHP4.0.6 or older but not properly on any new version since then. [2002-03-18 07:57:53] [EMAIL PROTECTED] Well it looks like I isolated the problem... and it's not PHP related. The FTP package I've been using has been truncating files that it has been sending to our server for some reason. I only just discovered this today as it did it to a non-PHP document that I sent (one of only a few). I've changed to another FTP package and sent the PHP docs I was having trouble with to our server (RH 7.2/Apache 1.3.20/PHP 4.0.6) and they ran OK. I'm not sure whether it was an FTP client or server problem (client more likely, but maybe clients are having problems dumping php files onto a specific FTP server build?) The FTPD we're running is WU FTPD 2.6.1 - others with this problem might want to check this isn't happening to their too. [2002-03-17 20:30:02] [EMAIL PROTECTED] Is it just me or does the output bug show up more often after a session_destory and then a header(location to another page? When I successfully use my login page it redirects me to a startpage which NEVER shows up wrong. When I logout from this page via a logout link it destoys the session and the redirects me to the login page. The login page NEVER EVER shoes up correctly upon using this route. If I reload it it shows up nicely. /Fabbe [2002-03-17 20:15:36] [EMAIL PROTECTED] Sorry... About the loginpage in my previous comment: I explained wrong and I think I have an interesting point to notice. The loginpage sometime crashes in one of two ways: It stops loading at the same spot, and when posting data to login the script doesn't ignores the header(location call) as if the session i just registered isn't there. My point is that it seems like the session doensn't register correctly even if it does so half the time and it always did with 4.0.x. Nuf said... [2002-03-17 20:09:47] [EMAIL PROTECTED] I'm experiencing the same problem. Pages sometimes get cut off, always in the same place. I'm having the problem on some of my pages and not all of them. The most annoying occrunce is on a login-page which loads correctly way to seldom and makes it almost impossible to login. The bug wasn't there in 4.0.x but when we upgraded to 4.1.x it is... We haven't been able to go back to 4.0.x to ensure that it isn't apache that messes up but we don't think so. Example of bug: www.svenskamagic.com (the last part of the page shows up corrupted sometimes) www.svenskamagic.com/club_login.php (page stops at the same spot all the time and it's hard to login when posting data with the form. An interesting point is that when the page works and you make a faulty login it shows an error-output Wrong user/pass, but when the page doesn't work upon logging in, it doesn't. It's like it just reloads the page without any form data sent to it.(if the form data would be there it would leave the error mess)) www.svenskamagic.com/phpinfo.php (info about the 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/14529 -- Edit this bug report at http://bugs.php.net/?id=14529edit=1
Bug #14529 Updated: script doesn't always finish output
ID: 14529 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Critical Bug Type: Output Control Operating System: Linux RH 7.2 PHP Version: 4.3.0-dev New Comment: Read the whole thread, concluded that I've got the same problems as described by jay1 First we thought that it maybe was an Apacheproblem, so we installed an older version than 1.3.23, namely 1.3.20 This didn't help, same bugs appeared. Fiddled around with fopen, nothing there. Read this thread and came to the idea to set session.save_handler to files instead of user (wich setting actually IS necesary, because we loadbalance our site with three mirrored servers). And since then, no problems at all. My question now is to jay1: how is session.save_handler in your php-config? Previous Comments: [2002-03-19 06:25:29] [EMAIL PROTECTED] My problem isn't ftp-related either. [2002-03-18 13:55:46] [EMAIL PROTECTED] My problems are definately not ftp, I run all my scripts first here on my local test server where they are created in the first place. My scripts ran fine on PHP4.0.6 or older but not properly on any new version since then. [2002-03-18 07:57:53] [EMAIL PROTECTED] Well it looks like I isolated the problem... and it's not PHP related. The FTP package I've been using has been truncating files that it has been sending to our server for some reason. I only just discovered this today as it did it to a non-PHP document that I sent (one of only a few). I've changed to another FTP package and sent the PHP docs I was having trouble with to our server (RH 7.2/Apache 1.3.20/PHP 4.0.6) and they ran OK. I'm not sure whether it was an FTP client or server problem (client more likely, but maybe clients are having problems dumping php files onto a specific FTP server build?) The FTPD we're running is WU FTPD 2.6.1 - others with this problem might want to check this isn't happening to their too. [2002-03-17 20:30:02] [EMAIL PROTECTED] Is it just me or does the output bug show up more often after a session_destory and then a header(location to another page? When I successfully use my login page it redirects me to a startpage which NEVER shows up wrong. When I logout from this page via a logout link it destoys the session and the redirects me to the login page. The login page NEVER EVER shoes up correctly upon using this route. If I reload it it shows up nicely. /Fabbe [2002-03-17 20:15:36] [EMAIL PROTECTED] Sorry... About the loginpage in my previous comment: I explained wrong and I think I have an interesting point to notice. The loginpage sometime crashes in one of two ways: It stops loading at the same spot, and when posting data to login the script doesn't ignores the header(location call) as if the session i just registered isn't there. My point is that it seems like the session doensn't register correctly even if it does so half the time and it always did with 4.0.x. Nuf said... 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/14529 -- Edit this bug report at http://bugs.php.net/?id=14529edit=1
Bug #14529 Updated: script doesn't always finish output
ID: 14529 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Critical Bug Type: Output Control Operating System: Linux RH 7.2 PHP Version: 4.3.0-dev New Comment: Check out bug-report #15940, talking about propably the same problems there Previous Comments: [2002-03-19 10:00:27] [EMAIL PROTECTED] Read the whole thread, concluded that I've got the same problems as described by jay1 First we thought that it maybe was an Apacheproblem, so we installed an older version than 1.3.23, namely 1.3.20 This didn't help, same bugs appeared. Fiddled around with fopen, nothing there. Read this thread and came to the idea to set session.save_handler to files instead of user (wich setting actually IS necesary, because we loadbalance our site with three mirrored servers). And since then, no problems at all. My question now is to jay1: how is session.save_handler in your php-config? [2002-03-19 06:25:29] [EMAIL PROTECTED] My problem isn't ftp-related either. [2002-03-18 13:55:46] [EMAIL PROTECTED] My problems are definately not ftp, I run all my scripts first here on my local test server where they are created in the first place. My scripts ran fine on PHP4.0.6 or older but not properly on any new version since then. [2002-03-18 07:57:53] [EMAIL PROTECTED] Well it looks like I isolated the problem... and it's not PHP related. The FTP package I've been using has been truncating files that it has been sending to our server for some reason. I only just discovered this today as it did it to a non-PHP document that I sent (one of only a few). I've changed to another FTP package and sent the PHP docs I was having trouble with to our server (RH 7.2/Apache 1.3.20/PHP 4.0.6) and they ran OK. I'm not sure whether it was an FTP client or server problem (client more likely, but maybe clients are having problems dumping php files onto a specific FTP server build?) The FTPD we're running is WU FTPD 2.6.1 - others with this problem might want to check this isn't happening to their too. [2002-03-17 20:30:02] [EMAIL PROTECTED] Is it just me or does the output bug show up more often after a session_destory and then a header(location to another page? When I successfully use my login page it redirects me to a startpage which NEVER shows up wrong. When I logout from this page via a logout link it destoys the session and the redirects me to the login page. The login page NEVER EVER shoes up correctly upon using this route. If I reload it it shows up nicely. /Fabbe 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/14529 -- Edit this bug report at http://bugs.php.net/?id=14529edit=1
Bug #14529 Updated: script doesn't always finish output
ID: 14529 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Critical Bug Type: Output Control Operating System: Linux RH 7.2 PHP Version: 4.3.0-dev New Comment: Responding to albert. My system also needed to have session.save_handler set to user for load balancing. However, I tried using files instead and at first I thought it worked fine but it turned out it still crashed, only less often and at different points. (Previously code output always stopped at specific spots when it crashed and only on some pages, this just changed the point at which it would crash and other pages that before had no problems didn't appear correctly. Some have suggested they removed sessions all together and still had the problem and others claim the problems stop if sessions are not used. (Maybe there is two completely different bugs causing similar problems). It seems as if this bug has nothing that anyone has been able to narrow down as what causes the problem. Besides apache crashing (Segmentation fault)I have noticed that other small things don't opperate properly since version 4.0.6 that should. Here are two other things I've seen give problems and confirmed through test scripts. 4.2.x (or 4.3.x) unserialize() does not recognizing values set by serialize() in PHP 4.0.x. My system stores arrays using the serialize() function into a database (such as a color scheme). When I upgrade to 4.2.x or new snaps, when those strings are pulled from the database, the unserialize() function will gives an error that it couldn't read the string (this is not a magic_quote issue as settings are the same). Session variable values getting corrupted: For example at one point I had a transparent graphic shim.gif used on a page to keep columns widths in line. That graphic was moved to a new location but a php's script was not updated from img src=shim.gif to img src=/images/shim.gif. This meant the HTML that PHP returned to the visitors browser had a simple invalid link in it and the page should load normally with just an empty placeholder where the image shim.gif was to be. However, even though this did happen it also did mess up session variable values. A simple test created that had the HTML code with the invalid location for shim.gif in the image tag along with the lines: echo $HTTP_SERVER_VARS['PHP_SELF'].'br'; $HTTP_SESSION_VAR['lastpage']=$HTTP_SERVER_VARS['PHP_SELF']; echo $HTTP_SERVER_VARS['PHP_SELF'].'br'; would output correctly: pagename.php pagename.php BUT the session $HTTP_SESSION_VAR['lastpage'] upon the next page load would be equal to 'shim.gif' and not 'pagename.php' like you'd expect. So even though $HTTP_SERVER_VARS['PHP_SELF'] returned (and must have set the correct value), setting it into a session changed the value of it. These problems did not happen in version 4.0.6 or older, so they may have something to do with the bug of shutting down apache but I don't know enough of how PHP is written to really know. Hope this helps. Previous Comments: [2002-03-19 10:03:48] [EMAIL PROTECTED] Check out bug-report #15940, talking about propably the same problems there [2002-03-19 10:00:27] [EMAIL PROTECTED] Read the whole thread, concluded that I've got the same problems as described by jay1 First we thought that it maybe was an Apacheproblem, so we installed an older version than 1.3.23, namely 1.3.20 This didn't help, same bugs appeared. Fiddled around with fopen, nothing there. Read this thread and came to the idea to set session.save_handler to files instead of user (wich setting actually IS necesary, because we loadbalance our site with three mirrored servers). And since then, no problems at all. My question now is to jay1: how is session.save_handler in your php-config? [2002-03-19 06:25:29] [EMAIL PROTECTED] My problem isn't ftp-related either. [2002-03-18 13:55:46] [EMAIL PROTECTED] My problems are definately not ftp, I run all my scripts first here on my local test server where they are created in the first place. My scripts ran fine on PHP4.0.6 or older but not properly on any new version since then. [2002-03-18 07:57:53] [EMAIL PROTECTED] Well it looks like I isolated the problem... and it's not PHP related. The FTP package I've been using has been truncating files that it has been sending to our server for some reason. I only just discovered this today as it did it to a non-PHP document that I sent (one of only a few). I've changed to another FTP package and sent the PHP docs I was having trouble with to our
Bug #14529 Updated: script doesn't always finish output
ID: 14529 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Critical Bug Type: Output Control Operating System: Linux RH 7.2 PHP Version: 4.3.0-dev New Comment: My problems are definately not ftp, I run all my scripts first here on my local test server where they are created in the first place. My scripts ran fine on PHP4.0.6 or older but not properly on any new version since then. Previous Comments: [2002-03-18 07:57:53] [EMAIL PROTECTED] Well it looks like I isolated the problem... and it's not PHP related. The FTP package I've been using has been truncating files that it has been sending to our server for some reason. I only just discovered this today as it did it to a non-PHP document that I sent (one of only a few). I've changed to another FTP package and sent the PHP docs I was having trouble with to our server (RH 7.2/Apache 1.3.20/PHP 4.0.6) and they ran OK. I'm not sure whether it was an FTP client or server problem (client more likely, but maybe clients are having problems dumping php files onto a specific FTP server build?) The FTPD we're running is WU FTPD 2.6.1 - others with this problem might want to check this isn't happening to their too. [2002-03-17 20:30:02] [EMAIL PROTECTED] Is it just me or does the output bug show up more often after a session_destory and then a header(location to another page? When I successfully use my login page it redirects me to a startpage which NEVER shows up wrong. When I logout from this page via a logout link it destoys the session and the redirects me to the login page. The login page NEVER EVER shoes up correctly upon using this route. If I reload it it shows up nicely. /Fabbe [2002-03-17 20:15:36] [EMAIL PROTECTED] Sorry... About the loginpage in my previous comment: I explained wrong and I think I have an interesting point to notice. The loginpage sometime crashes in one of two ways: It stops loading at the same spot, and when posting data to login the script doesn't ignores the header(location call) as if the session i just registered isn't there. My point is that it seems like the session doensn't register correctly even if it does so half the time and it always did with 4.0.x. Nuf said... [2002-03-17 20:09:47] [EMAIL PROTECTED] I'm experiencing the same problem. Pages sometimes get cut off, always in the same place. I'm having the problem on some of my pages and not all of them. The most annoying occrunce is on a login-page which loads correctly way to seldom and makes it almost impossible to login. The bug wasn't there in 4.0.x but when we upgraded to 4.1.x it is... We haven't been able to go back to 4.0.x to ensure that it isn't apache that messes up but we don't think so. Example of bug: www.svenskamagic.com (the last part of the page shows up corrupted sometimes) www.svenskamagic.com/club_login.php (page stops at the same spot all the time and it's hard to login when posting data with the form. An interesting point is that when the page works and you make a faulty login it shows an error-output Wrong user/pass, but when the page doesn't work upon logging in, it doesn't. It's like it just reloads the page without any form data sent to it.(if the form data would be there it would leave the error mess)) www.svenskamagic.com/phpinfo.php (info about the server) [2002-03-17 11:50:01] [EMAIL PROTECTED] Sorry, don't mind my previous post. I had a bug in my template system. 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/14529 -- Edit this bug report at http://bugs.php.net/?id=14529edit=1
Bug #14529 Updated: script doesn't always finish output
ID: 14529
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Critical
Bug Type: Output Control
Operating System: Linux RH 7.2
PHP Version: 4.3.0-dev
New Comment:
I found an interesting detail. On my windows box running PHP 4.1.1 and
Apache 1.3.23, it only stops on = signs.
I had a template that has some = signs in it, and by replacing the
first accurence, it goes on until the next one.
I'm using output buffering, but it outputs the content anyway. The
interesting fact is that it only turncates the output while echoing the
buffer.
Previous Comments:
[2002-03-14 04:02:44] [EMAIL PROTECTED]
Apologies for not including web server details (did so in another post
on another bug). Apache 1.3.20 with PHP as a DSO (no CGI compile). My
local Unix guru has suggested trying a more recent Apache release which
I will do when I get chance.
I haven't tried with 4.0.6 pre-file upload and I am loathed to do so as
I've now built PHP about a dozen times in the last week or so.
I don't have access to another linux ditro unfortunately although we
are running a production environment on Solaris. I haven't tried
anything on that yet due to its production status but can do if it
helps.
GCC details (gcc -v)
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
gcc version 2.96 2731 (Red Hat Linux 7.1 2.96-98)
[2002-03-13 17:27:27] [EMAIL PROTECTED]
We MAY have seen a similar problem (not using Zend Optimizer, though --
whew!). We had problems with locutions like
function postprocess($buf)
{
$buf = preg_replace(/some stuff/,some other stuff,$buf);
return $buf;
}
ob_start(postprocess);
Changing the postprocess function to
function postprocess($ibuf)
{
$obuf = preg_replace(/some stuff/,some other stuff,$ibuf);
return $obuf;
}
seems to have eliminated the problem.
[2002-03-13 10:41:37] [EMAIL PROTECTED]
A question for [EMAIL PROTECTED] :
Did you try it before the patch was applied in 4.0.6
Of the pages giving me grief, some of them have forms and some of them
don't.
I don't have the access at my end to try my scripts on a different
linux version.
[2002-03-13 08:57:03] [EMAIL PROTECTED]
i faintly remember issues with the gcc version
RedHat uses (experimental gcc prerelease from
their own labs or something)
there were definetly problems in the past that
where RedHat-only :(
do you have a chance to test on another linux
distribution or to compile on another one and
transfer the binaries to your RH system?
[2002-03-13 08:31:53] [EMAIL PROTECTED]
Which webserver and version do you use?
Derick
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/14529
--
Edit this bug report at http://bugs.php.net/?id=14529edit=1
Bug #14529 Updated: script doesn't always finish output
ID: 14529
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Critical
Bug Type: Output Control
Operating System: Linux RH 7.2
PHP Version: 4.3.0-dev
New Comment:
Sorry, don't mind my previous post. I had a bug in my template system.
Previous Comments:
[2002-03-17 11:19:53] [EMAIL PROTECTED]
I found an interesting detail. On my windows box running PHP 4.1.1 and
Apache 1.3.23, it only stops on = signs.
I had a template that has some = signs in it, and by replacing the
first accurence, it goes on until the next one.
I'm using output buffering, but it outputs the content anyway. The
interesting fact is that it only turncates the output while echoing the
buffer.
[2002-03-14 04:02:44] [EMAIL PROTECTED]
Apologies for not including web server details (did so in another post
on another bug). Apache 1.3.20 with PHP as a DSO (no CGI compile). My
local Unix guru has suggested trying a more recent Apache release which
I will do when I get chance.
I haven't tried with 4.0.6 pre-file upload and I am loathed to do so as
I've now built PHP about a dozen times in the last week or so.
I don't have access to another linux ditro unfortunately although we
are running a production environment on Solaris. I haven't tried
anything on that yet due to its production status but can do if it
helps.
GCC details (gcc -v)
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
gcc version 2.96 2731 (Red Hat Linux 7.1 2.96-98)
[2002-03-13 17:27:27] [EMAIL PROTECTED]
We MAY have seen a similar problem (not using Zend Optimizer, though --
whew!). We had problems with locutions like
function postprocess($buf)
{
$buf = preg_replace(/some stuff/,some other stuff,$buf);
return $buf;
}
ob_start(postprocess);
Changing the postprocess function to
function postprocess($ibuf)
{
$obuf = preg_replace(/some stuff/,some other stuff,$ibuf);
return $obuf;
}
seems to have eliminated the problem.
[2002-03-13 10:41:37] [EMAIL PROTECTED]
A question for [EMAIL PROTECTED] :
Did you try it before the patch was applied in 4.0.6
Of the pages giving me grief, some of them have forms and some of them
don't.
I don't have the access at my end to try my scripts on a different
linux version.
[2002-03-13 08:57:03] [EMAIL PROTECTED]
i faintly remember issues with the gcc version
RedHat uses (experimental gcc prerelease from
their own labs or something)
there were definetly problems in the past that
where RedHat-only :(
do you have a chance to test on another linux
distribution or to compile on another one and
transfer the binaries to your RH system?
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/14529
--
Edit this bug report at http://bugs.php.net/?id=14529edit=1
Bug #14529 Updated: script doesn't always finish output
ID: 14529 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Critical Bug Type: Output Control Operating System: Linux RH 7.2 PHP Version: 4.3.0-dev New Comment: Is it just me or does the output bug show up more often after a session_destory and then a header(location to another page? When I successfully use my login page it redirects me to a startpage which NEVER shows up wrong. When I logout from this page via a logout link it destoys the session and the redirects me to the login page. The login page NEVER EVER shoes up correctly upon using this route. If I reload it it shows up nicely. /Fabbe Previous Comments: [2002-03-17 20:15:36] [EMAIL PROTECTED] Sorry... About the loginpage in my previous comment: I explained wrong and I think I have an interesting point to notice. The loginpage sometime crashes in one of two ways: It stops loading at the same spot, and when posting data to login the script doesn't ignores the header(location call) as if the session i just registered isn't there. My point is that it seems like the session doensn't register correctly even if it does so half the time and it always did with 4.0.x. Nuf said... [2002-03-17 20:09:47] [EMAIL PROTECTED] I'm experiencing the same problem. Pages sometimes get cut off, always in the same place. I'm having the problem on some of my pages and not all of them. The most annoying occrunce is on a login-page which loads correctly way to seldom and makes it almost impossible to login. The bug wasn't there in 4.0.x but when we upgraded to 4.1.x it is... We haven't been able to go back to 4.0.x to ensure that it isn't apache that messes up but we don't think so. Example of bug: www.svenskamagic.com (the last part of the page shows up corrupted sometimes) www.svenskamagic.com/club_login.php (page stops at the same spot all the time and it's hard to login when posting data with the form. An interesting point is that when the page works and you make a faulty login it shows an error-output Wrong user/pass, but when the page doesn't work upon logging in, it doesn't. It's like it just reloads the page without any form data sent to it.(if the form data would be there it would leave the error mess)) www.svenskamagic.com/phpinfo.php (info about the server) [2002-03-17 11:50:01] [EMAIL PROTECTED] Sorry, don't mind my previous post. I had a bug in my template system. [2002-03-17 11:19:53] [EMAIL PROTECTED] I found an interesting detail. On my windows box running PHP 4.1.1 and Apache 1.3.23, it only stops on = signs. I had a template that has some = signs in it, and by replacing the first accurence, it goes on until the next one. I'm using output buffering, but it outputs the content anyway. The interesting fact is that it only turncates the output while echoing the buffer. [2002-03-14 04:02:44] [EMAIL PROTECTED] Apologies for not including web server details (did so in another post on another bug). Apache 1.3.20 with PHP as a DSO (no CGI compile). My local Unix guru has suggested trying a more recent Apache release which I will do when I get chance. I haven't tried with 4.0.6 pre-file upload and I am loathed to do so as I've now built PHP about a dozen times in the last week or so. I don't have access to another linux ditro unfortunately although we are running a production environment on Solaris. I haven't tried anything on that yet due to its production status but can do if it helps. GCC details (gcc -v) Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs gcc version 2.96 2731 (Red Hat Linux 7.1 2.96-98) 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/14529 -- Edit this bug report at http://bugs.php.net/?id=14529edit=1
Bug #14529 Updated: script doesn't always finish output
ID: 14529
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Critical
Bug Type: Output Control
Operating System: Linux RH 7.2
PHP Version: 4.3.0-dev
New Comment:
Apologies for not including web server details (did so in another post
on another bug). Apache 1.3.20 with PHP as a DSO (no CGI compile). My
local Unix guru has suggested trying a more recent Apache release which
I will do when I get chance.
I haven't tried with 4.0.6 pre-file upload and I am loathed to do so as
I've now built PHP about a dozen times in the last week or so.
I don't have access to another linux ditro unfortunately although we
are running a production environment on Solaris. I haven't tried
anything on that yet due to its production status but can do if it
helps.
GCC details (gcc -v)
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
gcc version 2.96 2731 (Red Hat Linux 7.1 2.96-98)
Previous Comments:
[2002-03-13 17:27:27] [EMAIL PROTECTED]
We MAY have seen a similar problem (not using Zend Optimizer, though --
whew!). We had problems with locutions like
function postprocess($buf)
{
$buf = preg_replace(/some stuff/,some other stuff,$buf);
return $buf;
}
ob_start(postprocess);
Changing the postprocess function to
function postprocess($ibuf)
{
$obuf = preg_replace(/some stuff/,some other stuff,$ibuf);
return $obuf;
}
seems to have eliminated the problem.
[2002-03-13 10:41:37] [EMAIL PROTECTED]
A question for [EMAIL PROTECTED] :
Did you try it before the patch was applied in 4.0.6
Of the pages giving me grief, some of them have forms and some of them
don't.
I don't have the access at my end to try my scripts on a different
linux version.
[2002-03-13 08:57:03] [EMAIL PROTECTED]
i faintly remember issues with the gcc version
RedHat uses (experimental gcc prerelease from
their own labs or something)
there were definetly problems in the past that
where RedHat-only :(
do you have a chance to test on another linux
distribution or to compile on another one and
transfer the binaries to your RH system?
[2002-03-13 08:31:53] [EMAIL PROTECTED]
Which webserver and version do you use?
Derick
[2002-03-13 08:19:41] [EMAIL PROTECTED]
Further to my previous comment. I downgraded to 4.0.6 with the last
file upload patch and I am still getting the problem.
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/14529
--
Edit this bug report at http://bugs.php.net/?id=14529edit=1
Bug #14529 Updated: script doesn't always finish output
ID: 14529 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Critical Bug Type: Output Control Operating System: Linux RH 7.2 PHP Version: 4.3.0-dev New Comment: RH 7.2 / PHP 4.1.1 4.1.2 (tried both). My one comment that may be useful is that I am only having this problem on pages that include HTML forms and form elements. If I remove a few form elements from a form it happily renders the page. I have a few very simple pages that contain very little in the way of PHP but keep getting truncated at certain points. No segfault and no errors in the log files to correspond to the time of the failure. There doesn't seem to be a particular pattern or size issue. I've tried other recommendations in this group but have not been able to get any success. There seems to be a size issue somewhere of some sort because I stripped a page back a line at a time until it all rendered, and then started adding in extra PHP until it started truncating again. Please e-mail me if you would like the HTML/PHP pages that contain the HTML forms. In the mean time I heading for PHP 4.0.6... Previous Comments: [2002-03-10 17:02:02] [EMAIL PROTECTED] Tried the new snapshot (4.3.0-dev) and the crash still occurs. As I work things through I am wondering if it is a problem with sessions hashes being used. For example I will have $_SESSION['prefs']['page_name1'] set and $_SESSION['prefs']['page_name2'] set and if page_name2 is no longer needed it will unset($_SESSION['prefs']['page_name2']). Could this be causing the problem in anything newer than PHP4.0.6 ??? [2002-03-04 14:52:55] [EMAIL PROTECTED] Yasuo - nope. I'm *using* sessions, but the pages that crash it aren't doing any creating, destroying or unsetting. In any case, I've been running this morning's snapshot all day without any problems. It seems to have been fixed (the POST problems went away as well). Thanks. [2002-03-04 04:38:12] [EMAIL PROTECTED] Can you please try a shapshot from snaps.php.net, my guess is that this is already fixed. Derick [2002-03-04 00:55:05] [EMAIL PROTECTED] It looks you are having session bug. It seems you are unset()ing $HTTP_SESSION_VARS or $_SESSION somewhere in your script, aren't you? [2002-03-03 21:12:33] [EMAIL PROTECTED] I'm seeing the same problem with 4.1.2. Can reproduce, but with no consistency. I'm also seeing a problem where PHP isn't responded to POSTs (watching it in ethereal, I had to post repeatedly to get a response; the responding page was to set a couple cookies and do a redirect). Any possibility that they might be related? (Had added a comment with a backtrace, but this one looks much more useful): #0 0x402ad693 in _zend_is_inconsistent (ht=0x0, file=0x403fcb84 zend_hash.c, line=975) at zend_hash.c:84 #1 0x402aff9f in zend_hash_internal_pointer_reset_ex (ht=0x0, pos=0xb090) at zend_hash.c:975 #2 0x4031da18 in php_session_save_current_state () at session.c:544 #3 0x40320579 in php_session_flush () at session.c:1381 #4 0x403205bd in zm_deactivate_session (type=1, module_number=3) at session.c:1393 #5 0x402ac614 in module_registry_cleanup (module=0x8054dc8) at zend_API.c:1165 #6 0x402af394 in zend_hash_apply (ht=0x404808c0, apply_func=0x402ac5d0 module_registry_cleanup) at zend_hash.c:669 #7 0x402a8a4e in zend_deactivate_modules () at zend.c:585 #8 0x402b9eb0 in php_request_shutdown (dummy=0x0) at main.c:723 #9 0x402b63ff in apache_php_module_main (r=0x80ab44c, display_source_mode=0) at sapi_apache.c:96 #10 0x402b71d0 in send_php (r=0x80ab44c, display_source_mode=0, filename=0x80ab9cc /usr/local/apache/htdocs/planworld/index.php) at mod_php4.c:575 #11 0x402b724c in send_parsed_php (r=0x80ab44c) at mod_php4.c:590 #12 0x4004b743 in _ufc_foobar () from /lib/libcrypt.so.1 #13 0x400630b9 in ?? () from /lib/libdb.so.3 #14 0x40063529 in ?? () from /lib/libdb.so.3 #15 0x400354e2 in ?? () from /lib/libcrypt.so.1 #16 0x4004b743 in _ufc_foobar () from /lib/libcrypt.so.1 #17 0x400630b9 in ?? () from /lib/libdb.so.3 #18 0x4006312f in ?? () from /lib/libdb.so.3 #19 0x4005910d in _ufc_foobar () from /lib/libcrypt.so.1 #20 0x400592e3 in _ufc_foobar () from /lib/libcrypt.so.1 #21 0x40059476 in _ufc_foobar () from /lib/libcrypt.so.1 #22 0x40059c34 in _ufc_foobar () from /lib/libcrypt.so.1 #23 0x4005a645 in _ufc_foobar () from /lib/libcrypt.so.1 #24 0x80486dd in ?? () from /usr/local/apache/libexec/mod_caucho.so #25 0x401589cb in __gconv_transform_internal_utf16 (step=0x80486c0,
Bug #14529 Updated: script doesn't always finish output
ID: 14529 Updated by: [EMAIL PROTECTED] -Summary: script doesn't always finish output Reported By: [EMAIL PROTECTED] Status: Critical Bug Type: Output Control Operating System: Linux RH 7.2 PHP Version: 4.3.0-dev New Comment: Which webserver and version do you use? Derick Previous Comments: [2002-03-13 08:19:41] [EMAIL PROTECTED] Further to my previous comment. I downgraded to 4.0.6 with the last file upload patch and I am still getting the problem. [2002-03-13 07:10:42] [EMAIL PROTECTED] RH 7.2 / PHP 4.1.1 4.1.2 (tried both). My one comment that may be useful is that I am only having this problem on pages that include HTML forms and form elements. If I remove a few form elements from a form it happily renders the page. I have a few very simple pages that contain very little in the way of PHP but keep getting truncated at certain points. No segfault and no errors in the log files to correspond to the time of the failure. There doesn't seem to be a particular pattern or size issue. I've tried other recommendations in this group but have not been able to get any success. There seems to be a size issue somewhere of some sort because I stripped a page back a line at a time until it all rendered, and then started adding in extra PHP until it started truncating again. Please e-mail me if you would like the HTML/PHP pages that contain the HTML forms. In the mean time I heading for PHP 4.0.6... [2002-03-10 17:02:02] [EMAIL PROTECTED] Tried the new snapshot (4.3.0-dev) and the crash still occurs. As I work things through I am wondering if it is a problem with sessions hashes being used. For example I will have $_SESSION['prefs']['page_name1'] set and $_SESSION['prefs']['page_name2'] set and if page_name2 is no longer needed it will unset($_SESSION['prefs']['page_name2']). Could this be causing the problem in anything newer than PHP4.0.6 ??? [2002-03-04 14:52:55] [EMAIL PROTECTED] Yasuo - nope. I'm *using* sessions, but the pages that crash it aren't doing any creating, destroying or unsetting. In any case, I've been running this morning's snapshot all day without any problems. It seems to have been fixed (the POST problems went away as well). Thanks. [2002-03-04 04:38:12] [EMAIL PROTECTED] Can you please try a shapshot from snaps.php.net, my guess is that this is already fixed. Derick 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/14529 -- Edit this bug report at http://bugs.php.net/?id=14529edit=1
Bug #14529 Updated: script doesn't always finish output
ID: 14529 Updated by: [EMAIL PROTECTED] -Summary: script doesn't always finish output Reported By: [EMAIL PROTECTED] Status: Critical Bug Type: Output Control Operating System: Linux RH 7.2 PHP Version: 4.3.0-dev New Comment: i faintly remember issues with the gcc version RedHat uses (experimental gcc prerelease from their own labs or something) there were definetly problems in the past that where RedHat-only :( do you have a chance to test on another linux distribution or to compile on another one and transfer the binaries to your RH system? Previous Comments: [2002-03-13 08:31:53] [EMAIL PROTECTED] Which webserver and version do you use? Derick [2002-03-13 08:19:41] [EMAIL PROTECTED] Further to my previous comment. I downgraded to 4.0.6 with the last file upload patch and I am still getting the problem. [2002-03-13 07:10:42] [EMAIL PROTECTED] RH 7.2 / PHP 4.1.1 4.1.2 (tried both). My one comment that may be useful is that I am only having this problem on pages that include HTML forms and form elements. If I remove a few form elements from a form it happily renders the page. I have a few very simple pages that contain very little in the way of PHP but keep getting truncated at certain points. No segfault and no errors in the log files to correspond to the time of the failure. There doesn't seem to be a particular pattern or size issue. I've tried other recommendations in this group but have not been able to get any success. There seems to be a size issue somewhere of some sort because I stripped a page back a line at a time until it all rendered, and then started adding in extra PHP until it started truncating again. Please e-mail me if you would like the HTML/PHP pages that contain the HTML forms. In the mean time I heading for PHP 4.0.6... [2002-03-10 17:02:02] [EMAIL PROTECTED] Tried the new snapshot (4.3.0-dev) and the crash still occurs. As I work things through I am wondering if it is a problem with sessions hashes being used. For example I will have $_SESSION['prefs']['page_name1'] set and $_SESSION['prefs']['page_name2'] set and if page_name2 is no longer needed it will unset($_SESSION['prefs']['page_name2']). Could this be causing the problem in anything newer than PHP4.0.6 ??? [2002-03-04 14:52:55] [EMAIL PROTECTED] Yasuo - nope. I'm *using* sessions, but the pages that crash it aren't doing any creating, destroying or unsetting. In any case, I've been running this morning's snapshot all day without any problems. It seems to have been fixed (the POST problems went away as well). Thanks. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/14529 -- Edit this bug report at http://bugs.php.net/?id=14529edit=1
Bug #14529 Updated: script doesn't always finish output
ID: 14529 Updated by: [EMAIL PROTECTED] -Summary: script doesn't always finish output Reported By: [EMAIL PROTECTED] Status: Critical Bug Type: Output Control Operating System: Linux RH 7.2 PHP Version: 4.3.0-dev New Comment: A question for [EMAIL PROTECTED] : Did you try it before the patch was applied in 4.0.6 Of the pages giving me grief, some of them have forms and some of them don't. I don't have the access at my end to try my scripts on a different linux version. Previous Comments: [2002-03-13 08:57:03] [EMAIL PROTECTED] i faintly remember issues with the gcc version RedHat uses (experimental gcc prerelease from their own labs or something) there were definetly problems in the past that where RedHat-only :( do you have a chance to test on another linux distribution or to compile on another one and transfer the binaries to your RH system? [2002-03-13 08:31:53] [EMAIL PROTECTED] Which webserver and version do you use? Derick [2002-03-13 08:19:41] [EMAIL PROTECTED] Further to my previous comment. I downgraded to 4.0.6 with the last file upload patch and I am still getting the problem. [2002-03-13 07:10:42] [EMAIL PROTECTED] RH 7.2 / PHP 4.1.1 4.1.2 (tried both). My one comment that may be useful is that I am only having this problem on pages that include HTML forms and form elements. If I remove a few form elements from a form it happily renders the page. I have a few very simple pages that contain very little in the way of PHP but keep getting truncated at certain points. No segfault and no errors in the log files to correspond to the time of the failure. There doesn't seem to be a particular pattern or size issue. I've tried other recommendations in this group but have not been able to get any success. There seems to be a size issue somewhere of some sort because I stripped a page back a line at a time until it all rendered, and then started adding in extra PHP until it started truncating again. Please e-mail me if you would like the HTML/PHP pages that contain the HTML forms. In the mean time I heading for PHP 4.0.6... [2002-03-10 17:02:02] [EMAIL PROTECTED] Tried the new snapshot (4.3.0-dev) and the crash still occurs. As I work things through I am wondering if it is a problem with sessions hashes being used. For example I will have $_SESSION['prefs']['page_name1'] set and $_SESSION['prefs']['page_name2'] set and if page_name2 is no longer needed it will unset($_SESSION['prefs']['page_name2']). Could this be causing the problem in anything newer than PHP4.0.6 ??? 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/14529 -- Edit this bug report at http://bugs.php.net/?id=14529edit=1
Bug #14529 Updated: script doesn't always finish output
ID: 14529
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Critical
Bug Type: Output Control
Operating System: Linux RH 7.2
PHP Version: 4.3.0-dev
New Comment:
We MAY have seen a similar problem (not using Zend Optimizer, though --
whew!). We had problems with locutions like
function postprocess($buf)
{
$buf = preg_replace(/some stuff/,some other stuff,$buf);
return $buf;
}
ob_start(postprocess);
Changing the postprocess function to
function postprocess($ibuf)
{
$obuf = preg_replace(/some stuff/,some other stuff,$ibuf);
return $obuf;
}
seems to have eliminated the problem.
Previous Comments:
[2002-03-13 10:41:37] [EMAIL PROTECTED]
A question for [EMAIL PROTECTED] :
Did you try it before the patch was applied in 4.0.6
Of the pages giving me grief, some of them have forms and some of them
don't.
I don't have the access at my end to try my scripts on a different
linux version.
[2002-03-13 08:57:03] [EMAIL PROTECTED]
i faintly remember issues with the gcc version
RedHat uses (experimental gcc prerelease from
their own labs or something)
there were definetly problems in the past that
where RedHat-only :(
do you have a chance to test on another linux
distribution or to compile on another one and
transfer the binaries to your RH system?
[2002-03-13 08:31:53] [EMAIL PROTECTED]
Which webserver and version do you use?
Derick
[2002-03-13 08:19:41] [EMAIL PROTECTED]
Further to my previous comment. I downgraded to 4.0.6 with the last
file upload patch and I am still getting the problem.
[2002-03-13 07:10:42] [EMAIL PROTECTED]
RH 7.2 / PHP 4.1.1 4.1.2 (tried both).
My one comment that may be useful is that I am only having this problem
on pages that include HTML forms and form elements. If I remove a few
form elements from a form it happily renders the page.
I have a few very simple pages that contain very little in the way of
PHP but keep getting truncated at certain points.
No segfault and no errors in the log files to correspond to the time of
the failure.
There doesn't seem to be a particular pattern or size issue. I've
tried other recommendations in this group but have not been able to get
any success.
There seems to be a size issue somewhere of some sort because I
stripped a page back a line at a time until it all rendered, and then
started adding in extra PHP until it started truncating again.
Please e-mail me if you would like the HTML/PHP pages that contain the
HTML forms. In the mean time I heading for PHP 4.0.6...
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/14529
--
Edit this bug report at http://bugs.php.net/?id=14529edit=1
Bug #14529 Updated: script doesn't always finish output
ID: 14529
Updated by: [EMAIL PROTECTED]
-Summary: script doesn't always finish output
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: Output Control
Operating System: Linux RH 7.2
-PHP Version: 4.1.2
+PHP Version: 4.3.0-dev
New Comment:
Tried the new snapshot (4.3.0-dev) and the crash still occurs.
As I work things through I am wondering if it is a problem with
sessions hashes being used.
For example I will have $_SESSION['prefs']['page_name1'] set and
$_SESSION['prefs']['page_name2'] set and if page_name2 is no longer
needed it will unset($_SESSION['prefs']['page_name2']). Could this be
causing the problem in anything newer than PHP4.0.6 ???
Previous Comments:
[2002-03-04 14:52:55] [EMAIL PROTECTED]
Yasuo - nope. I'm *using* sessions, but the pages that crash it aren't
doing any creating, destroying or unsetting.
In any case, I've been running this morning's snapshot all day without
any problems. It seems to have been fixed (the POST problems went away
as well).
Thanks.
[2002-03-04 04:38:12] [EMAIL PROTECTED]
Can you please try a shapshot from snaps.php.net, my guess is that this
is already fixed.
Derick
[2002-03-04 00:55:05] [EMAIL PROTECTED]
It looks you are having session bug.
It seems you are unset()ing $HTTP_SESSION_VARS or $_SESSION somewhere
in your script, aren't you?
[2002-03-03 21:12:33] [EMAIL PROTECTED]
I'm seeing the same problem with 4.1.2. Can reproduce, but with no
consistency.
I'm also seeing a problem where PHP isn't responded to POSTs (watching
it in ethereal, I had to post
repeatedly to get a response; the responding page was to set a couple
cookies and do a redirect). Any
possibility that they might be related?
(Had added a comment with a backtrace, but this one looks much more
useful):
#0 0x402ad693 in _zend_is_inconsistent (ht=0x0,
file=0x403fcb84 zend_hash.c, line=975) at zend_hash.c:84
#1 0x402aff9f in zend_hash_internal_pointer_reset_ex (ht=0x0,
pos=0xb090)
at zend_hash.c:975
#2 0x4031da18 in php_session_save_current_state () at session.c:544
#3 0x40320579 in php_session_flush () at session.c:1381
#4 0x403205bd in zm_deactivate_session (type=1, module_number=3)
at session.c:1393
#5 0x402ac614 in module_registry_cleanup (module=0x8054dc8) at
zend_API.c:1165
#6 0x402af394 in zend_hash_apply (ht=0x404808c0,
apply_func=0x402ac5d0 module_registry_cleanup) at
zend_hash.c:669
#7 0x402a8a4e in zend_deactivate_modules () at zend.c:585
#8 0x402b9eb0 in php_request_shutdown (dummy=0x0) at main.c:723
#9 0x402b63ff in apache_php_module_main (r=0x80ab44c,
display_source_mode=0)
at sapi_apache.c:96
#10 0x402b71d0 in send_php (r=0x80ab44c, display_source_mode=0,
filename=0x80ab9cc /usr/local/apache/htdocs/planworld/index.php)
at mod_php4.c:575
#11 0x402b724c in send_parsed_php (r=0x80ab44c) at mod_php4.c:590
#12 0x4004b743 in _ufc_foobar () from /lib/libcrypt.so.1
#13 0x400630b9 in ?? () from /lib/libdb.so.3
#14 0x40063529 in ?? () from /lib/libdb.so.3
#15 0x400354e2 in ?? () from /lib/libcrypt.so.1
#16 0x4004b743 in _ufc_foobar () from /lib/libcrypt.so.1
#17 0x400630b9 in ?? () from /lib/libdb.so.3
#18 0x4006312f in ?? () from /lib/libdb.so.3
#19 0x4005910d in _ufc_foobar () from /lib/libcrypt.so.1
#20 0x400592e3 in _ufc_foobar () from /lib/libcrypt.so.1
#21 0x40059476 in _ufc_foobar () from /lib/libcrypt.so.1
#22 0x40059c34 in _ufc_foobar () from /lib/libcrypt.so.1
#23 0x4005a645 in _ufc_foobar () from /lib/libcrypt.so.1
#24 0x80486dd in ?? () from /usr/local/apache/libexec/mod_caucho.so
#25 0x401589cb in __gconv_transform_internal_utf16 (step=0x80486c0,
data=0x2,
inbuf=0xbaa4, inbufend=0x8048560 U\211åSè,
written=0x804877c,
do_flush=1073786464) at ../iconv/loop.c:151
[2002-03-03 20:56:34] [EMAIL PROTECTED]
I've been seeing the same thing in 4.1.2. In some cases, it partially
displays pages. In others (I think
this may be related), it doesn't acknowledge a POST until it's been
submitted multiple times (3 or 4
generally). Both behaviors are very inconsistent (they happen
frequently on a site with moderate use, but I
can't reproduce them).
Here's a backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x402ad693 in _zend_is_inconsistent (ht=0x5a5a5a5a,
file=0x403fcb84 zend_hash.c, line=975) at zend_hash.c:84
84 if (ht-inconsistent==HT_OK) {
(gdb) bt
#0 0x402ad693 in _zend_is_inconsistent (ht=0x5a5a5a5a,
file=0x403fcb84
Bug #14529 Updated: script doesn't always finish output
ID: 14529 Updated by: [EMAIL PROTECTED] -Summary: script doesn't always finish output Reported By: [EMAIL PROTECTED] -Status: Open +Status: Critical Bug Type: Output Control Operating System: Linux RH 7.2 PHP Version: 4.3.0-dev Previous Comments: [2002-03-10 17:02:02] [EMAIL PROTECTED] Tried the new snapshot (4.3.0-dev) and the crash still occurs. As I work things through I am wondering if it is a problem with sessions hashes being used. For example I will have $_SESSION['prefs']['page_name1'] set and $_SESSION['prefs']['page_name2'] set and if page_name2 is no longer needed it will unset($_SESSION['prefs']['page_name2']). Could this be causing the problem in anything newer than PHP4.0.6 ??? [2002-03-04 14:52:55] [EMAIL PROTECTED] Yasuo - nope. I'm *using* sessions, but the pages that crash it aren't doing any creating, destroying or unsetting. In any case, I've been running this morning's snapshot all day without any problems. It seems to have been fixed (the POST problems went away as well). Thanks. [2002-03-04 04:38:12] [EMAIL PROTECTED] Can you please try a shapshot from snaps.php.net, my guess is that this is already fixed. Derick [2002-03-04 00:55:05] [EMAIL PROTECTED] It looks you are having session bug. It seems you are unset()ing $HTTP_SESSION_VARS or $_SESSION somewhere in your script, aren't you? [2002-03-03 21:12:33] [EMAIL PROTECTED] I'm seeing the same problem with 4.1.2. Can reproduce, but with no consistency. I'm also seeing a problem where PHP isn't responded to POSTs (watching it in ethereal, I had to post repeatedly to get a response; the responding page was to set a couple cookies and do a redirect). Any possibility that they might be related? (Had added a comment with a backtrace, but this one looks much more useful): #0 0x402ad693 in _zend_is_inconsistent (ht=0x0, file=0x403fcb84 zend_hash.c, line=975) at zend_hash.c:84 #1 0x402aff9f in zend_hash_internal_pointer_reset_ex (ht=0x0, pos=0xb090) at zend_hash.c:975 #2 0x4031da18 in php_session_save_current_state () at session.c:544 #3 0x40320579 in php_session_flush () at session.c:1381 #4 0x403205bd in zm_deactivate_session (type=1, module_number=3) at session.c:1393 #5 0x402ac614 in module_registry_cleanup (module=0x8054dc8) at zend_API.c:1165 #6 0x402af394 in zend_hash_apply (ht=0x404808c0, apply_func=0x402ac5d0 module_registry_cleanup) at zend_hash.c:669 #7 0x402a8a4e in zend_deactivate_modules () at zend.c:585 #8 0x402b9eb0 in php_request_shutdown (dummy=0x0) at main.c:723 #9 0x402b63ff in apache_php_module_main (r=0x80ab44c, display_source_mode=0) at sapi_apache.c:96 #10 0x402b71d0 in send_php (r=0x80ab44c, display_source_mode=0, filename=0x80ab9cc /usr/local/apache/htdocs/planworld/index.php) at mod_php4.c:575 #11 0x402b724c in send_parsed_php (r=0x80ab44c) at mod_php4.c:590 #12 0x4004b743 in _ufc_foobar () from /lib/libcrypt.so.1 #13 0x400630b9 in ?? () from /lib/libdb.so.3 #14 0x40063529 in ?? () from /lib/libdb.so.3 #15 0x400354e2 in ?? () from /lib/libcrypt.so.1 #16 0x4004b743 in _ufc_foobar () from /lib/libcrypt.so.1 #17 0x400630b9 in ?? () from /lib/libdb.so.3 #18 0x4006312f in ?? () from /lib/libdb.so.3 #19 0x4005910d in _ufc_foobar () from /lib/libcrypt.so.1 #20 0x400592e3 in _ufc_foobar () from /lib/libcrypt.so.1 #21 0x40059476 in _ufc_foobar () from /lib/libcrypt.so.1 #22 0x40059c34 in _ufc_foobar () from /lib/libcrypt.so.1 #23 0x4005a645 in _ufc_foobar () from /lib/libcrypt.so.1 #24 0x80486dd in ?? () from /usr/local/apache/libexec/mod_caucho.so #25 0x401589cb in __gconv_transform_internal_utf16 (step=0x80486c0, data=0x2, inbuf=0xbaa4, inbufend=0x8048560 U\211åSè, written=0x804877c, do_flush=1073786464) at ../iconv/loop.c:151 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/14529 -- Edit this bug report at http://bugs.php.net/?id=14529edit=1
Bug #14529 Updated: script doesn't always finish output
ID: 14529
Updated by: [EMAIL PROTECTED]
-Summary: script doesn't always finish output
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Output Control
Operating System: Linux RH 7.2
PHP Version: 4.1.2
New Comment:
Can you please try a shapshot from snaps.php.net, my guess is that this
is already fixed.
Derick
Previous Comments:
[2002-03-04 00:55:05] [EMAIL PROTECTED]
It looks you are having session bug.
It seems you are unset()ing $HTTP_SESSION_VARS or $_SESSION somewhere
in your script, aren't you?
[2002-03-03 21:12:33] [EMAIL PROTECTED]
I'm seeing the same problem with 4.1.2. Can reproduce, but with no
consistency.
I'm also seeing a problem where PHP isn't responded to POSTs (watching
it in ethereal, I had to post
repeatedly to get a response; the responding page was to set a couple
cookies and do a redirect). Any
possibility that they might be related?
(Had added a comment with a backtrace, but this one looks much more
useful):
#0 0x402ad693 in _zend_is_inconsistent (ht=0x0,
file=0x403fcb84 zend_hash.c, line=975) at zend_hash.c:84
#1 0x402aff9f in zend_hash_internal_pointer_reset_ex (ht=0x0,
pos=0xb090)
at zend_hash.c:975
#2 0x4031da18 in php_session_save_current_state () at session.c:544
#3 0x40320579 in php_session_flush () at session.c:1381
#4 0x403205bd in zm_deactivate_session (type=1, module_number=3)
at session.c:1393
#5 0x402ac614 in module_registry_cleanup (module=0x8054dc8) at
zend_API.c:1165
#6 0x402af394 in zend_hash_apply (ht=0x404808c0,
apply_func=0x402ac5d0 module_registry_cleanup) at
zend_hash.c:669
#7 0x402a8a4e in zend_deactivate_modules () at zend.c:585
#8 0x402b9eb0 in php_request_shutdown (dummy=0x0) at main.c:723
#9 0x402b63ff in apache_php_module_main (r=0x80ab44c,
display_source_mode=0)
at sapi_apache.c:96
#10 0x402b71d0 in send_php (r=0x80ab44c, display_source_mode=0,
filename=0x80ab9cc /usr/local/apache/htdocs/planworld/index.php)
at mod_php4.c:575
#11 0x402b724c in send_parsed_php (r=0x80ab44c) at mod_php4.c:590
#12 0x4004b743 in _ufc_foobar () from /lib/libcrypt.so.1
#13 0x400630b9 in ?? () from /lib/libdb.so.3
#14 0x40063529 in ?? () from /lib/libdb.so.3
#15 0x400354e2 in ?? () from /lib/libcrypt.so.1
#16 0x4004b743 in _ufc_foobar () from /lib/libcrypt.so.1
#17 0x400630b9 in ?? () from /lib/libdb.so.3
#18 0x4006312f in ?? () from /lib/libdb.so.3
#19 0x4005910d in _ufc_foobar () from /lib/libcrypt.so.1
#20 0x400592e3 in _ufc_foobar () from /lib/libcrypt.so.1
#21 0x40059476 in _ufc_foobar () from /lib/libcrypt.so.1
#22 0x40059c34 in _ufc_foobar () from /lib/libcrypt.so.1
#23 0x4005a645 in _ufc_foobar () from /lib/libcrypt.so.1
#24 0x80486dd in ?? () from /usr/local/apache/libexec/mod_caucho.so
#25 0x401589cb in __gconv_transform_internal_utf16 (step=0x80486c0,
data=0x2,
inbuf=0xbaa4, inbufend=0x8048560 U\211åSè,
written=0x804877c,
do_flush=1073786464) at ../iconv/loop.c:151
[2002-03-03 20:56:34] [EMAIL PROTECTED]
I've been seeing the same thing in 4.1.2. In some cases, it partially
displays pages. In others (I think
this may be related), it doesn't acknowledge a POST until it's been
submitted multiple times (3 or 4
generally). Both behaviors are very inconsistent (they happen
frequently on a site with moderate use, but I
can't reproduce them).
Here's a backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x402ad693 in _zend_is_inconsistent (ht=0x5a5a5a5a,
file=0x403fcb84 zend_hash.c, line=975) at zend_hash.c:84
84 if (ht-inconsistent==HT_OK) {
(gdb) bt
#0 0x402ad693 in _zend_is_inconsistent (ht=0x5a5a5a5a,
file=0x403fcb84
ýÿþýÿýÿ\025?ýÿG?F?ýÿýÿk?l?\205uTvýÿÌ?ýÿUvýÿË?§v¨vù?ýÿýÿýÿýÿx@z@u@ýÿv@w@ýÿýÿê@î@í@ýÿì@\017yýÿýÿ\204A\205A\203Aýÿ¼A½AÔAýÿýÿýÿýÿUBýÿPBLBHBýÿSBýÿWBTBNBJBQBýÿýÿIBKBcBýÿýÿ§B¦B¤Býÿýÿýÿä|å|ýÿýÿe~N~\027Cýÿ\026CýÿýÿcCýÿýÿ\202\177ýÿ{C|Cýÿ...,
line=975) at zend_hash.c:84
#1 0x4046b258 in ?? () from /usr/local/apache/libexec/libphp4.so
#2 0x402aff9f in zend_hash_internal_pointer_reset_ex (ht=0x5a5a5a5a,
pos=0xb090) at zend_hash.c:975
First symbol in segment of executable not a source symbol
[2002-02-28 17:15:48] [EMAIL PROTECTED]
Regarding the configure line and your MySQL problems. You should NEVER
(okay this is my opinion) use the bundled MySQL libs. On your
configure line you should do
--with-mysql=/usr | --with-mysql=/usr/local
Just depends on where it put your libs, which you can find like so
[root@somemachine /]# ldconfig -p | grep mysql
libmysqlclient.so.10 (libc6) =
Bug #14529 Updated: script doesn't always finish output
ID: 14529
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Output Control
Operating System: Linux RH 7.2
PHP Version: 4.1.2
New Comment:
I've been seeing the same thing in 4.1.2. In some cases, it partially
displays pages. In others (I think
this may be related), it doesn't acknowledge a POST until it's been
submitted multiple times (3 or 4
generally). Both behaviors are very inconsistent (they happen
frequently on a site with moderate use, but I
can't reproduce them).
Here's a backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x402ad693 in _zend_is_inconsistent (ht=0x5a5a5a5a,
file=0x403fcb84 zend_hash.c, line=975) at zend_hash.c:84
84 if (ht-inconsistent==HT_OK) {
(gdb) bt
#0 0x402ad693 in _zend_is_inconsistent (ht=0x5a5a5a5a,
file=0x403fcb84
ýÿþýÿýÿ\025?ýÿG?F?ýÿýÿk?l?\205uTvýÿÌ?ýÿUvýÿË?§v¨vù?ýÿýÿýÿýÿx@z@u@ýÿv@w@ýÿýÿê@î@í@ýÿì@\017yýÿýÿ\204A\205A\203Aýÿ¼A½AÔAýÿýÿýÿýÿUBýÿPBLBHBýÿSBýÿWBTBNBJBQBýÿýÿIBKBcBýÿýÿ§B¦B¤Býÿýÿýÿä|å|ýÿýÿe~N~\027Cýÿ\026CýÿýÿcCýÿýÿ\202\177ýÿ{C|Cýÿ...,
line=975) at zend_hash.c:84
#1 0x4046b258 in ?? () from /usr/local/apache/libexec/libphp4.so
#2 0x402aff9f in zend_hash_internal_pointer_reset_ex (ht=0x5a5a5a5a,
pos=0xb090) at zend_hash.c:975
First symbol in segment of executable not a source symbol
Previous Comments:
[2002-02-28 17:15:48] [EMAIL PROTECTED]
Regarding the configure line and your MySQL problems. You should NEVER
(okay this is my opinion) use the bundled MySQL libs. On your
configure line you should do
--with-mysql=/usr | --with-mysql=/usr/local
Just depends on where it put your libs, which you can find like so
[root@somemachine /]# ldconfig -p | grep mysql
libmysqlclient.so.10 (libc6) =
/usr/local/lib/mysql/libmysqlclient.so.10
libmysqlclient.so (libc6) =
/usr/local/lib/mysql/libmysqlclient.so
I think the RPM puts it in /usr.
-Chris
[2002-02-28 16:27:48] [EMAIL PROTECTED]
We are getting closer, I've got a small team of people at this end
working on solving this bug and are now trying to dedicate much more
time and money into getting this bug solved! (Our business success
depends on it) The problem, we only know PHP programming well and are
weaker in the server end of things (I'm the only one with some Linux
knowledge) so we need your help to solve this. Here is a summary of
all things done so far to narrow this down (much already due to your
help). We've seperated everything into sections below.
PROBLEM:
While running some more complex PHP scripts they will not work on
anything newer than 4.0.6 but works 100% on 4.0 - 4.0.6. The page
simply stops displaying part ways through a script (usually right in
the middle of an echo statement or between echo statements). The
script seemed to finish commands past the point of where it stopped but
is only known through the sessions (seeing nothing else is being
displayed to screen) But, we've discovered when this crash happens
where it has been giving us problems as well so we can not confirm this
anymore.
APACHE ERROR_LOG:
When a page is loaded with my problem scripts I get either 1 or 2
errors in my apache error_log:
[date] [notice] child pid exit signal Segmentation fault (11)
(if two errors the second is the same except different pid number)
SCRIPTS CAUSING CRASHES:
These scripts that cause the problems have been in development for
almost 3 years now and are fairly complex. Not all scripts give me
hassles, but from the tests I have done, it appears only scripts that
have sessions AND use fairly large hashes (passed into and out from
sessions via serialize() functions) is where I have problems. Even
complex or large scripts without this in it seem to run fine. All
scripts run fine in PHP versions 4.0.6 or older but not since 4.1.0 or
newer (up to 4.2.2)
PHP compiling configurations:
Have tried compiling with various combinations of options trying to
narrow down if a particular option is what is causing the problems. So
far I can not find anything consistent.
GDB RESULTS:
You gave me the link to the generating bug-traces and I'm having
problems getting it to run apache properly.
I could not find a core file on my server. (Apache isn't generating
them, or I simply can not find them). So I've been using your
suggested method of running the script through gdb itself. Here is
what I've done so far.
Stopped the apache server (tested going to web page and confirmed it
was down), I then typed:
gdb /usr/sbin/httpd
run -X (from inside the gdb prompt)
It then says it's starting /usr/sbin/httpd with a new thread and then
starts a new blank line (while it's waiting for an apache crash
signal).
If at this point I use my browser
Bug #14529 Updated: script doesn't always finish output
ID: 14529
Updated by: [EMAIL PROTECTED]
-Summary: script doesn't always finish output
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: Output Control
Operating System: Linux RH 7.2
PHP Version: 4.1.2
New Comment:
It looks you are having session bug.
It seems you are unset()ing $HTTP_SESSION_VARS or $_SESSION somewhere
in your script, aren't you?
Previous Comments:
[2002-03-03 21:12:33] [EMAIL PROTECTED]
I'm seeing the same problem with 4.1.2. Can reproduce, but with no
consistency.
I'm also seeing a problem where PHP isn't responded to POSTs (watching
it in ethereal, I had to post
repeatedly to get a response; the responding page was to set a couple
cookies and do a redirect). Any
possibility that they might be related?
(Had added a comment with a backtrace, but this one looks much more
useful):
#0 0x402ad693 in _zend_is_inconsistent (ht=0x0,
file=0x403fcb84 zend_hash.c, line=975) at zend_hash.c:84
#1 0x402aff9f in zend_hash_internal_pointer_reset_ex (ht=0x0,
pos=0xb090)
at zend_hash.c:975
#2 0x4031da18 in php_session_save_current_state () at session.c:544
#3 0x40320579 in php_session_flush () at session.c:1381
#4 0x403205bd in zm_deactivate_session (type=1, module_number=3)
at session.c:1393
#5 0x402ac614 in module_registry_cleanup (module=0x8054dc8) at
zend_API.c:1165
#6 0x402af394 in zend_hash_apply (ht=0x404808c0,
apply_func=0x402ac5d0 module_registry_cleanup) at
zend_hash.c:669
#7 0x402a8a4e in zend_deactivate_modules () at zend.c:585
#8 0x402b9eb0 in php_request_shutdown (dummy=0x0) at main.c:723
#9 0x402b63ff in apache_php_module_main (r=0x80ab44c,
display_source_mode=0)
at sapi_apache.c:96
#10 0x402b71d0 in send_php (r=0x80ab44c, display_source_mode=0,
filename=0x80ab9cc /usr/local/apache/htdocs/planworld/index.php)
at mod_php4.c:575
#11 0x402b724c in send_parsed_php (r=0x80ab44c) at mod_php4.c:590
#12 0x4004b743 in _ufc_foobar () from /lib/libcrypt.so.1
#13 0x400630b9 in ?? () from /lib/libdb.so.3
#14 0x40063529 in ?? () from /lib/libdb.so.3
#15 0x400354e2 in ?? () from /lib/libcrypt.so.1
#16 0x4004b743 in _ufc_foobar () from /lib/libcrypt.so.1
#17 0x400630b9 in ?? () from /lib/libdb.so.3
#18 0x4006312f in ?? () from /lib/libdb.so.3
#19 0x4005910d in _ufc_foobar () from /lib/libcrypt.so.1
#20 0x400592e3 in _ufc_foobar () from /lib/libcrypt.so.1
#21 0x40059476 in _ufc_foobar () from /lib/libcrypt.so.1
#22 0x40059c34 in _ufc_foobar () from /lib/libcrypt.so.1
#23 0x4005a645 in _ufc_foobar () from /lib/libcrypt.so.1
#24 0x80486dd in ?? () from /usr/local/apache/libexec/mod_caucho.so
#25 0x401589cb in __gconv_transform_internal_utf16 (step=0x80486c0,
data=0x2,
inbuf=0xbaa4, inbufend=0x8048560 U\211åSè,
written=0x804877c,
do_flush=1073786464) at ../iconv/loop.c:151
[2002-03-03 20:56:34] [EMAIL PROTECTED]
I've been seeing the same thing in 4.1.2. In some cases, it partially
displays pages. In others (I think
this may be related), it doesn't acknowledge a POST until it's been
submitted multiple times (3 or 4
generally). Both behaviors are very inconsistent (they happen
frequently on a site with moderate use, but I
can't reproduce them).
Here's a backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x402ad693 in _zend_is_inconsistent (ht=0x5a5a5a5a,
file=0x403fcb84 zend_hash.c, line=975) at zend_hash.c:84
84 if (ht-inconsistent==HT_OK) {
(gdb) bt
#0 0x402ad693 in _zend_is_inconsistent (ht=0x5a5a5a5a,
file=0x403fcb84
ýÿþýÿýÿ\025?ýÿG?F?ýÿýÿk?l?\205uTvýÿÌ?ýÿUvýÿË?§v¨vù?ýÿýÿýÿýÿx@z@u@ýÿv@w@ýÿýÿê@î@í@ýÿì@\017yýÿýÿ\204A\205A\203Aýÿ¼A½AÔAýÿýÿýÿýÿUBýÿPBLBHBýÿSBýÿWBTBNBJBQBýÿýÿIBKBcBýÿýÿ§B¦B¤Býÿýÿýÿä|å|ýÿýÿe~N~\027Cýÿ\026CýÿýÿcCýÿýÿ\202\177ýÿ{C|Cýÿ...,
line=975) at zend_hash.c:84
#1 0x4046b258 in ?? () from /usr/local/apache/libexec/libphp4.so
#2 0x402aff9f in zend_hash_internal_pointer_reset_ex (ht=0x5a5a5a5a,
pos=0xb090) at zend_hash.c:975
First symbol in segment of executable not a source symbol
[2002-02-28 17:15:48] [EMAIL PROTECTED]
Regarding the configure line and your MySQL problems. You should NEVER
(okay this is my opinion) use the bundled MySQL libs. On your
configure line you should do
--with-mysql=/usr | --with-mysql=/usr/local
Just depends on where it put your libs, which you can find like so
[root@somemachine /]# ldconfig -p | grep mysql
libmysqlclient.so.10 (libc6) =
/usr/local/lib/mysql/libmysqlclient.so.10
libmysqlclient.so (libc6) =
/usr/local/lib/mysql/libmysqlclient.so
I think the RPM puts it in /usr.
-Chris
Bug #14529 Updated: script doesn't always finish output
ID: 14529 Updated by: [EMAIL PROTECTED] -Summary: script doesn't always finish output Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Output Control Operating System: Linux RH 7.2 -PHP Version: 4.1.1 +PHP Version: 4.1.2 New Comment: We are getting closer, I've got a small team of people at this end working on solving this bug and are now trying to dedicate much more time and money into getting this bug solved! (Our business success depends on it) The problem, we only know PHP programming well and are weaker in the server end of things (I'm the only one with some Linux knowledge) so we need your help to solve this. Here is a summary of all things done so far to narrow this down (much already due to your help). We've seperated everything into sections below. PROBLEM: While running some more complex PHP scripts they will not work on anything newer than 4.0.6 but works 100% on 4.0 - 4.0.6. The page simply stops displaying part ways through a script (usually right in the middle of an echo statement or between echo statements). The script seemed to finish commands past the point of where it stopped but is only known through the sessions (seeing nothing else is being displayed to screen) But, we've discovered when this crash happens where it has been giving us problems as well so we can not confirm this anymore. APACHE ERROR_LOG: When a page is loaded with my problem scripts I get either 1 or 2 errors in my apache error_log: [date] [notice] child pid exit signal Segmentation fault (11) (if two errors the second is the same except different pid number) SCRIPTS CAUSING CRASHES: These scripts that cause the problems have been in development for almost 3 years now and are fairly complex. Not all scripts give me hassles, but from the tests I have done, it appears only scripts that have sessions AND use fairly large hashes (passed into and out from sessions via serialize() functions) is where I have problems. Even complex or large scripts without this in it seem to run fine. All scripts run fine in PHP versions 4.0.6 or older but not since 4.1.0 or newer (up to 4.2.2) PHP compiling configurations: Have tried compiling with various combinations of options trying to narrow down if a particular option is what is causing the problems. So far I can not find anything consistent. GDB RESULTS: You gave me the link to the generating bug-traces and I'm having problems getting it to run apache properly. I could not find a core file on my server. (Apache isn't generating them, or I simply can not find them). So I've been using your suggested method of running the script through gdb itself. Here is what I've done so far. Stopped the apache server (tested going to web page and confirmed it was down), I then typed: gdb /usr/sbin/httpd run -X (from inside the gdb prompt) It then says it's starting /usr/sbin/httpd with a new thread and then starts a new blank line (while it's waiting for an apache crash signal). If at this point I use my browser and go to plain html web page it works (so that tells me the apache server is running again), BUT if I go to a php page, I get a page not available error. This means I am unable to load the pages that will make apache crash. What am I doing wrong to get apache running with PHP through the gdb? Also, once httpd is started through gdb, how do I stop it and exit gdb - I can CNTL-C but apache keeps running and I can't find the process to kill it. There must be a cleaner way. Previous Comments: [2002-02-18 13:29:41] [EMAIL PROTECTED] I think i had something similar happen to me. It would just stop printing to the screen and either spit out crazy characters or stop altogether. I commented out every line and brought it back one by one until i located the problem. Although i'm still not exactly sure what's going on I might have a solution. (worked in my case) I put a flush() every now and then. It seemed to fix the problem. [2002-02-15 20:23:31] [EMAIL PROTECTED] I've followed the instructions on the gdb backtrace page but I can not find a core file anywhere on the site. When I tried running httpd -X in the gdb itself I can not access the page. I'm using RedHat 7.2 on my test server. I ran the command (to test it) /usr/sbin/httpd -X and it starts fine and no prompt comes back (which I think is normal). The moment I open a webpage it returns the line: Segmentation fault and then goes back to the command prompt. So this would tell me I found the right command line to run but when I try: gdb /usr/sbin/httpd run -X (from inside the gdb prompt) it says starting new thread and then locks up. If I try opening a web page it comes up as not found (just like it does when the httpd
Bug #14529 Updated: script doesn't always finish output
ID: 14529 Updated by: [EMAIL PROTECTED] -Summary: script doesn't always finish output Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Output Control Operating System: Linux RH 7.2 PHP Version: 4.1.1 New Comment: I've followed the instructions on the gdb backtrace page but I can not find a core file anywhere on the site. When I tried running httpd -X in the gdb itself I can not access the page. I'm using RedHat 7.2 on my test server. I ran the command (to test it) /usr/sbin/httpd -X and it starts fine and no prompt comes back (which I think is normal). The moment I open a webpage it returns the line: Segmentation fault and then goes back to the command prompt. So this would tell me I found the right command line to run but when I try: gdb /usr/sbin/httpd run -X (from inside the gdb prompt) it says starting new thread and then locks up. If I try opening a web page it comes up as not found (just like it does when the httpd server is not running at all). Any tips on what I'm doing wrong. At least I've finally confirmed it is PHP crashing. I've tried compiling with various options enabled or disabled. I've got the --enable-debug take and I did not set the --enable-trans-sid this time. Thanks Previous Comments: [2002-02-05 20:37:39] [EMAIL PROTECTED] To properly diagnose this bug, 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. [2002-02-05 18:55:06] [EMAIL PROTECTED] When I use simple little scripts it seems to work fine. The pages where I have problems is where there are dynamically called include_once and variable variables used. For me the output seemed to work at first with output.buffering on but it turns out there was problems on other pages then (that weren't bothered by it being off). And IE6 would simply load pages from cache of old pages (and Netscape would simply crash with a connection lost error) I also discovered that some environmental variables working with sessions would fail to if there was a tiny error on html output at least in one consistent test. Example: If I had page (such as index.php) generate a basic HTML page but within the html code generated there was an img tag with an image name that did not exist on the server anymore (I had renamed it and forgot to update that script). The browser just shows standard little box with x in it where image should be as usual. When this was happening, if I echoed the value of $HTTP_SERVER_VARS['PHP_SELF'] it would return index.php (or the name of the page). However, if I saved that value to a session, then even though a test before the script end showed it correctly set, upon reloading it would be set to the page name (image.gif). I have tried the compiling with AND without --enable-trans-sid and these errors still continue with no change. I have to keep my production server on php 4.0.6 as it simply is way to unreliable in 4.1.0 or newer (including 4.2.2-dev). I use a lot of serialize/unserialize and really was hoping to upgrade for the performance differences. [2002-02-05 18:38:03] [EMAIL PROTECTED] And what happens when you get rid of --enable-trans-sid from your confiugre line? [2002-02-05 18:36:38] [EMAIL PROTECTED] Anyone have short complete script for this bug? [2002-02-05 16:25:52] [EMAIL PROTECTED] I have verified this bug with the latest 4.2.0-dev version. Output problems are still the same: corrupt output with buffering off, and correct output with buffering on, without any HTTP GET variables. (http://ged.dynodns.net/band/index.php?func=articleoid=19288) But only on some pages, for some reason. (E.G. events.php never works) I'm backing up to 4.0.6 to get the site to a production status again. (If 4.0.6 doesn't work, I'll post again...) 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/14529 -- Edit this bug report at http://bugs.php.net/?id=14529edit=1
