Fwd: [squeak-dev] Re: VM crash on Windows

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