Just this week I was struggling with a customer problem, that “froze” the entire application. The debugger was of no use, since it was part of the test case to reproduce the problem. On the bright side, I knew exatly, which method was called, that finally caused the “freeze”. Unfortunately, the “freeze” happened only under very vertain circumstances. All other calls to this method where fine and did not cause the problem.

What was so different from the test case, to all the other calls?

I wanted to see the call stack and check for differences there.
How can you do that, when the application doesn’t respond any more?
In VW and OS8, you can get the entire call stack.
Here is the code, I’ve inserted into the method:

’>>>>>>>>>>>>>>>>>>>>>>>>>>>>>’ out.
Processor activeProcess name out.
(CraftedSmalltalk.DebuggerService shortStackFor: thisContext ofSize: 50) out.
’>>>>>>>>>>>>>>>>>>>>>>>>>>>>>’ out.

This code, plus logging the transcript output to a file, helped me to identify the differences in the call stack. I found a possible workaround and I’m sure we’ll find a good solution for the problem.

Andreas
———————————————
Quis Custodiet Ipsos Custodes?