GTK+

gtk+3.0 FTBFS on ppc64el

Bug #1262380 reported by Steve Langasek on 2013-12-18

This bug affects 1 person

Affects		Status	Importance	Assigned to	Milestone
	GTK+	Fix Released	Medium	gnome-bugs #721700
	gtk+3.0 (Ubuntu)	Fix Released	Undecided	Unassigned

Bug Description

gtk+3.0 fails to build on ppc64el with a test suite failure in the gtkbuilder tests:

$ cd gtk+3.0-3.10.6/debian/build/shared/testsuite/gtk
$ Xvfb -ac -noreset -screen 0 1024x768x16 :0 -nolisten tcp -auth &
$ export DISPLAY=:0.0
$ ./builder
/Builder/Parser: OK
/Builder/Types: OK
/Builder/Construct-Only Properties: OK
/Builder/Children: OK
/Builder/Child Properties: OK
/Builder/Object Properties: OK
/Builder/Notebook: OK
/Builder/Domain: OK
/Builder/Signal Autoconnect: Segmentation fault
$

gdb shows some kind of corrupted backtrace (the calling function is test_connect_signals(), not test_gmenu()):

(gdb) bt
#0 0x00003fffb7deeab8 in gtk_window_get_type ()
    at /home/buildd/stage1/gtk+3.0-3.10.6/./gtk/gtkwindow.c:552
#1 0x000000001000c8dc in signal_normal (window=<optimized out>, spec=...)
    at /home/buildd/stage1/gtk+3.0-3.10.6/./testsuite/gtk/builder.c:145
#2 0x00003fffb76c79b0 in g_cclosure_marshal_VOID__PARAM ()
   from /usr/lib/powerpc64le-linux-gnu/libgobject-2.0.so.0
#3 0x000000001000c8a0 in test_gmenu ()
    at /home/buildd/stage1/gtk+3.0-3.10.6/./testsuite/gtk/builder.c:2605
#4 0x626f3c20203e6563 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb)

A clean backtrace immediately before the segfault looks like:

#0 signal_normal (window=<optimized out>, spec=...)
    at /home/buildd/stage1/gtk+3.0-3.10.6/./testsuite/gtk/builder.c:144
#1 0x00003fffb76c7b30 in g_cclosure_marshal_VOID__PARAM (closure=0x100997a0,
    return_value=<optimized out>, n_param_values=<optimized out>,
    param_values=0x3fffffffe630, invocation_hint=<optimized out>,
    marshal_data=0x0) at /build/buildd/glib2.0-2.39.2/./gobject/gmarshal.c:1042
#2 0x00003fffb76c3678 in g_closure_invoke (closure=0x100997a0,
    return_value=0x0, n_param_values=<optimized out>,
    param_values=0x3fffffffe630, invocation_hint=0x3fffffffe528)
    at /build/buildd/glib2.0-2.39.2/./gobject/gclosure.c:777
#3 0x00003fffb76dec78 in signal_emit_unlocked_R (node=0x1004ca20, detail=457,
    instance=0x10200ff0, emission_return=0x0,
    instance_and_params=0x3fffffffe630)
    at /build/buildd/glib2.0-2.39.2/./gobject/gsignal.c:3556
#4 0x00003fffb76e7fc4 in g_signal_emit_valist (instance=0x10200ff0,
    signal_id=<optimized out>, detail=<optimized out>,
    var_args=0x3fffffffe800 "\003")
    at /build/buildd/glib2.0-2.39.2/./gobject/gsignal.c:3312
#5 0x00003fffb76e8240 in g_signal_emit (instance=<optimized out>,
    signal_id=<optimized out>, detail=<optimized out>)
    at /build/buildd/glib2.0-2.39.2/./gobject/gsignal.c:3368
#6 0x00003fffb76c9e2c in g_object_dispatch_properties_changed (
    object=0x10200ff0, n_pspecs=<optimized out>, pspecs=<optimized out>)
    at /build/buildd/glib2.0-2.39.2/./gobject/gobject.c:1046
