You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Victor Danilchenko <da...@cs.umass.edu> on 2007/05/03 04:57:59 UTC

Help with $r being corrupted

	Hi all,

	I have a custom handler which is supposed to do some stuff with the 
request, and run it through the Mason parser. The trouble is that ever 
once in a while -- rarely -- the request object comes to my handler 
method corrupted. The error I usually get is that dir_config method is 
not defined for $r:

Can't locate object method "dir_config" via package "Ask::Mason::Secure" 
at /usr/share/perl5/HTML/Mason/ApacheHandler.pm line 895.

	I tracked it down, and it is the $r problem.

	I suspect this is a Perl issue, as I have noticed that generally, funny 
things seem to occasionally happen with the symbol table (i.e. methods 
getting forgotten ever once in a while) in the perl code. So, I was 
wondering if there is any way to reconstitute the object, to get a new 
$r variable within the handler -- to re-create the Apache2::RequestRec 
object really.

	Can anyone help out with an idea?

Re: Help with $r being corrupted

Posted by Jonathan Vanasco <jv...@2xlp.com>.
On May 4, 2007, at 8:02 PM, Victor Danilchenko wrote:

> 	I am not sure if it's the same type of error, but the idea of  
> recording the PID is a great one -- if it is the problem, then  
> forcing the error-prone child to commit suicide might indeed be the  
> answer. I will add it to the error reporting.

damnit, my email is messed up today...

I was supposed to send this to the list --

====

