perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: Connection aborted was ModPerl::Util::exit: (120000) exit was called at /usr/share/perl5/CGI/ line 590
Date Wed, 14 Nov 2012 19:33:26 GMT
Dave Morgan wrote:
> -------- Original Message --------
> Thank you Andre,
> On 31/10/12 01:58 PM, André Warnier wrote:
>  > Dave Morgan wrote:
>  >> How do I find out where the following call(s) are made from?
>  >
>  > See
>  > or by including the string -MCarp=verbose in the PERL5OPT environment 
> variable.
>  > Exactly what I was looking for
> However, the above did not help as the call was to Carp::fatalstobrowser.

You've got me a bit confused now. "fatalstobrowser" is not a part of the "Carp" module, it

is part of the CGI::Carp module, which is not the same thing.
(And I should have spotted that from your earlier logs, sorry).

"fatalstobrowser" is not really something you call, it is an option which you ínclude in

the use statement for CGI::Carp.
It's sole effect, as far as I remember, is to /also/ output to the browser any fatal 
message that would normally only be sent to the server's error log.

> We did find the use statement and removed it. We now get
> Software caused connection abort at 
> /home/apache/metapoint/trunk/ line 231.

Ok, so now you know at which line of which module this issue happens.

Is that you only issue (this line in the logs) ?

Because if it is, it doesn't necessarily indicate a problem.  It can happen just because 
the user clicks on some other link (or closes the window or the browser), before your 
server has had time to send it the full answer to the present request.
Because of that, there is no more client connection over which Apache can continue to send

the response, and the next time your program tries to write something, it triggers this 
error and message in the log.

> This only happens when the client is IE. From searching the net it 
> appears to be something
> to do with the http header not quite right. 

No offense intended, but that sounds iffy to me; unless your $response below is a PDF 
document, in which case there was something indeed with some versions of the Adobe PDF 
plugin for IE not behaving correctly with some standard HTTP headers.

The code is quite simple:
> print $CGI->header( $header_info_ref );

> print $response;  <-- maybe you could add "or something-to-do-in-case-of-error" here
> Running curl provides the following output
> [webadmin@web001 perl]$ curl -v 
> '' --raw
> * About to connect() to port 80 (#0)
> *   Trying connected
> * Connected to ( port 80 (#0)
>  > GET / HTTP/1.1
>  > User-Agent: curl/7.19.7 (i386-redhat-linux-gnu) libcurl/7.19.7 
> NSS/ zlib/1.2.3 libidn/1.18 libssh2/1.2.2
>  > Host:
>  > Accept: */*
>  >
> < HTTP/1.1 200 OK
> < Date: Wed, 14 Nov 2012 17:03:17 GMT
> < Server: Apache
> < Expires: Tue, 15 Nov 2011 17:03:17 GMT
> < Pragma: no-cache
> < Set-Cookie: sessionid=jHZgBLBfavSyJcZMIaz; path=/; expires=Mon, 
> 13-May-2013 17:03:17 GMT
> < Transfer-Encoding: chunked
> < Content-Type: text/html; charset=iso-8859-1
> <
> 55f2
> <!-- BEGIN portal_chooser.tt2 -->
>         <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
> "">
> <html xmlns="" 
> xmlns:v="urn:schemas-microsoft-com:vml" xml:lang="en" lang="en">
> The only thing I can see is a line feed before the chunk size but I do 
> not know if this is the
> issue or if so how to remove it. Any ideas?

The above looks like a perfectly valid request/response to me. Do you get an error in the

logs when you do this with curl ?

In short, what is your problem ?

View raw message