Debugging Layout problems

Bob Arning arning at charm.net
Thu Dec 27 16:01:31 UTC 2001


Ross,

On Wed, 26 Dec 2001 22:01:37 -0800 Ross Boylan <RossBoylan at stanfordalumni.org> wrote:
>Here are some strategies that have occurred to me.  Which horse to bet
>on?
>
>1) Debug by inspection.  Unfortunately, I've looked at the code and
>the instance variables, and nothing has jumped out.  I do know where
>the problem is occurring because of the emergency evaluator stack
>trace.

There is a file "SqueakDebug.log" that is written even when the emergency evaluator is entered. This should give you more information than what is listed in the emergency evaluator. If worse comes to worse, try factoring the method where the error occurs into two or more parts so that you can narrow down exactly where the error is.

>5) Do old fashioned debugging with trace statements to a file.  Aside
>from the other problems, I'm not sure if buffering would prevent the
>interesting stuff from just before the problem from getting out.

You can send #flush to the file stream after each write to eliminate (or at least reduce) the possibility of losing data.

>I'm currently at 3.2alpha #4441.  Many months ago I remember that the
>system would sometimes display a red box with a yellow X across it in
>somewhat similar circumstances.  If there's a way to get that
>behavior, that would certainly make debugging easier.

The yellow-X-on-red is substituted when an error occurs while drawing a morph, thus avoiding endless errors redrawing the morph as a result of debuggers opening, etc. There are lots of other places for errors to happen that will not result in this handy recursion prevention.

Cheers,
Bob




More information about the Squeak-dev mailing list