Re: gtk+ on linux/ia64

[Tim Janik <timj gtk org>]

On Thu, 3 Jan 2002, George wrote:

> > > - How do I go about debugging this ? The backtrace does not give me
> > >   any clues to me:
> > > #0  g_type_check_is_value_type (type=6917529027641348864) at gtype.c:263
> > > #1  0x200000000098f3f0 in g_signal_newv (signal_name=0x0, 
> > >     itype=6917529027641364432,  signal_flags=G_SIGNAL_RUN_FIRST, 
> > >     class_closure=0x6000000000047ee0, accumulator=0, accu_data=0x0, 
> > >     c_marshaller=0x2000000000e54af0, return_type=4, n_params=1, 
> > >     param_types=0x6000000000047f30) at gsignal.c:1196
> > > #2  0x2000000000990040 in g_signal_new_valist 
> > >     (signal_name=0x20000000005d1038 "size_request", 
> > >      itype=6917529027641364432, signal_flags=G_SIGNAL_RUN_FIRST,  
> > >      class_closure=0x6000000000047ee0, accumulator=0, 
> > >      accu_data=0x0, c_marshaller=0x2000000000e54af0, return_type=4, 
> > >      n_params=1, args=0x80000fffffffb0b0) at gsignal.c:1322
> > 
> > 64 bit issues are really common when using varargs functions like
> > g_signal_new(). Look at the call and see if you are getting a
> > different number of bits going in than coming out.
> > 
> > Here is the call in question:
> > 
> >   widget_signals[SIZE_REQUEST] =
> >     g_signal_new ("size_request",
> >                    G_OBJECT_CLASS_TYPE (object_class),
> >                    G_SIGNAL_RUN_FIRST,
> >                    G_STRUCT_OFFSET (GtkWidgetClass, size_request),
> >                    NULL, NULL,
> >                    _gtk_marshal_VOID__BOXED,
> >                    GTK_TYPE_NONE, 1,
> >                    GTK_TYPE_REQUISITION | G_SIGNAL_TYPE_STATIC_SCOPE);
> > 
> > So I wonder if "GTK_TYPE_REQUISITION | G_SIGNAL_TYPE_STATIC_SCOPE"
> > ends up with type "int" instead of "GType" as intended, though if so
> > I'm surprised no one has noticed before now.
> 
> My alpha is not on right now, but GTK_TYPE_REQUISITION seems to be of type
> GType.  Perhaps the compiler trims the whole thing because
> G_SIGNAL_TYPE_STATIC_SCOPE is an int?  Or perhaps the or doesn't work as
> expected.  Perhaps try casting both to (gsize) before oring them together and
> see if that helps.  If not, the problem must be elsewhere.  I'll test how
> this is coming out on the alpha after dinner.

according to standard promotion rules, G_SIGNAL_TYPE_STATIC_SCOPE should be
implicitely converted to gsize before the ORing, it'd be a compiler bug if
that didn't happen.
also note:

#define G_SIGNAL_TYPE_STATIC_SCOPE (G_TYPE_FLAG_RESERVED_ID_BIT)
#define G_TYPE_FLAG_RESERVED_ID_BIT     (1 << 0)
and in frame #0:
 6917529027641348864 is still a 64bit pointer
 6917529027641348864 & 1 == 0

however, GTK_TYPE_NONE==4, itype==6917529027641364432, so it has to be
GTK_TYPE_REQUISITION | G_SIGNAL_TYPE_STATIC_SCOPE.

if i am to make a guess, this is from:
    if (!G_TYPE_IS_VALUE (param_types[i] & ~G_SIGNAL_TYPE_STATIC_SCOPE))
which probably does something like (promotion spelled out):
  ((gint64) param_types[i]) | ((gint64) ((guint32) ~ ((guint32) G_SIGNAL_TYPE_STATIC_SCOPE)))

so chances are that changing gtype.h:

-#define G_TYPE_FLAG_RESERVED_ID_BIT     (1 << 0)
+#define G_TYPE_FLAG_RESERVED_ID_BIT     ((GType) (1 << 0))

will fix this.

Karl, can you check that? (you need to recompile pango, atk and gtk after that
change).

> 
> George
> 

---
ciaoTJ