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
Thanks

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

Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash

Tuesday 25 July 2006 12:29, Brian G. Peterson wrote:
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.

Tuesday 25 July 2006 06:33, Phil Driscoll wrote:
Tuesday 25 July 2006 12:29, Brian G. Peterson wrote:
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

Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash

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

Posting Guidelines:

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.

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.

Tuesday 25 July 2006 12:50, Brian G. Peterson wrote:
Tuesday 25 July 2006 06:33, Phil Driscoll wrote:
Tuesday 25 July 2006 12:29, Brian G. Peterson wrote:
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.

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 :(

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:

You haven't provided any useful information in your report. PHP
version. We don't know what triggered PHP error. 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. 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.

Phil,

Tue, 2006-07-25 at 13:46 +0100, Phil Driscoll wrote:
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 :(

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

Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash

Tuesday 25 July 2006 07:42, Phil Driscoll wrote:
Tuesday 25 July 2006 12:50, Brian G. Peterson wrote:
Tuesday 25 July 2006 06:33, Phil Driscoll wrote:
Tuesday 25 July 2006 12:29, Brian G. Peterson wrote:
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

Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash

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, $_PST, and $_CKIE.
*/
foreach ($_REQUEST as $key =$value) {
unset($GLBALS[$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.

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, $_PST, and $_CKIE.
*/
foreach ($_REQUEST as $key =$value) {
unset($GLBALS[$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.

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, $_PST, and $_CKIE.
*/
foreach ($_REQUEST as $key =$value) {
unset($GLBALS[$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.

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

>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, $_PST, and $_CKIE.
>*/
>foreach ($_REQUEST as $key =$value) {
>unset($GLBALS[$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

Tuesday 25 July 2006 19:11, Tomas Kuliavas wrote:
http://bugs.php.net/38211
Thanks Tomas.