compilation problem in guile-gtk CVS

compilation problem in guile-gtk CVS

[Stan Pinte]

hello,

the ./autogen.sh procedure in the latest guile-gtk-1.2, in CVS, complains 
about
a missing config.scm.in in the gtk directory. this files is well present in 
the gtk-1.2 directory.

any clue?

thanks a lot,

Stan.

Re: compilation problem in guile-gtk CVS

[Marius Vollmer]

Stan Pinte <alto_stan@wanadoo.be> writes:

> any clue?

Should be fixed now.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405

general debugging question

[Stan Pinte]

hello,

sorry to bother you with something which may have been asked 10e24 times already...

I am trying the guile-gtk-1.2 CVS version, which compiles fine, thanks Marius!

It is segfaulting somewhere...

Is my only solution putting 

(format #f ...) in all my code, until I spot the place, or is there a guilish solution to that problem? (like printing the stack, or printing each call to a function?)

or shall I use gdb? (and if yes, has anyone done that already?)

thanks,

Stan.

Re: general debugging question

[Neil Jerram]

>>>>> "Stan" == Stan Pinte <alto_stan@wanadoo.be> writes:

    Stan> It is segfaulting somewhere...

    Stan> Is my only solution putting

    Stan> (format #f ...) in all my code, until I spot the place, or is there a
    Stan> guilish solution to that problem? (like printing the stack, or
    Stan> printing each call to a function?)

If you know what the top level call is, say `foo-bar', and you are
using unstable CVS, the following _might_ successfully tell you the
last Scheme thing that happened before the segv:

guile> (use-modules (ice-9 debugger breakpoints))
guile> (use-modules (ice-9 debugger breakpoints procedural))
guile> (trace-subtree! foo-bar)
guile> (foo-bar)

    Stan> or shall I use gdb? (and if yes, has anyone done that already?)

It would be nice if one could ask for a Scheme backtrace from GDB; I
don't think this is possible today.  (Maybe try `call
scm_backtrace()'.)

        Neil

Re: general debugging question + Segfault in guile-gtk

[Stan Pinte]

hello,

NOTE: I am using guile-1.6.0, and guile-gtk-1.2 from CVS (refreshed this morning).

I have managed to use gdb, and here (enclosed below) is the backtrace of my segfault.

I see some functions that sound familiar to me, but I do not understand exactly what is the problem.

Do I need to extract more info from gdb? How can I do it?

Any ideas or suggestions?

thanks a lot!!

Stan.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 1112)]
0x4039c174 in sgtk_arg_cleanup (a=0xbfffe64c, obj=0x2174) at guile-gtk.c:2026
2026          if (BOXED_INFO (obj)->cleanup)
(gdb) bt
#0  0x4039c174 in sgtk_arg_cleanup (a=0xbfffe64c, obj=0x2174) at guile-gtk.c:2026
#1  0x4039c2e7 in inner_callback_marshal (data=0xbfffe538) at guile-gtk.c:2091
#2  0x40085cd6 in scm_internal_catch (tag=0x2374, body=0x4039c1e0 <inner_callback_marshal>, body_data=0xbfffe538, 
    handler=0x40078280 <cwdr_handler>, handler_data=0xbfffe4e8) at throw.c:205
#3  0x40078402 in scm_internal_cwdr (body=0x4039c1e0 <inner_callback_marshal>, body_data=0xbfffe538, 
    handler=0x40086260 <scm_handle_by_message_noexit>, handler_data=0x403cfd6d, stack_start=0xbfffe534) at root.c:283
#4  0x4039c391 in sgtk_callback_marshal (obj=0x81e6268, data=0x81f0dac, n_args=3, args=0xbfffe624) at guile-gtk.c:2121
#5  0x404a4844 in gtk_handlers_run () from /usr/lib/libgtk-1.2.so.0
#6  0x404a3bef in gtk_signal_real_emit () from /usr/lib/libgtk-1.2.so.0
#7  0x404a1b47 in gtk_signal_emit () from /usr/lib/libgtk-1.2.so.0
#8  0x4041b6b9 in gtk_clist_select_row () from /usr/lib/libgtk-1.2.so.0
#9  0x4041990e in real_insert_row () from /usr/lib/libgtk-1.2.so.0
#10 0x404194b7 in gtk_clist_append () from /usr/lib/libgtk-1.2.so.0
#11 0x403b0120 in sgtk_gtk_clist_append (p_clist=0x40bf4c78, p_text=0x40a1b198) at gtk-glue.c:5276
#12 0x4004952c in scm_deval (x=0x2974, env=0x40a210e8) at eval.c:3102
#13 0x400462c9 in scm_deval (x=0x40a1b040, env=0x40a1b008) at eval.c:2093
#14 0x40045cda in scm_deval (x=0x40bafe20, env=0x40c34778) at eval.c:1999
#15 0x40045cda in scm_deval (x=0x40bc5818, env=0x40bf4bf8) at eval.c:1999
#16 0x40044ec2 in scm_i_eval_x (exp=0x40bc5430, env=0x40bc5400) at eval.c:4010
#17 0x40044f77 in scm_primitive_eval_x (exp=0x40bc5430) at eval.c:4028
#18 0x40060489 in load (data=0x4026dcb0) at load.c:97
#19 0x400384f4 in scm_internal_dynamic_wind (before=0x40060420 <swap_port>, inner=0x40060460 <load>, after=0x40060420 <swap_port>, 
    inner_data=0x4026dcb0, guard_data=0xbfffede0) at dynwind.c:168
