Delivered-To: lablgtk at yquem.inria.fr
Date: Tue, 27 Nov 2007 14:11:40 +0900 (JST)
Message-Id: <20071127.141140.182616637.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 <garrigue at math.nagoya-u.ac.jp>
In-Reply-To: <20071127025136.GA6909 at monolith.gateway.2wire.net>
References: <20071126204522.GA8290 at monolith.gateway.2wire.net>
	<20071127025136.GA6909@monolith.gateway.2wire.net>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Cc: lablgtk at yquem.inria.fr
Content-Type: Text/Plain; charset=us-ascii
Content-Length: 3011

From: Brian de Alwis <bsd at cs.ubc.ca>

> Thanks for your reply Jacques.  I was running the examples using
> lablgtktop, but didn't show that -- sorry.

And I was not clear enough myself: lablgtktop does _not_ initialize
Gtk. Your test case would fail on any machine running lablgtk, albeit
giving some warning, so it is not really satisfactory as
demonstration.


>     $ 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 ();;

> [...]

> 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.

This may, or may not be the real problem. It may also just be that Gtk
being not initialized, some data structures are just plain wrong.
But indeed this would explain why unison fails.
 
> 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?

Indeed, this problem of mismatch between GType and its current
representation has already been mentionned. 
If this is the cause of your problem, then the following change in
ml_gobject.h should solve it:

#define GType_val(t) ((GType)t)
#define Val_GType(t) ((value)t)

(I.e., do nothing, as GType's are guaranteed to to be 4-byte aligned,
even for fundamental types, cf. G_TYPE_MAKE_FUNDAMENTAL)

If this is required to solve your problem, please tell me, and we may
decide to switch to this approach. This was left unchanged until now
because nobody reported any problem...

Cheers,

Jacques

_______________________________________________
Lablgtk mailing list
Lablgtk@yquem.inria.fr
http://yquem.inria.fr/cgi-bin/mailman/listinfo/lablgtk