> 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: [email protected] >>>> [mailto:[email protected]] 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 >>>> [email protected] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [email protected] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> > > > >
_______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