#20 0x4006057c in scm_primitive_load (filename=0x4026d820) at load.c:126
#21 0x40043800 in scm_ceval (x=0x2974, env=0x4026dc40) at eval.c:3158
#22 0x40044f29 in scm_i_eval (exp=0x8072850, env=0x4026dc40) at eval.c:4017
#23 0x400370ea in scm_start_stack (id=0x807e120, exp=0x8072850, env=0x4026dc40) at debug.c:529
#24 0x400371a0 in scm_m_start_stack (exp=0x4026dc48, env=0x4026dc40) at debug.c:545
#25 0x400441c0 in scm_apply (proc=0x806ee60, arg1=0x4026dc48, args=0x4026dc58) at eval.c:3536
#26 0x400423a4 in scm_ceval (x=0x4026dc48, env=0x4026dc40) at eval.c:2611
#27 0x40044451 in scm_apply (proc=0x4026dad8, arg1=0x2974, args=0x2974) at eval.c:3605
#28 0x40043999 in scm_call_0 (proc=0x4026daf0) at eval.c:3263
#29 0x400383b7 in scm_dynamic_wind (in_guard=0x4026db38, thunk=0x4026daf0, out_guard=0x4026db48) at dynwind.c:128
#30 0x40043800 in scm_ceval (x=0x402506b0, env=0x4026db30) at eval.c:3158
#31 0x400405c4 in scm_ceval (x=0x4026d838, env=0x4026da90) at eval.c:1971
#32 0x40044ec2 in scm_i_eval_x (exp=0x4026da70, env=0x4026da90) at eval.c:4010
#33 0x40044f77 in scm_primitive_eval_x (exp=0x4026da70) at eval.c:4028
#34 0x4004506f in inner_eval_x (data=0x4026da70) at eval.c:4075
#35 0x400384f4 in scm_internal_dynamic_wind (before=0x40044fd0 <change_environment>, inner=0x40045050 <inner_eval_x>, 
    after=0x40045010 <restore_environment>, inner_data=0x4026da70, guard_data=0x4026da78) at dynwind.c:168
#36 0x400450f0 in scm_eval_x (exp=0x4026da70, module=0x8084c30) at eval.c:4084
#37 0x4007abae in scm_shell (argc=4, argv=0xbffff3ec) at script.c:676
#38 0x8048916 in ?? ()
#39 0x4005cfa9 in invoke_main_func (body_data=0xbffff33c) at init.c:636
#40 0x4005cf57 in scm_boot_guile_1 (base=0xbffff338, closure=0xbffff33c) at init.c:616
#41 0x4005cc3c in scm_boot_guile (argc=4, argv=0xbffff3ec, main_func=0x8048900, closure=0x0) at init.c:440
#42 0x804894c in ?? ()
#43 0x40140c6f in __libc_start_main () from /lib/libc.so.6

Re: general debugging question + Segfault in guile-gtk

[Daniel Skarda]

Stan Pinte <alto_stan@wanadoo.be> writes:
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 1024 (LWP 1112)]
> 0x4039c174 in sgtk_arg_cleanup (a=0xbfffe64c, obj=0x2174) at guile-gtk.c:2026
> 2026          if (BOXED_INFO (obj)->cleanup)
> (gdb) bt
> #0  0x4039c174 in sgtk_arg_cleanup (a=0xbfffe64c, obj=0x2174) at guile-gtk.c:2026

   Oops, thats my code, fresh new code.... Mea culpa.

   Aha! 0x2174 is #f (SCM_BOOL_F) (no, I am not a wizard, I am using gdb.... :-)

   GuileGtk converts callbacks parameters to scheme types (according to
information from Gtk). Than it tries to clean-up data - and I forgot that
structures can also be converted to #f (which is not a boxed type).

      if (BOXED_INFO (obj)->cleanup)

   should be replaced by

      if (BOXED_P (obj) && BOXED_INFO(obj)->cleanup)

   Hope that this stops your problems. I am going to commit the fix to CVS ASAP.

Thank you for bug report,
0.

Re: general debugging question + Segfault in guile-gtk

[Stan Pinte]

On Thu, 28 Nov 2002 23:34:59 +0100
Daniel Skarda <0rfelyus@ucw.cz> wrote:

