Regarding having to do a kill -9 on the Squeak VM and not knowing why.
Let me point out that on unix based systems it is easy to attach the  
debugger to a process/application then do real-time debugging. One of  
the things you can do is stop the interpreter and then call the C  
subroutine to print the stack so you can see what's up

[otter:~] johnmci% ps -ax | grep Squeak
  3944  ??  S      0:11.46  
/Users/johnmci/Documents/Squeak3.7.0/build/Squeak  
3.7.4Beta1b.app/Contents/MacOS/Squeak VM Opt -psn_0_4849
  3978 std  R+     0:00.00 grep Squeak

"Everything I need to identify the program path and the process id I  
need for GDB"

[otter:~] johnmci% gdb  
"/Users/johnmci/Documents/Squeak3.7.0/build/Squeak  
3.7.4Beta1b.app/Contents/MacOS/Squeak VM Opt" 3944


GNU gdb 5.3-20030128 (Apple version gdb-309) (Thu Dec  4 15:41:30 GMT  
2003)
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and  
you are
welcome to change it and/or distribute copies of it under certain  
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for  
details.
This GDB was configured as "powerpc-apple-darwin".
Reading symbols for shared libraries ....... done
/Users/johnmci/3944: No such file or directory.
Attaching to program:  
`/Users/johnmci/Documents/Squeak3.7.0/build/Squeak  
3.7.4Beta1b.app/Contents/MacOS/Squeak VM Opt', process 3944.
Reading symbols for shared libraries  
.................................................... done
0x900074c8 in mach_msg_trap ()
(gdb)

Now issue the command

call (int) printAllStacks()

give me this stuff below on the Console log for os-x, this is somewhat  
better than getting nothing and having to do a kill -9 without any  
information about
what was going on.

Process
94774824 ProcessorScheduler class>idleProcess
94561472 [] in ProcessorScheduler class>startUp
94561564 [] in BlockContext>newProcess

Process
76950284 Delay class>?
76950620 [] in Delay class>?
76950696 [] in BlockContext>?

Process
78498300 WeakArray class>?
78498024 [] in UndefinedObject>?
78498208 [] in BlockContext>?

Process
94560116 InputSensor>userInterruptWatcher
94559932 [] in InputSensor>installInterruptWatcher
94560024 [] in BlockContext>newProcess

Process
95007552 Delay>wait
95007864 [] in EventSensor>eventTickler
95007460 BlockContext>on:do:
94560608 EventSensor>eventTickler
94560332 [] in EventSensor>installEventTickler
94560516 [] in BlockContext>newProcess

Process
94561052 SystemDictionary>lowSpaceWatcher
94561144 [] in SystemDictionary>installLowSpaceWatcher
94561236 [] in BlockContext>newProcess

Process
95034544 Delay>wait
95034452 WorldState>interCyclePause:
95033808 WorldState>doOneCycleFor:
95033716 PasteUpMorph>doOneCycle
86819048 [] in Project class>spawnNewProcess
86819140 [] in BlockContext>newProcess

Process
95125136 Delay>wait
95125044 WorldState>interCyclePause:
95124216 WorldState>doOneCycleFor:
95124124 PasteUpMorph>doOneCycle
86819048 [] in Project class>spawnNewProcess
86819140 [] in BlockContext>newProcess



On Jul 10, 2004, at 12:12 PM, Avi Bryant wrote:

>>> How easy is it to lose data?
>> Actually, not too easy, as long as hardware doesn't fail.
>
> Having a process die suddenly does not require hardware failure.   
> Operating systems kill processes all the time.  Not to mention  
> sysadmins.  If I can't "killall -9 squeak" without fearing for my  
> data, that's a big problem.  Again, I would be much happier if you  
> seemed to be acknowledging the problem rather than explaining it away.
>
> Cheers,
> Avi



> --
======================================================================== 
===
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
======================================================================== 
===