Andreas, Stef, I agree that logs are good, especially for rare problems; sometimes just a callstack can point to a weakness that would otherwise be nearly impossible to find. I have had Dolphin apps logging for quite a long time, and have not run into problems (just had to say that...<g>). I am fairly new at running Pharo images, and even newer at running them on machines that actually work. A 500 MB log would be no problem as long as it does not itself crash the image trying to open it. Do you have any tools to parse logs? Chris Uppal wrote Ghoul for parsing Dolphin crash dumps. It parses the dump and uses current code in the image to create a debugger-like view of a single "record" (one crash) from the dump; a drop-down list allows switching between records in a given file. It would be nice to have something similar here. 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: Thursday, March 11, 2010 3:10 AM To: Pharo-project@lists.gforge.inria.fr; squeak-dev@lists.squeakfoundation.org Subject: Re: [Pharo-project] VM crash on Windows 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
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project