> Stan Pinte <alto_stan@wanadoo.be> writes:
> > Program received signal SIGSEGV, Segmentation fault.
> > [Switching to Thread 1024 (LWP 1112)]
> > 0x4039c174 in sgtk_arg_cleanup (a=0xbfffe64c, obj=0x2174) at guile-gtk.c:2026
> > 2026          if (BOXED_INFO (obj)->cleanup)
> > (gdb) bt
> > #0  0x4039c174 in sgtk_arg_cleanup (a=0xbfffe64c, obj=0x2174) at guile-gtk.c:2026
> 
>    Oops, thats my code, fresh new code.... Mea culpa.
> 
>    Aha! 0x2174 is #f (SCM_BOOL_F) (no, I am not a wizard, I am using gdb.... :-)
> 
>    GuileGtk converts callbacks parameters to scheme types (according to
> information from Gtk). Than it tries to clean-up data - and I forgot that
> structures can also be converted to #f (which is not a boxed type).
> 
>       if (BOXED_INFO (obj)->cleanup)
> 
>    should be replaced by
> 
>       if (BOXED_P (obj) && BOXED_INFO(obj)->cleanup)
> 
>    Hope that this stops your problems. I am going to commit the fix to CVS ASAP.


I verified, and it is ok!

Thanks a lot,

Stan.

> 
> Thank you for bug report,
> 0.
> 


-- 

Stanislas Pinte

Computer Consultant

Alto Software
20 Pl St Jacques
B-4000 Liège

web:		http://www.altosw.be
email:		alto_stan@wanadoo.be

guile-gtk-1.2 CVS % gtk-pixmap-new

[Stan Pinte]

hello,

apparently, gtk-pixmap-new has disappeared in the CVS version, (compared to version guile-gtk-1.2-0.31).

I changed the call from that function to gtk-pixmap-new-from-file, which works ok, but is this the desired change?

thanks,

NOTE: what's the preferred way to communicate to others the changes? the NEWS file? the CVS commit messages?

Stan.

Re: guile-gtk-1.2 CVS % gtk-pixmap-new

[Daniel Skarda]

> apparently, gtk-pixmap-new has disappeared in the CVS version, (compared to
> version guile-gtk-1.2-0.31).

  No, it does not have disappeared - it is still in gtk-1.2.defs, but now it has the
same meaning as gtk_pixmap_new from Gtk+:

  gtk/gtkpixmap.h:

GtkWidget* gtk_pixmap_new	 (GdkPixmap  *pixmap,
				  GdkBitmap  *mask);

  gtk-1.2.defs:

(define-func gtk_pixmap_new
  GtkWidget
  ((GdkPixmap pixmap)
   (GdkBitmap bitmap (null-ok) (= "NULL"))))

  Former (gtk-pixmap-new file parent) was "weaker" - it was not possible to
create GtkPixmaps from already existing GdkPixmap/GdkPitmaps etc.  I guess that
the old behaviour was old hack from times, when there were no bindings for
GdkPixmap/GdkBitmap types and functions.

  Because (< (guile-gtk-version) 1.0), I decided that there is still a time to
replace the hack by correct bindings that closely reflect C API. As you wrote,
I mentioned my change in ChangeLog and NEWS (that entry is not so clear about
the change), but I forgot to send an email (because there were so many changes
in my commit, that gtk-pixmap-new seemed to me as a cosmetic change).

  I am sorry if the change caused you big troubles.

> I changed the call from that function to gtk-pixmap-new-from-file, which works
> ok, but is this the desired change?

  Yes. gtk-pixmap-new-from-file implements code, that used to be in old
gtk-pixmap-new C hack.

0.

Re: guile-gtk-1.2 CVS % gtk-pixmap-new

[Stan Pinte]

On Fri, 29 Nov 2002 15:01:30 +0100
Daniel Skarda <0rfelyus@ucw.cz> wrote:

> 
>   gtk-1.2.defs:
> 
> (define-func gtk_pixmap_new
>   GtkWidget
>   ((GdkPixmap pixmap)
>    (GdkBitmap bitmap (null-ok) (= "NULL"))))
> 
>   Former (gtk-pixmap-new file parent) was "weaker" - it was not possible to
> create GtkPixmaps from already existing GdkPixmap/GdkPitmaps etc.  I guess that
> the old behaviour was old hack from times, when there were no bindings for
> GdkPixmap/GdkBitmap types and functions.
> 
>   Because (< (guile-gtk-version) 1.0), I decided that there is still a time to
> replace the hack by correct bindings that closely reflect C API. As you wrote,
> I mentioned my change in ChangeLog and NEWS (that entry is not so clear about
> the change), but I forgot to send an email (because there were so many changes
> in my commit, that gtk-pixmap-new seemed to me as a cosmetic change).
> 
>   I am sorry if the change caused you big troubles.
> 

No problem....just a tiny grep/replace problem

> > I changed the call from that function to gtk-pixmap-new-from-file, which works
> > ok, but is this the desired change?
> 
>   Yes. gtk-pixmap-new-from-file implements code, that used to be in old
> gtk-pixmap-new C hack.

It works perfectly anyway.

> 
> 0.
> 


-- 

Stanislas Pinte

Computer Consultant

Alto Software
20 Pl St Jacques
B-4000 Liège

web:		http://www.altosw.be
email:		alto_stan@wanadoo.be