[Seaside] Re: VM freezes; how to find the cause?

[Joachim Tuchel]

Am 27.05.13 19:59, schrieb intrader:
> I don't know whether VisualWorks oe Object Studio by Cincom has a code 
> 'freeze' detector, but it is worth a try as it is a commercial 
> environment (they offer a free vorsion); you can try your bad 
> initialize there. You may wish to consult 
> http://www.smalltalk.org/versions for other versions. Good luck

As far as I know, there is a keyboard shortcut (was it ctrl-SysRq?) in 
VisualWorks to stop a runnig process and jump right into a debugger. 
Newer versions of ObjectStudio run in a VisualWorks VM, so I'd guess the 
same keystroke works as well.
In VAST (the environment I know best), you have a little extra button on 
the screen that does the same. Since that button is not controlled by 
Smalltalk code but by the VM, it does work in 99.9% of the cases (Of 
course you use another vm executable for your deployment). 
Instantiations also offers a free evaluation license that you can use to 
experiment.

In most Smalltalks I've used, you can use the debugger to break right 
into any running smalltalk process that you'd like to take a closer look 
at... It can be challenging to open a debugger on a background process 
that's gone wild, because there can be multiple processes running and 
the process  names are not always helping you much.

Most of the time, you end up with a StackOverflow exception if you run 
into a never-ending recursion, so you usually end up in the debugger 
anyways and the challenge is to dive down deep enough into the stack 
trace to find where the evil started ;-)

Joachim