Bug#525031: gnome-settings-daemon: spins on cpu, possibly, while, Registering GsdXrandrPlugin

[Michael Cree]

Still present in 2.30-1.

Now that gdb has been updated I can get a backtrace:

gdb) run
Starting program: /usr/bin/gnome-settings-daemon --debug --no-daemon
[Thread debugging using libthread_db enabled]
** (gnome-settings-daemon:17983): DEBUG: Successfully connected to D-Bus

[...snip...]

** (gnome-settings-daemon:17983): DEBUG: Registering GsdXrandrPlugin

Program received signal SIGSEGV, Segmentation fault.
0x0000020001760edc in register_gnome_settings_plugin (module=0x12005a280)
     at gsd-xrandr-plugin.c:36
36	GNOME_SETTINGS_PLUGIN_REGISTER (GsdXrandrPlugin, gsd_xrandr_plugin)

(gdb) bt
#0  0x0000020001760edc in register_gnome_settings_plugin 
(module=0x12005a280)
     at gsd-xrandr-plugin.c:36
#1  0x0000000120009ef4 in gnome_settings_module_load (gmodule=0x12005a280)
     at gnome-settings-module.c:78
#2  0x0000020000704af0 in g_type_module_use ()
    from /usr/lib/libgobject-2.0.so.0
#3  0x0000000120008bd8 in load_plugin_module (info=0x1200614e0)
     at gnome-settings-plugin-info.c:431
#4  0x0000000120008f48 in _activate_plugin (info=0x1200614e0)
     at gnome-settings-plugin-info.c:493
#5  0x00000001200090f0 in gnome_settings_plugin_info_activate (
     info=0x1200614e0) at gnome-settings-plugin-info.c:520
#6  0x0000000120005c10 in maybe_activate_plugin (info=0x1200614e0,
     user_data=0x0) at gnome-settings-manager.c:94
#7  0x00000200007c0ea4 in g_slist_foreach () from /lib/libglib-2.0.so.0
#8  0x0000000120006494 in _load_all (manager=0x12005b000)
     at gnome-settings-manager.c:263
#9  0x0000000120006850 in gnome_settings_manager_start 
(manager=0x12005b000,
     error=0x11f901468) at gnome-settings-manager.c:349
#10 0x0000000120005558 in main (argc=1, argv=0x11f901598) at main.c:487


Taking a close look, i.e., disassembling, the local scope:
gdb) disass /m
Dump of assembler code for function register_gnome_settings_plugin:
36	GNOME_SETTINGS_PLUGIN_REGISTER (GsdXrandrPlugin, gsd_xrandr_plugin)
    0x0000020001760e54 <+0>:	ldah	gp,2(t12)
    0x0000020001760e58 <+4>:	lda	gp,7556(gp)
    0x0000020001760e5c <+8>:	lda	sp,-32(sp)
    0x0000020001760e60 <+12>:	stq	ra,0(sp)
    0x0000020001760e64 <+16>:	stq	fp,8(sp)
    0x0000020001760e68 <+20>:	mov	sp,fp
    0x0000020001760e6c <+24>:	stq	a0,16(fp)
    0x0000020001760e70 <+28>:	clr	a0
    0x0000020001760e74 <+32>:	lda	a1,128
    0x0000020001760e78 <+36>:	ldah	t0,-2(gp)
    0x0000020001760e7c <+40>:	lda	a2,21672(t0)
    0x0000020001760e80 <+44>:	ldq	t12,-31368(gp)
    0x0000020001760e84 <+48>:	jsr	ra,(t12),0x20001760e88 
<register_gnome_settings_plugin+52>
    0x0000020001760e88 <+52>:	ldah	gp,2(ra)
    0x0000020001760e8c <+56>:	lda	gp,7504(gp)
    0x0000020001760e90 <+60>:	ldah	t0,-2(gp)
    0x0000020001760e94 <+64>:	lda	a0,21700(t0)
    0x0000020001760e98 <+68>:	ldah	t0,-2(gp)
    0x0000020001760e9c <+72>:	lda	a1,21722(t0)
    0x0000020001760ea0 <+76>:	ldq	t12,-32336(gp)
    0x0000020001760ea4 <+80>:	jsr	ra,(t12),0x20001760ea8 
<register_gnome_settings_plugin+84>
    0x0000020001760ea8 <+84>:	ldah	gp,2(ra)
    0x0000020001760eac <+88>:	lda	gp,7472(gp)
    0x0000020001760eb0 <+92>:	ldah	t0,-2(gp)
    0x0000020001760eb4 <+96>:	lda	a0,21700(t0)
    0x0000020001760eb8 <+100>:	ldah	t0,-2(gp)
    0x0000020001760ebc <+104>:	lda	a1,21740(t0)
    0x0000020001760ec0 <+108>:	ldq	t12,-31472(gp)
    0x0000020001760ec4 <+112>:	jsr	ra,(t12),0x20001760ec8 
<register_gnome_settings_plugin+116>
    0x0000020001760ec8 <+116>:	ldah	gp,2(ra)
    0x0000020001760ecc <+120>:	lda	gp,7440(gp)
    0x0000020001760ed0 <+124>:	ldah	t0,0(gp)
    0x0000020001760ed4 <+128>:	ldq	t1,16(fp)
    0x0000020001760ed8 <+132>:	stq	t1,-31272(t0)
=> 0x0000020001760edc <+136>:	ldq	t12,0(gp)
    0x0000020001760ee0 <+140>:	jsr	ra,(t12),0x20001760ee4 
<register_gnome_settings_plugin+144>

This code is in the xrandr plugin.  We can see the segmentation 
violation occurs at the instruction ldq t12,0(gp).   This instruction is 
loading cpu register t12 with an entry from the data area (presumably 
the global offset table) pointed to by the global pointer (gp).  The 
next instruction (if it were executed) calls the subroutine pointed to 
by cpu register t12 and should be gnome_settings_plugin_get_type(), 
i.e., a call back into the main program.

Looking at the other jsr instructions register t12 is always loaded with 
an offset (typically about -31000) from the gp and I have verified that 
they are entries into an offset table with the addresses of the 
subroutine being called.  But for the offending instruction the offset 
is 0 from the gp.  I suspect that, somehow, the dynamic linker has not 
resolved this symbol properly in the code of the plugin, i.e., that the 
0 offset to the gp is incorrect.

I wonder if a similar thing is occurring on the ia64 architecture for 
which this bug was first reported.

I personally don't know enough about the glib/gnome plugin mechanisms to 
debug this much further without guidance.

Regards
Michael.