Hi Bill -

The just released 3.11.8 VM does take care of the issue you're 
reporting. It creates a proper crash.dmp for all of the cases that would 
previously silently quit. Try that doIt below in with 3.11.8 to compare 
to the previous behavior.

Cheers,
   - Andreas

On 3/10/2010 5:12 AM, 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 at lists.gforge.inria.fr [mailto:pharo-project-bounces at 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 at lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>