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.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
