Malte Ubl wrote:

Can you reproduce the problem at will?

Unfortunately not. Although I have seen the problem on our development system (where I was testing), the problem is not reproducable. As I said the live system doesn't behave deterministically either. The conditions under which is fails are always similar, but it doesn't fail always under these conditions.

I'd try to use ab or something similar on the dev machine to reproduce it. Do you know what script/args does it hit when you get this error? e.g. you could customise the $SIG{__DIE__} handler or put that code above in eval {} and log the args and the uri of the request that has caused the problem. However sometimes the error happens on the next request following the request that has triggered the problem.

Quite often the error line is reported incorrectly. You can always add something like:

#line 215
   $pr->{'code'} = $pr->{r}->slurp_filename;

I'll try that, but I haven't been able to reproduce the problem yet. Can I be sure that the reported file is right?

Normally it is correct. Unless someone has messed up with the low level C code that can change that.

For example $$ is readonly, so you get:


That is a good hint. I only had literals on my mind and I didn't think of special vars.

Our code is not using any specials variables though except %SIG for alarm.

I've used $$ just as an example, any variable can be affected.

If the error occurs, it seem to bubble from apache child to apache child like an infection (Although it seems to take a pretty long time (like 15 Minutes)). That's why I always figured that this bug must be releated to source code that is being modified and copied to the children.

Could it be some environment issue? running out of disk space, RAM, etc.?

--
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Reply via email to