Debugging UI
Last updated at 4:31 pm UTC on 14 January 2006
Cees de Groot 22 maart 2005 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.So, my questions:
- What are the possible causes?
- What is a debugging strategy to find out exactly where it goes wrong?
Bill Schwab It has been a while ago now, but I had a problem that would describe as Morphic locking up but the VM still working. In particular, I could interact with the VM system menu (windows) commands to dump the call stack on the current thread. In my case, it was apparently a case of inadequate mutual exclusion. I made a critical section bigger, and was no longer able to reproduce the lockup. I no longer recall the details, but it was driven by looking at callstacks from other than the active process/thread. So, here is what I recommend: modify the dump call stack command to dump all non-dead processes, not merely the active one. I did it by compiling my own VM. I did what I could at the time to make the changes available, but got the distinct sense of shouting into a canyon with no echo. I might be able to find what I did to make it work; let me know if you have interest; better still, let me know if there is collective interest in making what IMHO would be a very useful change to the VM.
Bruce O'Neel The other thing you mention is that the network still responds. You could write a little listener and hang it off of some port (say 8888) and then you could connect and type squeak commands. This would tell you whether or not the VM is still processing squeak commands or if the VM itself is hung up.
The other thing you could do is just write a small network listener that as soon as you connect to a particlar port just executes some code to create a small file in /tmp or so Smalltalk snapshot: true andQuit: true
and either the image will be saved and you can debug it from a new instance (does the simulator work these days?) or nothing happens.
How to save a parts bin March 23, 2005 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.
Scott Wallace One good debug methods 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."
David T. Lewis 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
Cees de Groot And to add to the confusion, when the Linux images hangs it jumps to99% CPU time.I want a post-mortem image debugger
How to save a parts bin What I do is this to figure out where a hung or unresponsive squeak is:
gdb -p
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
Cees de GrootIs that being done while the image runs on? I'm asking because I get a whole list of processes in the same critical section, so I assume they're activated in turn while the printing is done (otherwise there's something
terribly wrong, but I can't believe that...).Is that being done while the image runs on?
How to save a parts bin No; you interrupt the running Squeak first, so one process is active. That one will (I believe) be printed first.
