Delivered-To: lablgtk at yquem.inria.fr Date: Mon, 26 Nov 2007 20:51:36 -0600 From: Brian de Alwis To: lablgtk at yquem.inria.fr Message-ID: <20071127025136.GA6909 at monolith.gateway.2wire.net> References: <20071126204522.GA8290 at monolith.gateway.2wire.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20071126204522.GA8290 at monolith.gateway.2wire.net> Subject: [Lablgtk] Re: SIGSEGV with lablgtk for GTK+ 2 Content-Type: text/plain; charset=us-ascii Content-Length: 5423 Thanks for your reply Jacques. I was running the examples using lablgtktop, but didn't show that -- sorry. I've been trying to trace through this SIGSEGV a bit more. I'm running this on NetBSD/i386 4.99.35 -- this is a 32-bit machine. I've discovered that the cause is a combination of NetBSD's malloc allocating objects above the 2GB line (thus the top-most bit is set) and the GType_val/Val_GType definitions that aren't preserving the full 32 bits. I can reproduce this crash simply by providing the following snippet to the lablgtktop interpreter: let w = GWindow.window ~show:true ();; for example: $ CAML_LD_LIBRARY_PATH=../src gdb ../src/lablgtktop (gdb) run -w s -I ../src Starting program: /tmp/obj/x11/lablgtk/work/lablgtk-2.10.0/src/lablgtktop -w s -I ../src Objective Caml version 3.10.0 # let w = GWindow.window ~show:true ();; Program received signal SIGSEGV, Segmentation fault. 0xbb488252 in IA__g_type_fundamental (type_id=983598912) at gtype.c:3100 3100 return node ? NODE_FUNDAMENTAL_TYPE (node) : 0; (gdb) where #0 0xbb488252 in IA__g_type_fundamental (type_id=983598912) at gtype.c:3100 #1 0x080a9323 in ml_G_TYPE_FUNDAMENTAL (arg1=1967197825) at ml_gobject.c:87 #2 0x080ca233 in caml_interprete () #3 0x080bb309 in caml_main () #4 0x080bb505 in main () (gdb) Note the type_id being provided to IA__g_type_fundamental. If I re-run the example having put a breakpoint on IA__g_type_from_name, the above example causes reveals that the IA__g_type_from_name is called to look up "GtkWindow" and the return value, the `GType type', is 3131082560. Looking at these different values in binary: 3131082560: 0b10111010101000001000011101000000 (0xBAA08740) 983598912: 0b00111010101000001000011101000000 (0x3AA08740) 1967197825: 0b1110101010000010000111010000001 (0x75410E81) And the type id is transformed to and from the ocaml interpreter using the GType_val (= Long_val) and Val_GType (= Val_long) macros, whose definitions do bit shifts and only preserve the lower 31 bits and loses the top-most bit. So the ultimate cause is that * glib uses the memory address for non-fundamental types as the GType, * NetBSD's malloc causes these non-fundamental types to be allocated > 2GB, such that the top-most bit is set, and * the lablgtk mapping treats the GTypes as longs in ocaml, which don't have sufficient capacity to represent the full possible range. Is there a better GType_val/Val_GType macro combination? Since the pointers on 32-bit machine are 4-byte aligned, perhaps instead of shifting, we could use instead use next-lowest bit to distinguish whether the value is a fundamental type or a derived type? Brian. On 2007.11.26 14:45:22 -0600, Brian de Alwis wrote: > Hello everybody. I'm not an ocaml or lablgtk user, but rather a > happy user of unison. I'm not cc'd to this list, so I've redirected > replies to both myself and the list. > > I recently did a big recompile including ocaml, lablgtk, and unison. > I use pkgsrc.org. unison now cores with a SIGSEGV when trying to > use its lablgtk-based UI ('graphics' mode): > > (gdb) where > #0 0xbb5516b2 in g_type_fundamental () from /usr/pkg/lib/libgobject-2.0.so.0 > #1 0x08172e85 in ml_G_TYPE_FUNDAMENTAL () > #2 0x080ce208 in camlGobject__objtype_from_name_256 () > #3 0x762cb901 in ?? () > #4 0x0818aad4 in camlUigtk2__187 () > #5 0x762cb901 in ?? () > #6 0x081f8fbc in camlGtkBaseProps__150 () > #7 0x081f2640 in camlGobject__114 () > #8 0x080ce405 in camlGobject__unsafe_create_290 () > [...] > > Unison works fine in text mode. > > Poking into this problem a bit further, almost all of lablgtk's > example programs crash in the same way *except* for about.ml. The > crash traces generally look like: > > (gdb) run -I ../src -w s tree.ml > Starting program: /tmp/obj/x11/lablgtk/work/lablgtk-2.10.0/src/lablgtktop -I ../src -w s tree.ml > > Program received signal SIGSEGV, Segmentation fault. > 0xbb48c6b2 in g_type_fundamental () from /usr/pkg/lib/libgobject-2.0.so.0 > (gdb) bt > #0 0xbb48c6b2 in g_type_fundamental () from /usr/pkg/lib/libgobject-2.0.so.0 > #1 0x080a8aff in ml_G_TYPE_FUNDAMENTAL (arg1=1967197825) at ml_gobject.c:87 > #2 0x080c9a0f in caml_interprete () > #3 0x080baae5 in caml_main () > #4 0x080bace1 in main () > > I found one reference to a similar problem on a debian installation, > but there were no solutions. Does this trigger any ideas for > anybody? > > My package versions installed: > > lablgtk-2.10.0 (with default options) > ocaml-3.10.0 > gtk2+-2.12.1 > glib2-2.14.3 > > Many thanks. > > Brian. > > -- > Brian de Alwis | Software Practices Lab | UBC | http://www.cs.ubc.ca/~bsd/ > "Amusement to an observing mind is study." - Benjamin Disraeli > > ----- End forwarded message ----- > > -- > Brian de Alwis | Software Practices Lab | UBC | http://www.cs.ubc.ca/~bsd/ > "Amusement to an observing mind is study." - Benjamin Disraeli -- 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