what about logging a wtf in that handler ?

	sub handler {
		my $r= shift;
		if ( !ref($r) || (ref($r) ne 'Apache' && ref($r) ne  
'Apache::Request' && ref($r) ne 'Apache::Filter'))
		{
			# log into sql
			# pid | timestamp | ref($r) | caller(1)
		}

this way you can better map a trend of what is screwing up , when
if you do it in sqlite, you'll have something relatively quick to  
implement and easy to search through.


Re: Help with $r being corrupted

Posted by Victor Danilchenko <da...@cs.umass.edu>.
	I am not sure if it's the same type of error, but the idea of recording 
the PID is a great one -- if it is the problem, then forcing the 
error-prone child to commit suicide might indeed be the answer. I will 
add it to the error reporting.


Adam Prime x443 wrote:
> I have encounter the same problem (at least the same symptoms) 
> 
> thread here:
> http://marc.info/?l=apache-modperl&m=114226565622372&w=2
> 
> I have never been able to find a true solution, but it is very
> intermittent.  I worked around it by doing this (which isn't really a
> solution at all, and in fact borders on horrible).  It does however keep
> the user from getting a 500 (they get nothing at all instead).  I kill
> the child because the errors would usually come in clusters all from a
> single apache child.
> 
> sub handler {
>     my $r = shift;
>     if ( !ref($r) || (ref($r) ne 'Apache' && ref($r) ne
> 'Apache::Request' && ref($r) ne 'Apache::Filter')){
>        print STDERR 'pnotes error occuring '.__PACKAGE__.' - pid: ' . $$
> . ' non-apache object: ' . ref($r) . "\n";
>        Apache->request->child_terminate;
>        return DONE;
>     }
> ...
> 
> You might be able to work around it by doing something like this though
> now that i think about it.
> 
> sub handler {
>     my $r = shift;
>     if ( !ref($r) || (ref($r) ne 'Apache' && ref($r) ne
> 'Apache::Request' && ref($r) ne 'Apache::Filter')){
>         $r = Apache->request;
>         $r->child_terminate; # i'd still kill off the child anyway
> }
> 
> HTH
> 
> Adam
> 
> 
> -----Original Message-----
> From: Victor Danilchenko [mailto:danilche@cs.umass.edu] 
> Sent: Thursday, May 03, 2007 6:51 PM
> To: Frank Wiles
> Cc: modperl@perl.apache.org
> Subject: Re: Help with $r being corrupted
> 
> Frank Wiles wrote:
> 
>>    Actually it isn't an issue of methods being forgotten, more likely
>>    you aren't using Apache2::RequestUtil in your code.  Preferably
>>    preloading it. 
> 
> 	Well, the production code which has this problem is running
> under 
> mod_perl 1 and Apache 1.3 right now, but I do load both Apache and 
> Apache::Request there (the code is compatible with moth mod_perl and 
> mod_perl2, I also load Apache2::RequestUtil in the Apache2 comaptibility
> 
> block), and the error still occurs.
> 
> 	Is it some different module for Apache 1 that I am missing?
> Though the 
> fact that the error occurs only infrequently, and mostly in requests 
> which occur over SSL, makes me suspect that it's something else.
> 


RE: Help with $r being corrupted

Posted by Adam Prime x443 <ap...@brunico.com>.
I have encounter the same problem (at least the same symptoms) 

thread here:
http://marc.info/?l=apache-modperl&m=114226565622372&w=2

I have never been able to find a true solution, but it is very
intermittent.  I worked around it by doing this (which isn't really a
solution at all, and in fact borders on horrible).  It does however keep
the user from getting a 500 (they get nothing at all instead).  I kill
the child because the errors would usually come in clusters all from a
single apache child.

sub handler {
    my $r = shift;
    if ( !ref($r) || (ref($r) ne 'Apache' && ref($r) ne
'Apache::Request' && ref($r) ne 'Apache::Filter')){
       print STDERR 'pnotes error occuring '.__PACKAGE__.' - pid: ' . $$
. ' non-apache object: ' . ref($r) . "\n";
       Apache->request->child_terminate;
       return DONE;
    }
...

You might be able to work around it by doing something like this though
now that i think about it.

sub handler {
    my $r = shift;
    if ( !ref($r) || (ref($r) ne 'Apache' && ref($r) ne
'Apache::Request' && ref($r) ne 'Apache::Filter')){
        $r = Apache->request;
        $r->child_terminate; # i'd still kill off the child anyway
}

HTH

Adam


-----Original Message-----
From: Victor Danilchenko [mailto:danilche@cs.umass.edu] 
Sent: Thursday, May 03, 2007 6:51 PM
To: Frank Wiles
Cc: modperl@perl.apache.org
Subject: Re: Help with $r being corrupted

Frank Wiles wrote:

>    Actually it isn't an issue of methods being forgotten, more likely
>    you aren't using Apache2::RequestUtil in your code.  Preferably
>    preloading it. 

	Well, the production code which has this problem is running
under 
mod_perl 1 and Apache 1.3 right now, but I do load both Apache and 
Apache::Request there (the code is compatible with moth mod_perl and 
mod_perl2, I also load Apache2::RequestUtil in the Apache2 comaptibility

block), and the error still occurs.

	Is it some different module for Apache 1 that I am missing?
Though the 
fact that the error occurs only infrequently, and mostly in requests 
which occur over SSL, makes me suspect that it's something else.


Re: Help with $r being corrupted

Posted by Victor Danilchenko <da...@cs.umass.edu>.
Frank Wiles wrote:

>    Actually it isn't an issue of methods being forgotten, more likely
>    you aren't using Apache2::RequestUtil in your code.  Preferably
>    preloading it. 

	Well, the production code which has this problem is running under 
mod_perl 1 and Apache 1.3 right now, but I do load both Apache and 
Apache::Request there (the code is compatible with moth mod_perl and 
mod_perl2, I also load Apache2::RequestUtil in the Apache2 comaptibility 
block), and the error still occurs.

	Is it some different module for Apache 1 that I am missing? Though the 
fact that the error occurs only infrequently, and mostly in requests 
which occur over SSL, makes me suspect that it's something else.


Re: Help with $r being corrupted

Posted by Frank Wiles <fr...@wiles.org>.
On Wed, 02 May 2007 22:57:59 -0400
Victor Danilchenko <da...@cs.umass.edu> wrote:

> 	Hi all,
> 
> 	I have a custom handler which is supposed to do some stuff
> with the request, and run it through the Mason parser. The trouble is
> that ever once in a while -- rarely -- the request object comes to my
> handler method corrupted. The error I usually get is that dir_config
> method is not defined for $r:
> 
> Can't locate object method "dir_config" via package
> "Ask::Mason::Secure" at /usr/share/perl5/HTML/Mason/ApacheHandler.pm
> line 895.
> 
> 	I tracked it down, and it is the $r problem.
> 
> 	I suspect this is a Perl issue, as I have noticed that
> generally, funny things seem to occasionally happen with the symbol
> table (i.e. methods getting forgotten ever once in a while) in the
> perl code. So, I was wondering if there is any way to reconstitute
> the object, to get a new $r variable within the handler -- to
> re-create the Apache2::RequestRec object really.
> 
> 	Can anyone help out with an idea?

   Actually it isn't an issue of methods being forgotten, more likely
   you aren't using Apache2::RequestUtil in your code.  Preferably
   preloading it. 

 ---------------------------------
   Frank Wiles <fr...@wiles.org>
   http://www.wiles.org
 ---------------------------------


Re: Help with $r being corrupted

Posted by Victor Danilchenko <da...@cs.umass.edu>.
Perrin Harkins wrote:
> On 5/2/07, Victor Danilchenko <da...@cs.umass.edu> wrote:
>>         I suspect this is a Perl issue, as I have noticed that 
>> generally, funny
>> things seem to occasionally happen with the symbol table (i.e. methods
>> getting forgotten ever once in a while) in the perl code.
> 
> I don't think it's a general perl issue.  Probably there is a bug in
> some C code, either in a module you're using or in mod_perl, that is
> causing this problem.  If you can figure out a way to reproduce it
> reliably, it can be fixed.

	I wish it were so easy. As it is, all I have now is perhaps a dozen 
error instances per many thousands of requests (each day). I trap the 
error in eval and mail it to myself, though, so if you have any 
suggestions about the extra data to include in the mailed message, for 
debugging purposes, I would be glad to hear it. This problem has been 
bugging me like crazy.


Re: Help with $r being corrupted

Posted by Perrin Harkins <pe...@elem.com>.
On 5/2/07, Victor Danilchenko <da...@cs.umass.edu> wrote:
>         I suspect this is a Perl issue, as I have noticed that generally, funny
> things seem to occasionally happen with the symbol table (i.e. methods
> getting forgotten ever once in a while) in the perl code.

I don't think it's a general perl issue.  Probably there is a bug in
some C code, either in a module you're using or in mod_perl, that is
causing this problem.  If you can figure out a way to reproduce it
reliably, it can be fixed.

- Perrin