Re: problem becouse scm_tc7_contin is not defined

[P Pareit]

On Tuesday 10 September 2002 09:04 pm, you wrote:
> P Pareit <address@hidden> writes:
> > Tried and failed, it does compile but I get a segment fault at
> > startup and scm_internal_cwdr_no_unwind shows up in the
> > backtrace. So I think this is the problem.
>
> Hmm.  I tried my version of scm_internal_cwdr_no_unwind with guile-gtk
> and it did work without problems.  Are you sure that you don't run
>
> into this:
> > > This will _only_ work when HANDLER does not do a non-local exit (via
> > > longjmp, or similar).  If you want to support that (which I
> > > recommend), you need to defer running HANDLER (with the same trick
> > > that scm_internal_cwdr uses) until scm_dynwinds has been restored.
>
> Could you try this version: (yeah, I could download Scwm and do this
> myself, but... ;)
>
> SCM
> scm_internal_cwdr_no_unwind (scm_catch_body_t body, void *body_data,
>                            scm_catch_handler_t handler, void *handler_data,
>                            SCM_STACKITEM *stack_start)
> {
>   return scm_internal_cwdr (body, body_data, handler, handler_data,
>                           stack_start);
> }
>
> That version is not very interesting but it will ket us see whether
> the bug is with scm_internal_cwdr_no_unwind or with some other part of
> Scwm or Guile.
>

Well, it gave me absolutly the same bactrace as before:

(gdb) backtrace
#0  0x4007bd5c in scm_hook_empty_p (hook=0x0) at hooks.c:227
#1  0x0806069e in scwm_handle_error (data=0x809023a, tag=0x80a8f50,
    throw_args=0x404825a8) at callbacks.c:501
#2  0x400a0811 in scm_internal_catch (tag=0x2374, body=0x400a0a30 <cwss_body>,
    body_data=0xbffff240, handler=0x8060650 <scwm_handle_error>, 
    handler_data=0x809023a) at throw.c:200
#3  0x400a0aae in scm_internal_stack_catch (tag=0x40497c38, body=0,
    body_data=0x0, handler=0x8060650 <scwm_handle_error>, 
    handler_data=0x809023a) at throw.c:330
#4  0x08060550 in scwm_body_eval_str (body_data=0x8092120) at callbacks.c:451
#5  0x400a0839 in scm_internal_catch (tag=0x2374,
    body=0x80604e0 <scwm_body_eval_str>, body_data=0x8092120,
    handler=0x40094160 <cwdr_handler>, handler_data=0xbffff3e0) at throw.c:205
#6  0x400942a4 in scm_internal_cwdr (body=0x80604e0 <scwm_body_eval_str>,
    body_data=0x8092120, handler=0x805686c <scm_handle_by_message_noexit>, 
    handler_data=0x809023a, stack_start=0x0) at root.c:283
#7  0x0806ef4f in scm_internal_cwdr_no_unwind (
    body=0x80604e0 <scwm_body_eval_str>, body_data=0x8092120,
    handler=0x805686c <scm_handle_by_message_noexit>, handler_data=0x809023a,
    stack_start=0xbffff464) at guile-compat.c:64
#8  0x08060782 in scwm_safe_eval_str (
    string=0x8092120 "\n\n\n\n\n\n\n\n(use-modules (app scwm 
optargs))\n\n(define-public guile-version (+ (string->number (major-version)) 
\n\t\t\t\t(/ (string->number (minor-version)) 10)))\n\n\n\n(if (> 
guile-version 1.3)\n    (setvbuf (cur"...) at callbacks.c:532
#9  0x0807f55d in scwm_main (argc=134932312, argv=0x5b) at scwm.c:1220
#10 0x40072ebe in gh_launch_pad (closure=0x807ed20, argc=1, argv=0xbffff944)
    at gh_init.c:60
#11 0x4007c987 in invoke_main_func (body_data=0x0) at init.c:636
#12 0x4007c942 in scm_boot_guile_1 (base=0xbffff88c, closure=0xbffff890)
    at init.c:616
#13 0x4007c63b in scm_boot_guile (argc=0, argv=0x0, main_func=0, closure=0x0)
    at init.c:440
#14 0x40072ef9 in gh_enter (argc=1, argv=0xbffff944,
    c_main_prog=0x807ed20 <scwm_main>) at gh_init.c:70
#15 0x0807ed0b in main (argc=1, argv=0xbffff944) at scwm.c:607
#16 0x4030c082 in __libc_start_main () from /lib/i686/libc.so.6
(gdb) 

The problem seems to start at #8, I wonder what happens if something goes 
wrong in the evaluation of "(use-modules (...))".

>
> I've contacted the Scwm developers as well, but I would be happy if
> you could continue to handle this.

Yes, I will. One of the things that I might best do, is to write an a small as 
possible program that uses guile in the same way as scwm now. 

pieter;