Stas Bekman wrote:
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.
We only have a single script that handles the XML-RPC-Requests. We can
enable logging of the Parameters being passed back and forth. If we
could only reproduce the problem :)
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.
How does a variable become read-only? Is that something that can be done
on C/XS Level?
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.?
RAM would be possible. We'll look into that and maybe go down with
MaxClients a little. It doesnt look like we have ever hit the SWAP though.
Thanks,
Malte
--
SCHAFFHAUSEN COMMUNICATION GROUP
Schaffhausen Advertising GmbH / Daimlerstraße 17 / 25337 Elmshorn
Fon +49 41 21.47 29-459 / Fax +49 41 21.47 29-455
[EMAIL PROTECTED] / www.schaffhausen.de