I have not checked this in a while (and cannot do so right now), but
Andreas provided four tests that should be expected to be interruptable
(on any VM in both Morphic and MVC). These are:

  * "[true] whileTrue"
  * "[[true] whileTrue] forkAt: Processor userSchedulingPriority + 1"
  * "Smalltalk createStackOverflow"
  * "[Smalltalk createStackOverflow] forkAt: Processor
userSchedulingPriority + 1"

There are a number of Mantis entries that provide background and
descriptions of unsolved problems. They are collected in Mantis 7655: "A
mother for user interupt bugs and problems"

http://bugs.squeak.org/view.php?id=7655

Dave

>
> On 06-03-2014, at 8:16 AM, Chris Muller <asqueaker at gmail.com> wrote:
>
>> If, during the act of building and opening the debugger, if something
>> causes yet another exception to be triggered (say, a bad printOn: or
>> problem building one of the inspector panes), then I think you'll be
>> in an unavoidable infinite recursion.  Not sure whether there's any
>> way around that

>
> That’s certainly one kind of problem we can so easily make for ourselves
> and as Levente points out it *should* trigger the emergence evaluator. On
> a good day, at least.
>
> I suppose at some point I (and by ‘I’, I mean possibly me or perhaps some
> other person with some actual available time, if such a person exists)
> should probably add some debug code to trap the time the cmd-. was
> actually pressed, the time when it was recognised in either
> EventSensor>processEvent: or the InputSensor>userInterruptWatcher etc. My
> suspicion is that the interrupt is not getting into the image in a timely
> manner but it could of course be some problem in the work to actually open
> the debugger once the interrupt has been handled.
>
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Useful random insult:- Understands English as well as any parrot.
>
>
>