#7 0x00003fffb76cd864 in g_object_notify_by_spec_internal (
    pspec=<optimized out>, object=0x10200ff0)
    at /build/buildd/glib2.0-2.39.2/./gobject/gobject.c:1140
#8 g_object_notify (object=0x10200ff0, property_name=<optimized out>)
    at /build/buildd/glib2.0-2.39.2/./gobject/gobject.c:1187
#9 0x00003fffb7df00d4 in gtk_window_set_title_internal (window=0x10200ff0,
    title=<optimized out>, update_titlebar=<optimized out>)
    at /home/buildd/stage1/gtk+3.0-3.10.6/./gtk/gtkwindow.c:1807
#10 0x00000000100080a8 in test_connect_signals ()
    at /home/buildd/stage1/gtk+3.0-3.10.6/./testsuite/gtk/builder.c:260
#11 0x00003fffb7617ce8 in test_case_run (tc=0x10053a70)
    at /build/buildd/glib2.0-2.39.2/./glib/gtestutils.c:2088
#12 g_test_run_suite_internal (suite=0x10048ae0, path=0x3fffb769aa68 "")
    at /build/buildd/glib2.0-2.39.2/./glib/gtestutils.c:2148
#13 0x00003fffb7617f08 in g_test_run_suite_internal (suite=0x10048ac0,
    path=0x3fffb769aa68 "")
    at /build/buildd/glib2.0-2.39.2/./glib/gtestutils.c:2159
#14 0x00003fffb761840c in g_test_run_suite (suite=0x10048ac0)
    at /build/buildd/glib2.0-2.39.2/./glib/gtestutils.c:2210
#15 0x00003fffb7618480 in g_test_run ()
    at /build/buildd/glib2.0-2.39.2/./glib/gtestutils.c:1526
#16 0x0000000010003ed4 in main (argc=1, argv=0x3ffffffff638)
    at /home/buildd/stage1/gtk+3.0-3.10.6/./testsuite/gtk/builder.c:2781
(gdb)

Stepping through with gdb also shows signal_normal() being entered twice in response to the first gtk_window_set_title() call, even though it should only be called once.

This problem was not evident in the initial bootstrap of gtk+3.0, but now is reproducible on both the launchpad builders and the porter system. It could be due to a kernel upgrade after the initial bootstrap, we're not sure.

Tags:

Related branches

lp://staging/~ubuntu-desktop/gtk/ubuntugtk3

Steve Langasek (vorlon) on 2013-12-18

tags:	added: ftbfs
tags:	added: ppc64el

Revision history for this message

Anton Blanchard (anton-samba) wrote on 2013-12-23:

This looks like an issue with passing structs by value. g_cclosure_marshal_VOID__PARAM is only allocating a 64 byte stack frame and is calling signal_normal via some marshalling tricks. The prototype for signal_normal includes a large struct which will be partially passed in registers and signal_normal expects to be able to write that out to the parameter save area in the callers frame.

signal_normal does end up writing out parameters to the caller stack:

Dump of assembler code for function signal_normal:
   0x000000001000c880 <+0>: lis r2,4099
   0x000000001000c884 <+4>: addi r2,r2,-4080
   0x000000001000c888 <+8>: mflr r0
   0x000000001000c88c <+12>: std r31,-8(r1)
   0x000000001000c890 <+16>: mr r31,r3
   0x000000001000c894 <+20>: std r0,16(r1)
   0x000000001000c898 <+24>: stdu r1,-48(r1)
   0x000000001000c89c <+28>: std r4,88(r1)
   0x000000001000c8a0 <+32>: std r5,96(r1)
   0x000000001000c8a4 <+36>: std r6,104(r1)
   0x000000001000c8a8 <+40>: std r7,112(r1)
   0x000000001000c8ac <+44>: std r8,120(r1)
   0x000000001000c8b0 <+48>: std r9,128(r1)
   0x000000001000c8b4 <+52>: std r10,136(r1)

And since g_cclosure_marshal_VOID__PARAM hasn't allocated enough stack we stomp all over the stack and die.

