Hi Perrin, Thanks again for trying to help.
> The only other thing that occurs to me, and this is a reach because > I'm way out of my expertise, is that the problem Stas fixed earlier > had to do with some XS code not leaving things in a good state, and > maybe some XS code in a module you use is doing that. One thing you > could do is add enough logging to be able to examine the series of > requests for a process which lead up to this error. Then you'd be > able to check if it always starts after a certain page or a certain > sequence. I'm afraid that the problem I have is difficult to repeat even with a forking httpd in my development environment. Whereas in my production environment, if I access some a new mod_perl page again and again over the course of a few minutes I'm almost guaranteed for users to trigger the error which actually occurs on _another_ mod_perl page which has been working okay since it's migration many months ago. When you say 'good state' isn't it actually the job of mod_perl to reset the state of certain things? Don't get me wrong, I'm not saying that mod_perl has to fix every problem under the sun between invocations of a page/script - for example there's no way it can fix a memory leak from a CPAN module, but still problem still seems like something is 'corrupting' the workings/state of taint mode in the Perl interpreter so that future evals throw the error. The only way to work around this seems to be to do a graceful restart and thus kill off the corrupted Perl interpreter. It would be nice if I could somehow connect to the Perl interpreter in the httpd child process that I know is going wrong and get it to dump out more of its internal state, but I'm not sure how to do this. I'm going to install Devel::Symdump so that I can use the Symbol Table part of Apache2::Status, maybe that will shed some light on the situation, but I'm really clutching at straws now. Can anyone explain the negative egid that I saw. Is that normal & expected under mod_perl ? Sagar ------------------------------------------------------------------------ For more information about Barclays Capital, please visit our web site at http://www.barcap.com. Internet communications are not secure and therefore the Barclays Group does not accept legal responsibility for the contents of this message. Although the Barclays Group operates anti-virus programmes, it does not accept responsibility for any damage whatsoever that is caused by viruses being passed. Any views or opinions presented are solely those of the author and do not necessarily represent those of the Barclays Group. Replies to this email may be monitored by the Barclays Group for operational or business reasons. ------------------------------------------------------------------------
