[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
debugging stack overflow er
- To: info-mcl@cambridge.apple.com (info-mcl)
- Subject: debugging stack overflow er
- From: Laura_Bagnall@TERC.EDU (Laura Bagnall)
- Date: Thu, 13 Feb 1992 13:03:50 EST
- Cc: Chris_Hancock@TERC.EDU (Chris Hancock), Blake_Meike@TERC.EDU (Blake Meike)
- Organization: TERC, 2067 Mass. Ave., Cambridge, MA, 02140
REGARDING debugging stack overflow errors
I have a very mysterious problem that I am having considerable
difficulty in debugging, so I thought I'd as the list if anybody has
seen anything similar or could give me any pointers to how to
go about debugging it.
I have created a stand-alone application with the following toplevel-loop.
(defun tabletop-toplevel ()
(event-dispatch)
(handler-case
(progn
(eval (get-next-queued-form))
(process-app-events)) ;;<- defined by our application.
(error () nil)))
It works just fine for maybe 10 or 20 minutes, at which point it bombs
out with Stack Overflow error while running function X, where X has been at
various times POINTERP, FRONT-WINDOWS, CCL::WAIT-NEXT-EVENT-SLEEP-TICKS,
SLOT-VALUE, FIND-CLASS, GET-NEXT-EVENT. At this point the application is
dead in the water, and the only solution is to reboot. This happens whether
or not
the application has any windows open or whether it is running in the
foreground
or the background. I have deduced that it must be happening inside the call
to EVENT-DISPATCH, otherwise I wouldn't even see the error message because
of the HANDLER-CASE. In addition, it is almost certainly happening when
a null-event is received, because it has happened when the application is in
the
background and I haven't touched the machine since I started the
application.
Background applications can only receive update, null or high-level events,
and
there wouldn't be any update events without any windows being moved around
and I can't think of any high-level events that would be floating around.
Having gotten this far, I'm kind of stuck. I presume that there is some
infinite
recursion going on somewhere, which is the usual reason for stack overflow.
Is there anything else which would cause stack overflow errors? Has anybody
seen anything like this before? Any debugging hints? I'm currently
resorting
to looking at the disassembled code for EVENT-DISPATCH and CCL::DO-EVENT
(Blech!) in order to try to figure out what the system does when it receives
a
null event. Anyone got any better ideas?
Thanks
Laura