Opened 12 years ago
Closed 10 years ago
#232 closed enhancement (fixed)
New backtrace-as-list function
Reported by: | jwiele | Owned by: | gb |
---|---|---|---|
Priority: | minor | Milestone: | |
Component: | Compiler | Version: | |
Keywords: | Cc: |
Description
SBCL has a sb-debug::backtrace-as-list function which returns the backtrace summary in list form. This is useful for certain kinds of tracing and profiling. The attached diff adds a similar function to OpenMCL/CCL.
Attachments (1)
Change History (4)
Changed 12 years ago by jwiele
comment:1 Changed 12 years ago by gb
- Status changed from new to assigned
comment:2 Changed 12 years ago by gb
I actually looked at the patch a bit (as soon as my knee stopped jerking.) The builtin "tty" backtrace (the :b break loop command, which invokes PRINT-CALL-HISTORY) just prints a terse summary of each function call (with a lot of *print-level*/*print-length* truncation and with a lot of elipses to indicate missing detail; there'a a :detailed-p option that shows (current) argument and local values.
Ignoring the issue of whether it's a good idea to capture stack-allocated values when that might be a bad idea (e.g., treating BACKTRACE-AS-LIST as being enough rope to hang yourself with), do you really want to just capture the stuff that ordinarily goes into that terse summary ? Or would you rather try to have more information about (at least the current values of) all arguments ?
comment:3 Changed 10 years ago by rme
- Resolution set to fixed
- Status changed from assigned to closed
ccl::backtrace-as-list seems to have appeared in r8973
What are the consequences of capturing stack-allocated (DYNAMIC-EXTENT) objects in a list ? (I suppose that the real question involves the consequences of returning that list upward.)
Might there be other ways of doing certain kinds of tracing/profiling (whatever they might be) that don't raise these issues ?
(I honestly don't know whether this is a good idea or not; I'll try to look at it.)