You are viewing a plain text version of this content. The canonical link for it is here.
Posted to embperl@perl.apache.org by Gerald Richter <ri...@ecos.de> on 2001/10/04 21:07:40 UTC
Re: Setup of CGI.pm failed
>
> Thanks Gerald - unfortunately I still don't know *WHY* CGI.pm dies -
> and I am lost about how to find out.
>
> I have put in a log line just after the eval to dump %ENV, but this
> does not look particularly unusual.
>
Could you print out $@ directly after the
eval { $cgi = new CGI } ;
When CGI fails, does it contain any usefull information ?
In past sometimes it has helped to upgrade CGI.pm in such cases, but it
could also simply the case that people press "Abort" during the upload or
make a double click on the submit button which also aborts the first
request.
I really would be happy to find out the reason too, because this isn't the
first time this issue came up...
Gerald
P.S. Let's take the discussion on the Embperl list, maybe somebody there has
any idea
-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925131
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: Setup of CGI.pm failed
Posted by Gerald Richter <ri...@ecos.de>.
>
> It appears that Embperl thinks CGI.pm has failed even though it hasn't -
and CGI.pm
> continues uploading files even though Embperl has bailed out.
>
> This is the sequence of events I have so far from the logs:
>
> 10:30:29 - my logging in CGI.pm reports read_multipart() in CGI.pm called,
upload length 949716
> 10:30:30 - my logging in CGI.pm reports first file of batch started
> 10:31:58 - my logging in CGI.pm reports first file of batch completed
successfully
> 10:31:58 - my logging in CGI.pm reports second file of batch started
> 10:32:17 - Setup of CGI.pm failed appears in error log
> 10:32:19 - my log from HTML script complains that %fdat is empty
> 10:32:20 - POST request appears in main server log with 500 return code
> 10:36:01 - my logging in CGI.pm reports second first file of batch
completed successfully
> 10:36:01 - my logging in CGI.pm reports third file of batch started
> 10:39:55 - my logging in CGI.pm reports third file of batch completed
successfully
> 10:39:55 - my logging in CGI.pm reports fourth file of batch started
> 10:40:10 - my logging in CGI.pm reports third file of batch completed
successfully
>
>
That would mean that CGI.pm somehow continues, also the request is already
finished.
That would only be possible if either there is another process...
Are you sure all these log entries belong to the same process and request ?
Not sure if this changes anything, but can you change im Embperl.pm
eval { $cgi = new CGI } ;
to
$cgi = eval { new CGI } ;
Also in the newer CGI.pm version there is a function called cgi_error, which
may give more informations in case of failure
Gerald
-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925131
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: Setup of CGI.pm failed
Posted by Chris Allen <ch...@cjx.com>.
On Wed, Oct 10, 2001 at 08:41:47PM +0200, Gerald Richter wrote:
>
> I have currently no idea what is happeing. The only way I see to track this
> down, is to put logging message inside of CGI.pm itself. I good place to
> start is the function read_multipart. Put some warns inside to see where it
> might fail.
>
It appears that Embperl thinks CGI.pm has failed even though it hasn't - and CGI.pm
continues uploading files even though Embperl has bailed out.
This is the sequence of events I have so far from the logs:
10:30:29 - my logging in CGI.pm reports read_multipart() in CGI.pm called, upload length 949716
10:30:30 - my logging in CGI.pm reports first file of batch started
10:31:58 - my logging in CGI.pm reports first file of batch completed successfully
10:31:58 - my logging in CGI.pm reports second file of batch started
10:32:17 - Setup of CGI.pm failed appears in error log
10:32:19 - my log from HTML script complains that %fdat is empty
10:32:20 - POST request appears in main server log with 500 return code
10:36:01 - my logging in CGI.pm reports second first file of batch completed successfully
10:36:01 - my logging in CGI.pm reports third file of batch started
10:39:55 - my logging in CGI.pm reports third file of batch completed successfully
10:39:55 - my logging in CGI.pm reports fourth file of batch started
10:40:10 - my logging in CGI.pm reports third file of batch completed successfully
Any ideas??
ps... Confirmed that this also happens through mod_perl.
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: Setup of CGI.pm failed
Posted by Gerald Richter <ri...@ecos.de>.
>
> > When CGI fails, does it contain any usefull information ?
>
> It's empty. Always.
>
ok, I just wanted to make sure it didn't get lost, because there was nothing
in the Embperl error message. So we have verified that CGI.pm really doesn't
set's $@
>
> Also the user often (but not always) gets a '500 server error' message.
> This happens at least 20 times a day on our site, so I don't think it
> is the user pressing stop.
>
They will see the 500 error when you see message in the error log I guess.
>
> Other things that may be useful:
>
> - This happens in a script that is called as a CGI, not through mod perl.
> I have not seen it happen through mod perl. Unfortunately a bug in mod
proxy
> means that I have to run it as a CGI.
>
> - It is an upload script that handles large files - usually over 1MB
>
> - I also use CGI::Cookie in this script.
>
I have currently no idea what is happeing. The only way I see to track this
down, is to put logging message inside of CGI.pm itself. I good place to
start is the function read_multipart. Put some warns inside to see where it
might fail.
Gerald
-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925131
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: Setup of CGI.pm failed
Posted by Chris Allen <ch...@cjx.com>.
On Thu, Oct 04, 2001 at 09:07:40PM +0200, Gerald Richter wrote:
>
> Could you print out $@ directly after the
>
> eval { $cgi = new CGI } ;
> When CGI fails, does it contain any usefull information ?
It's empty. Always.
>
> In past sometimes it has helped to upgrade CGI.pm in such cases, but it
> could also simply the case that people press "Abort" during the upload or
> make a double click on the submit button which also aborts the first
> request.
I have tried with the latest version of CGI.pm - no improvement.
Also the user often (but not always) gets a '500 server error' message.
This happens at least 20 times a day on our site, so I don't think it
is the user pressing stop.
Other things that may be useful:
- This happens in a script that is called as a CGI, not through mod perl.
I have not seen it happen through mod perl. Unfortunately a bug in mod proxy
means that I have to run it as a CGI.
- It is an upload script that handles large files - usually over 1MB
- I also use CGI::Cookie in this script.
-
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org