I've been experiencing UI hangups ever since I started working with 
Squeak-at-the-backend (Seaside, my current P2P stuff, even various 
Swiki  incarnations I think) - the symptom is always the same: Squeak 
does not  respond to mouse&keyboard anymore, but the networkings bits 
still work.

I now have an image with a severe case of this - it'll hangup in as 
little as 10 minutes...

---

Just to see if it is the finalization thing - have you tried finding 
and killing the finalizationProcess and seeing if it still happens?

Seaside in particular makes extensive use (too much use, I think) of 
WeakArray, which can sometimes turn out to be a real problem in 
production - though the symptoms I've seen are of extremely high CPU 
usage rather than outright hanging.

---

What I do is this to figure out where a hung or unresponsive squeak is:

gdb -p <processid>

then:

# show current stack to stderr (my script that starts squeak directs 
stderr to

uniquely named files) call printCallStack() # show all stacks: call 
printAllStacks() # flush output call fflush(stderr) # quit q

---

Touching the Transcript causes it to be redrawn, which causes your 
code to be redrawn, etc.

It's best not to use the Transcript while debugging UI code.

I've written a logger that uses a circular buffer (and which you can 
turn off and on); you can run some code and then display the results 
later.

What some people (including me) do to debug UI code (in Morphic or 
MVC) is to draw directly on the Display somewhere. There are a number 
of debug methods to do just that.

... of which a good one to use for once-off info is Object method 
#printDirectlyToDisplay, because if you should happen to leave such 
debugging code in, you can detect it via the ChangeSorter's "check for 
slips."

---

And of course if you happen to be running Squeak on a unixy sort
of system, this sort of thing works well:

(FileStream fileNamed: '/dev/tty')
  nextPutAll: 'hello world';
  nextPut: Character lf;
  flush