What is interesting is that signal_normal doesn't touch the struct, so why are we bothering to save it? It looks like a missing optimisation in gcc and this test case shows it:

struct foo
{
void *a, *b, *c, *d, *e, *f, *g, *h;
#if 1
void *i;
#endif
};

int bar(struct foo foo)
{
return 0;
}

With a struct big enough to not fit into registers, we always save the whole struct out to the stack even if we never touch it:

bar:
        std 3,32(1)
        std 4,40(1)
        li 3,0
        std 5,48(1)
        std 6,56(1)
        std 7,64(1)
        std 8,72(1)
        std 9,80(1)
        std 10,88(1)
        blr

Revision history for this message

Alan Modra (amodra) wrote on 2013-12-26:

I'm fairly certain this is a bug in the test itself.

If you take a look at glib2.0/gobject/gmarshal.c g_cclosure_marshal_VOID__PARAM, you see
  typedef void (*GMarshalFunc_VOID__PARAM) (gpointer data1,
                                            gpointer arg_1,
                                            gpointer data2);

That says to me that all of the signal functions in gtk/tests/builder.c should be declared as
signal_normal (GtkWindow *window, GParamSpec *spec)
not
signal_normal (GtkWindow *window, GParamSpec spec)

The "spec" parameter corresponds to "arg_1" in the typedef, which is a pointer.

Revision history for this message

Steve Langasek (vorlon) wrote on 2013-12-27: Re: [Bug 1262380] Re: gtk+3.0 FTBFS on ppc64el

On Thu, Dec 26, 2013 at 08:15:29AM -0000, Alan Modra wrote:
> I'm fairly certain this is a bug in the test itself.

> If you take a look at glib2.0/gobject/gmarshal.c g_cclosure_marshal_VOID__PARAM, you see
> typedef void (*GMarshalFunc_VOID__PARAM) (gpointer data1,
> gpointer arg_1,
> gpointer data2);

> That says to me that all of the signal functions in gtk/tests/builder.c should be declared as
> signal_normal (GtkWindow *window, GParamSpec *spec)
> not
> signal_normal (GtkWindow *window, GParamSpec spec)

> The "spec" parameter corresponds to "arg_1" in the typedef, which is a
> pointer.

Thanks Alan, confirmed here that fixing the prototypes of the signal
functions resolves the testsuite failure. I'm uploading gtk+3.0 to Ubuntu
now with this patch.

Revision history for this message

Launchpad Janitor (janitor) wrote on 2013-12-27:

This bug was fixed in the package gtk+3.0 - 3.10.6-0ubuntu3

---------------
gtk+3.0 (3.10.6-0ubuntu3) trusty; urgency=medium

  * Fix clean target to not fail when it's already been run (rm *-f*,
    people)
  * debian/patches/testsuite-ppc64el-failure.patch: fix prototypes of
    signal callbacks in the test suite. Closes LP: #1262380.
-- Steve Langasek <email address hidden> Thu, 26 Dec 2013 18:33:37 -0800

Changed in gtk+3.0 (Ubuntu):
status:	New → Fix Released

Revision history for this message

Sebastien Bacher (seb128) wrote on 2014-01-06:

Thanks for the fix Steve, did you upstream that fix (in which case do you have the bug url?) or do you want somebody from desktop to do it?

Revision history for this message

Steve Langasek (vorlon) wrote on 2014-01-06:

On Mon, Jan 06, 2014 at 01:54:53PM -0000, Sebastien Bacher wrote:
> Thanks for the fix Steve, did you upstream that fix (in which case do
> you have the bug url?) or do you want somebody from desktop to do it?

Have not yet forwarded it upstream. If you guys could take care of this,
that would be awesome - otherwise, let me know and I'll follow it up this
week/next week.

Revision history for this message

Sebastien Bacher (seb128) wrote on 2014-01-07:

Sent to https://bugzilla.gnome.org/show_bug.cgi?id=721700

Bug Watch Updater (bug-watch-updater) on 2014-01-07