[Seaside] Re: VM freezes; how to find the cause?
jtuchel at objektfabrik.de
Mon May 27 19:22:25 UTC 2013
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
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 ;-)
More information about the seaside