[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Enabling Debugging
From: |
Neil Jerram |
Subject: |
Re: Enabling Debugging |
Date: |
Mon, 04 Sep 2006 08:35:37 +0100 |
User-agent: |
Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux) |
Volkan YAZICI <address@hidden> writes:
> On Jul 31 10:53, dave wrote:
>> I had to work through this a while back, and the problem I had was that
>> there are two types of error handler callback - one is called before the
>> stack is unwound, the other after. If you only set the error callback
>> for after the unwind there is no stack to do the debugging...
>
> Can you send an example working code snippet please?
You've probably seen the new doc on this subject that I posted to the
guile list a few days ago. This is also now in the CVS reference
manual (node "Debug on Error"), and I hope that it answers most of
your questions; please let me know if not.
> I've considered your "before the stack is unwound and the other after"
> explanation and concluded with such a scm_c_catch() call:
>
> scm_c_catch(SCM_BOOL_T, /* tag */
> (scm_t_catch_body) eval_code, /* body */
> (void *) code, /* body data */
> (scm_t_catch_handler) catch_err, /* handler */
> (void *) code, /* handler data */
> (scm_t_catch_handler) unwind_catch,
> (void *) code);
>
> But scm_backtrace(), that's placed in both catch_err() and
> unwind_catch(), still complains that "No backtrace available".
Yes; this is because the stack still needs to be captured explicitly
by a scm_make_stack call, within unwind_catch.
> Doesn't anybody have a working example code snippet? How did ppl achieve
> to write so much programs using guile?
I personally like to write as much as possible in Scheme, so I'm
afraid I don't have a tested example.
(In other words, I make a single call out from C to Scheme, using
scm_call or scm_apply, then code whatever exception handling I need
in Scheme, within the function that was called from C.)
> Furthermore, I've another problem: How do we receive information from
> tag and args variables passed to exception handlers? I was using
>
> buf = SCM_STRING_CHARS(tag);
> len = SCM_STRING_LENGTH(tag);
> while (len-- > 0)
> putchar(*buf++);
>
> method but, in the new 1.8 release it says that I'm using deprecated
> functions. So how can get the pointer pointing to the related text
> buffer? I cannot use gh_scm2newstr() in this situation, because it
> allocates required buffer itself and just dumps an error to stderr
> in case of a failure. Actually, I'm working on a shared memory segment
> thus I don't want guile to make any memory allocations on its own.
> Can I achieve such a functionality? (I want it to use palloc/pfree
> instead of recent malloc/free calls.) Can a macro hack like
>
> #define malloc palloc
> #define free pfree
>
> solve that problem?
The tag is actually a symbol. What do you want to do with it? If you
want to test it for equality (with scm_misc_error_key, for example),
use "scm_is_eq (tag, scm_misc_error_key)". If you want to print it
out to the current output port, use "scm_display (tag,
SCM_UNDEFINED)".
> Moreover, as far as SCM_CONSP(args) says so, the third param (args)
> passed to exception handlers is a cons. Despite I've tried some
> gh_car(), gh_cdr() tricks, I couldn't manage to figure out how to use
> that information too.
This - i.e. knowing how to interpret exception args - is an ongoing
problem. Please see and contribute to the discussion in another
thread.
Regards,
Neil
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: Enabling Debugging,
Neil Jerram <=