ok so excellent then. I though that having a max counter to get let us say 1000 last crash could help. I do not know what is the situation of dabblebd like setup.
Stef
On Mar 11, 2010, at 9:09 AM, Andreas Raab wrote:
On 3/10/2010 11:40 PM, Stéphane Ducasse wrote:
did you not notice problem with the size of the log file with the appening behavior? Because I started to have a huge file where all the crashes reports were added one by one and I was wondering if on a server this may not be a problem (probably having a limit for the size of the report could be a good idea - but I do not know).
One a production server? Do the math: 1GB of disk space costs cents. One hour of two of your engineers trying to recreate the problem or recover the information costs a few hundred bucks. That's a ratio of 10000:1.
On our main server the size of the logs is 500MB going back six months or so when we reimaged it last. That's 0.1% of the disk space on the box. The other day we bought a few more TBs of cheap scratch storage which we use for throwaway VMs in QA (vmware VMs, not Squeak so it's 20+GB each).
On a production server it makes no sense whatsoever to limit logging unless you're logging *excessively*. In an emergency the logs are all you have to find out what is going wrong, it's worth keeping them.
Cheers, - Andreas
Stef
On Mar 10, 2010, at 2:12 PM, Schwab,Wilhelm K wrote:
Andreas,
I will give that a try. I think it should be active by default, but it won't matter too much once I modify the shortcuts on a few boxes. Other wish list items would be to have a similar option on Linux and to ensure that the contents of the log are concatenated vs. replaced with each crash.
Thanks!!
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Andreas Raab Sent: Wednesday, March 10, 2010 12:32 AM To: Pharo Development Subject: Re: [Pharo-project] VM crash on Windows
Hi Bill -
If you have problems like these consider cross-posting to squeak-dev or vm-dev. I only check Pharo in irregular intervals.
On 3/8/2010 4:27 PM, Schwab,Wilhelm K wrote:
I am having a sudden problem with Pharo crashing on Windows - it's quitting on handling Seaside requests, and I'm getting **no** information. The VM pops up the output console, writes a lot of (probably useful) information to it, and then promptly exits.
The issue you're seeing is caused by a recursive MessageNotUnderstood error. You can easily recreate this by doing the following:
((ProtoObject subclass: #Bummerator instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'Kernel-Objects') superclass: nil; new) bummer.
The reason why that doesn't result in a regular crash.dmp is that the support code (which catches the crashes and writes the dump) isn't involved at all. The interpreter just quits.
Contrast this with, say the result of an FFI crash:
(ExternalLibraryFunction name:'' module: '' callType: 0 returnType: ExternalType void argumentTypes: #()) setHandle: ((ExternalAddress new) at: 1 put: 1; yourself); invoke
This does generate a crash.dmp since the support code can catch the problem.
However, to catch the former issue you can run the vm with -log: <logfile> which will contain the resulting output.
The rebuttal: if it has time/ability to write information all over part of the screen, it can open a file and make sure it leaves a trace of what happened. Right? The current vms (Windows and Linux) appear to be totally disinterested in logging crashes, and that needs to change.
They do if you tell 'em to.
Cheers, - Andreas
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project