Delivered-To: lablgtk at yquem.inria.fr Date: Wed, 28 Nov 2007 08:47:21 +0900 (JST) Message-Id: <20071128.084721.74752347.garrigue at math.nagoya-u.ac.jp> To: bsd at cs.ubc.ca Subject: Re: [Lablgtk] Re: SIGSEGV with lablgtk for GTK+ 2 From: Jacques Garrigue In-Reply-To: <20071127225520.GA27623 at monolith.usask.ca> References: <20071127.141140.182616637.garrigue at math.nagoya-u.ac.jp> <20071127172200.GC3857@monolith.usask.ca> <20071127225520.GA27623@monolith.usask.ca> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Cc: lablgtk at yquem.inria.fr Content-Type: Text/Plain; charset=us-ascii Content-Length: 3332 Dear Brian, Thanks for this very detailed report, and sorry for the wrong information in the README. I've just fixed it. So it looks like NetBSD really uncovers the pointer problem in Val_GType. Luckily this should be solved easily, but as you found quickly there ma be some stray Val_int around. For this particular case, I think the following patch should do the job: Index: src/ml_gobject.c =================================================================== --- src/ml_gobject.c (revision 1388) +++ src/ml_gobject.c (working copy) @@ -51,7 +51,7 @@ Make_Val_final_pointer(GObject, g_object_ref, ml_g_object_unref_later, 0) Make_Val_final_pointer_ext (GObject, _new, Ignore, ml_g_object_unref_later, 20) -ML_1 (G_TYPE_FROM_INSTANCE, GObject_val, Val_int) +ML_1 (G_TYPE_FROM_INSTANCE, GObject_val, Val_GType) // ML_1 (g_object_ref, GObject_val, Unit) CAMLprim value ml_g_object_unref (value val) { Tell me if it works, and if you see any other problem. Jacques From: Brian de Alwis > Just to be sure that the GType_val/Val_GType change is sufficient, > I also tried another ocaml+lablgtk based app, mldonkey. Unfortunately > mldonkey crashes with similar-looking pointer issues (e.g., see frame #2): > > Program received signal SIGSEGV, Segmentation fault. > 0xbbb46545 in type_node_check_conformities_UorL (node=0x75ccc400, > iface_node=0xbae661c0, support_interfaces=1, support_prerequisites=1, > have_lock=0) at gtype.c:2719 > 2719 if (/* support_inheritance && */ > (gdb) where > #0 0xbbb46545 in type_node_check_conformities_UorL (node=0x75ccc400, > iface_node=0xbae661c0, support_interfaces=1, support_prerequisites=1, > have_lock=0) at gtype.c:2719 > #1 0xbbb467ce in type_node_conforms_to_U (node=0x75ccc400, > iface_node=0xbae661c0, support_interfaces=1, support_prerequisites=1) > at gtype.c:2753 > #2 0xbbb46790 in IA__g_type_is_a (type=1976353793, iface_type=3135660480) > at gtype.c:2765 > #3 0x0829ab5d in ml_g_type_is_a () > #4 0x081d9e87 in camlGobject__is_a_263 () > #5 0x75ccc401 in ?? () > #6 0xbae661c0 in ?? () > #7 0xbab22718 in ?? () > #8 0xbae661c0 in ?? () > #9 0x081d9ea0 in camlGobject__try_cast_268 () > #10 0x083030ec in camlGuiTools__73 () > [... 36 other frames removed ...] > > The type id value in frame #2 (as well as the node pointer values > in frames 0 and 1) look suspiciously like the bit-shifting problems > from before. I'd hazard that there is a stray Long_val somewhere? > mldonkey apparently works fine on an amd64 machine, presumably > because its longs are 64 bits and so preserve the relevant bits. > > I'm unfortunately way out of my depth in trying to trace this :-( > I'm happy to try patches, or I could put together a NetBSD Live CD > with ocaml and gtk2 if that would help. > > Brian. > > -- > Brian de Alwis | Software Practices Lab | UBC | http://www.cs.ubc.ca/~bsd/ > "Amusement to an observing mind is study." - Benjamin Disraeli > > _______________________________________________ > Lablgtk mailing list > Lablgtk@yquem.inria.fr > http://yquem.inria.fr/cgi-bin/mailman/listinfo/lablgtk _______________________________________________ Lablgtk mailing list Lablgtk@yquem.inria.fr http://yquem.inria.fr/cgi-bin/mailman/listinfo/lablgtk