From: Phil D. <ph...@di...> - 2006-07-25 09:54:24
|
I've just being testing SquirrelMail 1.4.7 with the PHP 5.2.0RC1 and am having some problems (I'm testing on a machine running SuSE 10.1). I can get the login page to appear ok, but when I login and get redirected to src/webmail.php, the browser reports that the network connection has broken. I guess that webmail.php is unexpectedly dying somewhere, but there are no clues in any of my logfiles. If I revert to an older version of php, things work fine. I also tested an older SquirrelMail (1.4.5) against this PHP RC, and had no problems. Can someone please have a look to see what's broken, or alternatively, give me some guidance as to what further tests I can perform to pin down the problem. The PHP 5.2.0RC1 source tarball can be downloaded from http://downloads.php.net/ilia/ and windows binary from http://downloads.php.net/edink/php-5.2.0RC1-Win32.zip Thanks -- Phil Driscoll |
From: Brian G. P. <br...@br...> - 2006-07-25 11:30:19
|
On Tuesday 25 July 2006 04:54, Phil Driscoll wrote: > Can someone please have a look to see what's broken, or alternatively, > give me some guidance as to what further tests I can perform to pin > down the problem. set error_reporting=E_ALL in php.ini, and restart apache. Then look either on the screen or in your apache error log. There are reports all over the internet about PHP 5.2.0RC1 breaking existing PHP code, so I'm not surprised that you're seeing problems with Squirrelmail too. The PHP core team doesn't always take much care for backward compatibility. Regards, - Brian |
From: Phil D. <ph...@di...> - 2006-07-25 11:33:22
|
On Tuesday 25 July 2006 12:29, Brian G. Peterson wrote: > On Tuesday 25 July 2006 04:54, Phil Driscoll wrote: > > Can someone please have a look to see what's broken, or alternatively, > > give me some guidance as to what further tests I can perform to pin > > down the problem. > > set > error_reporting=E_ALL > in php.ini, and restart apache. It is already set to E_ALL - but no errors are output anywhere I can find. -- Phil Driscoll |
From: Brian G. P. <br...@br...> - 2006-07-25 11:51:34
|
On Tuesday 25 July 2006 06:33, Phil Driscoll wrote: > On Tuesday 25 July 2006 12:29, Brian G. Peterson wrote: > > On Tuesday 25 July 2006 04:54, Phil Driscoll wrote: > > > Can someone please have a look to see what's broken, or > > > alternatively, give me some guidance as to what further tests I can > > > perform to pin down the problem. > > > > set > > error_reporting=E_ALL > > in php.ini, and restart apache. > > It is already set to E_ALL - but no errors are output anywhere I can > find. Well, errors should either be displaying on the screen or in your apache error log. Check the php and apache settings to figure out where the errors should be logging to, and look there. If things aren't working and aren't giving any error, then I'll say it's a bug in PHP 5.2.0RC1 : It's PHP's responsibility to tell you why it's failing to complete a page execution. That aside, your next step would be to use one of the PHP debuggers and step through the code to see where it fails. Regards, - Brian |
From: Tomas K. <to...@us...> - 2006-07-25 12:30:53
|
> I've just being testing SquirrelMail 1.4.7 with the PHP 5.2.0RC1 and am > having some problems (I'm testing on a machine running SuSE 10.1). > > I can get the login page to appear ok, but when I login and get redirected > to src/webmail.php, the browser reports that the network connection has > broken. > > I guess that webmail.php is unexpectedly dying somewhere, but there are no > clues in any of my logfiles. > > If I revert to an older version of php, things work fine. I also tested an > older SquirrelMail (1.4.5) against this PHP RC, and had no problems. > > Can someone please have a look to see what's broken, or alternatively, > give me > some guidance as to what further tests I can perform to pin down the > problem. > > The PHP 5.2.0RC1 source tarball can be downloaded from > http://downloads.php.net/ilia/ > and windows binary from > http://downloads.php.net/edink/php-5.2.0RC1-Win32.zip ... > Posting Guidelines: > http://www.squirrelmail.org/wiki/MailingListPostingGuidelines Used IMAP server, TLS or plain text IMAP connection, PHP configure line. SquirrelMail DB or flat file setup, list of enabled plugins, used browser, all non-standard PHP core and session settings. info about used zend extensions. Make sure that you restart Apache after you install new PHP version. One more suggestion - please stop asking to run unsigned code hosted on some user accounts. Yes, these accounts belong to PHP developers. No, we don't have information if these accounts are not broken. If you want us to run that code - show official message from PHP developers which confirms file md5sums. SquirrelMail 1.4.8cvs login works with 5.2.0rc2-dev snapshot. -- Tomas |
From: Phil D. <ph...@di...> - 2006-07-25 12:43:08
|
On Tuesday 25 July 2006 12:50, Brian G. Peterson wrote: > On Tuesday 25 July 2006 06:33, Phil Driscoll wrote: > > On Tuesday 25 July 2006 12:29, Brian G. Peterson wrote: > > > On Tuesday 25 July 2006 04:54, Phil Driscoll wrote: > > > > Can someone please have a look to see what's broken, or > > > > alternatively, give me some guidance as to what further tests I can > > > > perform to pin down the problem. > > > > > > set > > > error_reporting=E_ALL > > > in php.ini, and restart apache. > > > > It is already set to E_ALL - but no errors are output anywhere I can > > find. > > Well, errors should either be displaying on the screen or in your apache > error log. Check the php and apache settings to figure out where the > errors should be logging to, and look there. If I add a line at the start of login.php die($poo); I get a warning message about $poo not being defined, so I am sure that my E_ALL setting is ok. -- Phil Driscoll |
From: Brian G. P. <br...@br...> - 2006-07-25 13:24:33
|
On Tuesday 25 July 2006 07:42, Phil Driscoll wrote: > On Tuesday 25 July 2006 12:50, Brian G. Peterson wrote: > > On Tuesday 25 July 2006 06:33, Phil Driscoll wrote: > > > On Tuesday 25 July 2006 12:29, Brian G. Peterson wrote: > > > > On Tuesday 25 July 2006 04:54, Phil Driscoll wrote: > > > > > Can someone please have a look to see what's broken, or > > > > > alternatively, give me some guidance as to what further tests I > > > > > can perform to pin down the problem. > > > > > > > > set > > > > error_reporting=E_ALL > > > > in php.ini, and restart apache. > > > > > > It is already set to E_ALL - but no errors are output anywhere I > > > can find. > > > > Well, errors should either be displaying on the screen or in your > > apache error log. Check the php and apache settings to figure out > > where the errors should be logging to, and look there. > > If I add a line at the start of login.php > die($poo); > I get a warning message about $poo not being defined, so I am sure that > my E_ALL setting is ok. Then refer to my earlier post: Install a PHP debugger and step through the code. It is PHP's responsibility to tell you why it is stopping execution of a script. If PHP isn't reporting a fatal error, then the fault lies with PHP, or your PHP configuration. Stepping through the code may help you figure out specifically where the problem lies. PHP 5.2.0 has been widely reported to have problems with backwards compatibility. No one in their right mind who's been around PHP for a while would run a 5.2.0 release on a production machine for an enterprise application like Squirrelmail. *I* wouldn't even bother on a testing machine until PHP 5.2.1 was released, and one could assume that most of the worst bugs had been worked out. But that's just me, so I'm willing to play along in *your* troubleshooting. Regards, - Brian |
From: Phil D. <ph...@di...> - 2006-07-25 12:46:47
|
Thanks for all the hostility Tomas. Always heartwarming to get a telling off when all I'm doing is trying to help both the PHP and Squirrelmail projects. Perhaps it would be better for me to keep quiet and just let things go bang for SquirrelMail users when php 5.2.0 is released :( -- Phil Driscoll |
From: Tomas K. <to...@us...> - 2006-07-25 13:07:15
|
> Thanks for all the hostility Tomas. Always heartwarming to get a telling > off when all I'm doing is trying to help both the PHP and Squirrelmail > projects. > > Perhaps it would be better for me to keep quiet and just let things go > bang for SquirrelMail users when php 5.2.0 is released :( Posting Guidelines: http://www.squirrelmail.org/wiki/MailingListPostingGuidelines You haven't provided any useful information in your report. Only PHP version. We don't know what triggered PHP error. One way to debug your issue is to reproduce it on other machine. Can't do that, if you give only version number. There are many ways to misconfigure PHP settings and trigger some kind of issue. Your report only warns that there might be issues with newer PHP version and looks like cracker's attempt to push his or her code to other people. I don't want to be hostile. Sorry if you felt that way. Please provide information that allows to debug your issue. Or try to reproduce same issue on other machine. If you don't have other server for testing - get vmware or other virtualization software and retest your setup there. -- Tomas |
From: Thijs K. <ki...@sq...> - 2006-07-25 13:10:42
|
Phil, On Tue, 2006-07-25 at 13:46 +0100, Phil Driscoll wrote: > Thanks for all the hostility Tomas. Always heartwarming to get a telling = off=20 > when all I'm doing is trying to help both the PHP and Squirrelmail projec= ts. >=20 > Perhaps it would be better for me to keep quiet and just let things go ba= ng=20 > for SquirrelMail users when php 5.2.0 is released :( Tomas' style is direct and to-the-point. Maybe to the casual reader this may seem as hostile, but you should realise that he (and many other team members like myself) are not native English speakers so expressing ourselves in English isn't always as subtle as it might be. I can assure you that Tomas is not hostile and that he has done and does a lot to resolve bugs in SquirrelMail. While he works hard, his time is limited and so it really helps all of us if people provide as detailed information as possible so he can debug the problem efficiently. He's trying to get that information and nothing more. I understand that you're trying to help the projects, which is appreciated, but it would help to realise that the developers on this list are doing even more work for the software that you've been using for free for all that time. It would therefore be advisable to not seek malice in our people but rather try to interpret a situation like this as a misunderstanding than as an attempt to scare you away. Thanks. Thijs |
From: Phil D. <ph...@di...> - 2006-07-25 13:25:25
|
My findings,as sent to the php-qa mailing list: What's happening is that PHP is dying mid-request. Debugging is slightly unreliable as I think PHP sometimes dies after echo/flush statements I've inserted, but before they are output. As far as I can tell, PHP is dying in some code in SquirrelMail which deals with register globals settings. (functions/global.php line 78 onwards) /** * Remove all globals from $_GET, $_POST, and $_COOKIE. */ foreach ($_REQUEST as $key => $value) { unset($GLOBALS[$key]); } PHP is dying (I think) on the unset() - if not, it's dying on the foreach() but before the output of any echo+flush statements I put after the unset(). If I comment out the unset line, I can echo out a list of the 3 variables the code would unset. The interesting one is probably SQMSESSID - the PHP session Id. -- Phil Driscoll |
From: Tomas K. <to...@us...> - 2006-07-25 15:04:56
|
> My findings,as sent to the php-qa mailing list: > > > What's happening is that PHP is dying mid-request. > Debugging is slightly unreliable as I think PHP sometimes dies after > echo/flush statements I've inserted, but before they are output. > As far as I can tell, PHP is dying in some code in SquirrelMail which > deals > with register globals settings. > > (functions/global.php line 78 onwards) > > /** > * Remove all globals from $_GET, $_POST, and $_COOKIE. > */ > foreach ($_REQUEST as $key => $value) { > unset($GLOBALS[$key]); > } > > PHP is dying (I think) on the unset() - if not, it's dying on the > foreach() > but before the output of any echo+flush statements I put after the > unset(). > > If I comment out the unset line, I can echo out a list of the 3 variables > the code would unset. The interesting one is probably SQMSESSID - the PHP > session Id. > -- > Phil Driscoll This code is active only when PHP register_globals are turned on. We will have to do layout changes in functions/global.php in order to fix incorrect script execution order (bug #1527870), but these changes don't fix your issue. Script tries to unset registered globals. I can reproduce it in SquirrelMail. Can't reproduce it in short PHP script that does same thing. -- Tomas |
From: Tomas K. <to...@us...> - 2006-07-25 16:36:15
Attachments:
global.php-2.diff
|
> My findings,as sent to the php-qa mailing list: > > > What's happening is that PHP is dying mid-request. > Debugging is slightly unreliable as I think PHP sometimes dies after > echo/flush statements I've inserted, but before they are output. > As far as I can tell, PHP is dying in some code in SquirrelMail which > deals > with register globals settings. > > (functions/global.php line 78 onwards) > > /** > * Remove all globals from $_GET, $_POST, and $_COOKIE. > */ > foreach ($_REQUEST as $key => $value) { > unset($GLOBALS[$key]); > } > > PHP is dying (I think) on the unset() - if not, it's dying on the > foreach() > but before the output of any echo+flush statements I put after the > unset(). > > If I comment out the unset line, I can echo out a list of the 3 variables > the > code would unset. The interesting one is probably SQMSESSID - the PHP > session > Id. Interface breaks only when you have 'key' cookie. 09416ee728ab1f5f934750f94496c095 global.php-2.diff Patch includes #1527870 updates and uses less generic names in foreach() calls. Patch is against 1.4.7 functions/global.php -- Tomas |
From: Tomas K. <to...@us...> - 2006-07-25 18:56:56
|
>> My findings,as sent to the php-qa mailing list: >> >> >> What's happening is that PHP is dying mid-request. >> Debugging is slightly unreliable as I think PHP sometimes dies after >> echo/flush statements I've inserted, but before they are output. >> As far as I can tell, PHP is dying in some code in SquirrelMail which >> deals >> with register globals settings. >> >> (functions/global.php line 78 onwards) >> >> /** >> * Remove all globals from $_GET, $_POST, and $_COOKIE. >> */ >> foreach ($_REQUEST as $key => $value) { >> unset($GLOBALS[$key]); >> } >> >> PHP is dying (I think) on the unset() - if not, it's dying on the >> foreach() >> but before the output of any echo+flush statements I put after the >> unset(). >> >> If I comment out the unset line, I can echo out a list of the 3 >> variables >> the >> code would unset. The interesting one is probably SQMSESSID - the PHP >> session >> Id. > > Interface breaks only when you have 'key' cookie. http://bugs.php.net/38211 -- Tomas |
From: Phil D. <ph...@di...> - 2006-07-28 22:08:26
|
On Tuesday 25 July 2006 19:11, Tomas Kuliavas wrote: > http://bugs.php.net/38211 Thanks Tomas. -- Phil Driscoll |