bill 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).
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
