[Openmcl-devel] how do I debug this?

[Gary Byers]

On Thu, 11 Nov 2004, alex crain wrote:

> >
> >>
> >> Helpful suggestions, anyone?
> >
> > I'd be interested to know which thread had the bogus ALLOCPTR.  You can
> > often get a strong hint of this by showing (L)isp registers and
> > (R)egisters
> > in the kernel debugger.  (If there -is- some sort of memory corruption,
> > the kernel debugger is likely to choke trying to print lisp values, but
> > it's worth a try.)
>
> Is there any way to force the system into the kernel debugger?

? (ccl::dbg)

CCL::DBG takes an optional argument (which defaults to NIL); that value's
just stored in r23/arg_z and returned from CCL::DBG when it returns from
the kernel debugger.  (Sometimes it's handy to use a string, as in:

(cond ((evenp x) (do-even-case x))
      ((oddp x) (do-odd-case x))
      (t (ccl::dbg "X is in that little-known third category")))



)

>
> I'm often finding that I'd like to debug some other thread then the one
> that I have access to: typically something is goofy in a cocoa thread
> but I don't have a listener there - can I drop into the kernel debugger
> and look at things in the other threads? If I can and do, will I be able
> to resume execution when I'm done?

Any time that the kernel debugger is entered, it tries to suspend all
other threads (so (B)acktrace shows the state of things as of some point
at or slightly after the time that the debugger is entered.)

Unfortunately, all of the register-display commands (R,L,F) just show
the current thread's registers.

I've certainly stooped to using CCL::DBG to try to debug Cocoa event-
process stuff.

It's also possible to use GDB to debug low-level issues, but it's
almost impossible to explain how.