* compilation problem in guile-gtk CVS @ 2002-11-21 0:01 Stan Pinte 2002-11-22 12:44 ` Marius Vollmer 0 siblings, 1 reply; 10+ messages in thread From: Stan Pinte @ 2002-11-21 0:01 UTC (permalink / raw) To: guile-gtk; +Cc: guile-user 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: compilation problem in guile-gtk CVS 2002-11-21 0:01 compilation problem in guile-gtk CVS Stan Pinte @ 2002-11-22 12:44 ` Marius Vollmer 2002-11-28 0:18 ` general debugging question Stan Pinte 0 siblings, 1 reply; 10+ messages in thread From: Marius Vollmer @ 2002-11-22 12:44 UTC (permalink / raw) To: Stan Pinte; +Cc: guile-gtk, guile-user 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* general debugging question 2002-11-22 12:44 ` Marius Vollmer @ 2002-11-28 0:18 ` Stan Pinte 2002-11-28 2:32 ` Neil Jerram 0 siblings, 1 reply; 10+ messages in thread From: Stan Pinte @ 2002-11-28 0:18 UTC (permalink / raw) To: Marius Vollmer; +Cc: guile-gtk, guile-user 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: general debugging question 2002-11-28 0:18 ` general debugging question Stan Pinte @ 2002-11-28 2:32 ` Neil Jerram 2002-11-28 9:23 ` general debugging question + Segfault in guile-gtk Stan Pinte 0 siblings, 1 reply; 10+ messages in thread From: Neil Jerram @ 2002-11-28 2:32 UTC (permalink / raw) To: alto_stan; +Cc: Marius Vollmer, guile-gtk, guile-user >>>>> "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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: general debugging question + Segfault in guile-gtk 2002-11-28 2:32 ` Neil Jerram @ 2002-11-28 9:23 ` Stan Pinte 2002-11-28 14:37 ` Daniel Skarda 0 siblings, 1 reply; 10+ messages in thread From: Stan Pinte @ 2002-11-28 9:23 UTC (permalink / raw) To: Neil Jerram; +Cc: guile-gtk, guile-user 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: general debugging question + Segfault in guile-gtk 2002-11-28 9:23 ` general debugging question + Segfault in guile-gtk Stan Pinte @ 2002-11-28 14:37 ` Daniel Skarda 2002-11-28 23:53 ` Stan Pinte 2002-11-28 23:53 ` guile-gtk-1.2 CVS % gtk-pixmap-new Stan Pinte 0 siblings, 2 replies; 10+ messages in thread From: Daniel Skarda @ 2002-11-28 14:37 UTC (permalink / raw) To: alto_stan; +Cc: Neil Jerram, guile-gtk, guile-user 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: general debugging question + Segfault in guile-gtk 2002-11-28 14:37 ` Daniel Skarda @ 2002-11-28 23:53 ` Stan Pinte 2002-11-28 23:53 ` guile-gtk-1.2 CVS % gtk-pixmap-new Stan Pinte 1 sibling, 0 replies; 10+ messages in thread From: Stan Pinte @ 2002-11-28 23:53 UTC (permalink / raw) To: Daniel Skarda; +Cc: neil, guile-gtk, guile-user 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* guile-gtk-1.2 CVS % gtk-pixmap-new 2002-11-28 14:37 ` Daniel Skarda 2002-11-28 23:53 ` Stan Pinte @ 2002-11-28 23:53 ` Stan Pinte 2002-11-29 11:56 ` Daniel Skarda 1 sibling, 1 reply; 10+ messages in thread From: Stan Pinte @ 2002-11-28 23:53 UTC (permalink / raw) To: guile-gtk; +Cc: guile-user 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: guile-gtk-1.2 CVS % gtk-pixmap-new 2002-11-28 23:53 ` guile-gtk-1.2 CVS % gtk-pixmap-new Stan Pinte @ 2002-11-29 11:56 ` Daniel Skarda 2002-12-01 2:48 ` Stan Pinte 0 siblings, 1 reply; 10+ messages in thread From: Daniel Skarda @ 2002-11-29 11:56 UTC (permalink / raw) To: alto_stan; +Cc: guile-gtk, guile-user > 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: guile-gtk-1.2 CVS % gtk-pixmap-new 2002-11-29 11:56 ` Daniel Skarda @ 2002-12-01 2:48 ` Stan Pinte 0 siblings, 0 replies; 10+ messages in thread From: Stan Pinte @ 2002-12-01 2:48 UTC (permalink / raw) To: Daniel Skarda; +Cc: guile-gtk, guile-user 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2002-12-01 10:48 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-11-21 0:01 compilation problem in guile-gtk CVS Stan Pinte 2002-11-22 12:44 ` Marius Vollmer 2002-11-28 0:18 ` general debugging question Stan Pinte 2002-11-28 2:32 ` Neil Jerram 2002-11-28 9:23 ` general debugging question + Segfault in guile-gtk Stan Pinte 2002-11-28 14:37 ` Daniel Skarda 2002-11-28 23:53 ` Stan Pinte 2002-11-28 23:53 ` guile-gtk-1.2 CVS % gtk-pixmap-new Stan Pinte 2002-11-29 11:56 ` Daniel Skarda 2002-12-01 2:48 ` Stan Pinte
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).