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