Re: guile-debugging: how to access source properties from trap context

[Holger Blasum <holgerlists@blasum.net>]

[-- Attachment #1.1: Type: text/plain, Size: 5070 bytes --]

Hello Neil,

On 01-03, Neil Jerram wrote:
> Holger Blasum <holgerlists@blasum.net> writes:
> Perhaps it would make sense for the debugger to show the source
> position automatically on each step?  What do you think?

At least gdb, pydb (python) and ocamldebug (ocd) do this. But any
verbosity trade-offs are better left to your consideration ...
For reference here are the current ocamldebug and pydb default styles:
(ocd) s
Time : 2 - pc : 4164 - module Pervasives
112   float_of_bits 0x7F_F0_00_00_00_00_00_00L<|a|>
(pydb) step
?() at server.py:1
1    from SocketServer import StreamRequestHandler, ThreadingTCPServer

> So are you really looking for a _non_-interactive solution then?
> In that case I recommend the trace-trap and trace-until-exit
> behaviours provided by (ossau trace), and `set-trace-layout' to
> configure exactly what trace output you want at each trap point.

Wonderful, works great ;) 

> Thanks.  Can you suggest some wording that would make it clear that
> these are not the _only_ available procedures for getting information
> out of a trap context?  (Perhaps something including a reference back
> to 2.4.2?)

Perhaps: 
"In addition to the trap low-level context functions given in section 2.4.2, 
high-level trap context access is offered by the trap context
object. It is an object that ..." 
Perhaps merge 2.4.1 with 2.4.3 and 2.4.2 with 2.4.4? 

> What about instead adding a whole new "Examples" chapter before the
> current "Traps" one, containing the examples that we've discussed in
> this thread, and other useful ones as they arise in future?  I think
> that would be easier for a reader to find than an example buried
> inside 2.10, and would allow 2.10 and its neighbours to keep their
> existing more reference-style flavour.

Yes! For more feedback, I've also been asked whether instead of 
the number of applications I could give the number of time. (Like 
in petite scheme "(time (some-evaluation))").

> Also, I'm still not quite clear what you mean by profiling.  Which of
> the examples that we've discussed best fits what you have in mind?

The trace-trap example you gave last might fit closest. 

Just as a last addendum, I've run into a garbage-collection segfault 
with the combination minlog 4.0/guile-core.unstable-20060105/
guile-debugging-0.12/i686 GNU/Linux 2.6.14 #4.

(gdb) file /usr/local/bin/guile
(gdb) run
guile>  (use-modules (ossau breakpoints) (ossau trace))
guile> (debug-set! stack 0)
guile> (debug-set! depth 0)
guile> (debug-set! maxdepth 0)
guile> (debug-set! indent 0)
guile> (debug-set! width 0)
guile> (set-trace-layout "~20@a: ~a\n" trace/source trace/info)
guile> (break-in 'set-goal #:behaviour (list trace-trap
trace-until-exit))
guile> (load "examples/analysis/extraction.scm.guile")
Program <guile> received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1211029280 (LWP 24947)]
0xb7f424d5 in scm_gc_mark (ptr=0xb6fb8490) at gc-mark.c:160
160     {
0xb7f36538 in scm_gc_mark (ptr=Variable "ptr" is not available.
) at gc-mark.c:168
168       scm_gc_mark_dependencies (ptr);
#0  0xb7f36538 in scm_gc_mark (ptr=Variable "ptr" is not available.
) at gc-mark.c:168
#1  0xb7f363e9 in scm_gc_mark_dependencies (p=0xb6085db0) at
gc-mark.c:270
#2  0xb7f3653d in scm_gc_mark (ptr=Variable "ptr" is not available.
) at gc-mark.c:168
...

Remarkably, one then can segfault gdb too by asking it via "bc -10" 
to spit out the ten outer 10 stack frames.

#149734 0xb7f70a19 in scm_shell (argc=1, argv=0xbfbd7cd4) at
script.c:737
#149735 0xb7f51515 in invoke_main_func (body_data=0xbfbd7c04) at
init.c:367
#149736 0xb7f25040 in c_body (d=0xbfbd7b78) at continuations.c:359
#149737 0xb7f91106 in scm_internal_catch (tag=0x104, body=0xb7f25030
<c_body>,
    body_data=0xbfbd7b78, handler=0xb7f25050 <c_handler>,
    handler_data=0xbfbd7b78) at throw.c:173
#149738 0xb7f2500d in scm_i_with_continuation_barrier (
    body=0xb7f25030 <c_body>, body_data=0xbfbd7b78,
    handler=0xb7f25050 <c_handler>, handler_data=0xbfbd7b78)
    at continuations.c:336
Program <gdb> received signal SIGSEGV, Segmentation fault.
0x08152319 in dwarf2_frame_cache (next_frame=0xfcf0698,
this_cache=0xfcf0ae8) at dwarf2-frame.c:637
(Info of last line of course comes from running "minlog from guile
from gdb from gdb".)

I then tried to find an easier test case to reproduce this (without
the theorem prover context), but (define (rec n) (case n ((1) 1) 
(else (rec (- n 1))))) does *not* break guile even on things 
like (rec 1000000) where presumably a million of frames is 
on the stack(?, if not how does one turn off tail recursion optimizations 
and the like) ... :(

Cheers,

-- 
Holger Blasum +49-174-7313590 (gsm) GnuPG 1024D/ACDFC3B769DC1ED66B47
"It has turned out that the networking of many small computers, at many 
places, is more efficient than the one supercomputer - the success of 
the internet is based on this principle." - Angela Merkel, government
declaration, 30 Nov 2005

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 140 bytes --]

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user