On Tue, Feb 10, 2009 at 02:08:59PM +0200, Nikodemus Siivola wrote:
> 2009/2/9 David Creelman <creelman.david@...>:
> (I took the liberty of adding sbcl-help back to CC.)
Thanks for that.
> > I have a function, check-reminders, that has an error in. I've added
> > (trace check-reminders) just after the definition of the function. The trace
> > seems to get registered, but when I run the function I don't get any traces.
> (defun foo () ...)
> (trace foo)
> in a file, and not getting a trace when you call FOO sounds odd. A
> session transcript would be helpful here. File or non-file scope is
> not really an issue here: TRACE replaces the function definition with
> a traced one.
> > If I do the trace in another file that loads reminder-calcs, I get
> > 0: (CHECK-REMINDERS 3328), but the function doesn't seem to get traced.
> > reminder-calcs gets compiled and loaded via asdf.
> This is from the traced function wrapper, so things *are* getting traced.
Yes, I just misread it.
> 0: (CHECK-REMINDERS 3328)
> if there is no corresponding
> 0: CHECK-REMINDERS returned ...
> line, then perhaps CHECK-REMINDERS doesn't return normally, but unwinds?
It looks like this is what was happening. After I fixed the bug, I got the
following in my log
0: (CHECK-REMINDERS 3329)
0: CHECK-REMINDERS returned
The bug was in check-reminders, but I misread the first of the above two lines
and thought they were something that happened when I requested the trace.
But it was doing exactly the right thing and logging that it had entered
check-reminders, then breaking on the error.
The error turned out to be passing nil as the second arg to /. It reported it
as Y not set to a value. I had a Y var in my code, so I thought I had not set
it. It looks like it was more likely Y of something like
(defun / (x y) (code ...)).
> > If I do (untrace) and then (trace) in a test file, I don't seem to get any
> > traces either. I was kind of expecting everything to be traced with this
> > approach. This makes me think that there is some other statement that I'm
> > missing which will turn off optimization or include debugging data, but I'm
> > not sure.
> Plain (TRACE) does exactly nothing. To trace all functions in a
> package you can do
> (trace "PACKAGE-NAME")
Okay, that might be useful next time. Thanks.
> . Plain (UNTRACE) untraces everything.
> Also: common reason for thing not being traced is inlining: inlined
> calls to functions cannot be traced. If you have declaimed things
> INLINE, TRACE will not work. Similarly, macros aren't ever traced (in
> case that wasn't obvious.)
Okay, that makes sense. In this case, that wasn't the problem.
> One additional possibility is *TRACE-OUTPUT* being bound or set to a
> stream that doesn't show up in your REPL.
This wasn't happening either, but I'll remember that too.
Thanks for your help and the extra info on trace.
> -- Nikodemus