Delivered-To: lablgtk at yquem.inria.fr
Date: Tue, 27 Nov 2007 16:55:20 -0600
From: Brian de Alwis <bsd at cs.ubc.ca>
To: Jacques Garrigue <garrigue at math.nagoya-u.ac.jp>
Subject: Re: [Lablgtk] Re: SIGSEGV with lablgtk for GTK+ 2
Message-ID: <20071127225520.GA27623 at monolith.usask.ca>
References: <20071126204522.GA8290 at monolith.gateway.2wire.net>
	<20071127025136.GA6909@monolith.gateway.2wire.net>
	<20071127.141140.182616637.garrigue@math.nagoya-u.ac.jp>
	<20071127172200.GC3857@monolith.usask.ca>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20071127172200.GC3857 at monolith.usask.ca>
Cc: lablgtk at yquem.inria.fr
Content-Type: text/plain; charset=us-ascii
Content-Length: 2074

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