GNOME Bugzilla – Bug 672245
[power]: gnome-settings-daemon crashed with SIGSEGV in gnome_rr_screen_get_dpms_mode()
Last modified: 2012-12-05 13:16:49 UTC
Hello It crash on a fresh dreated usb live session, no actions performed. Thanks fabio ProblemType: CrashDistroRelease: Ubuntu 12.04 Package: gnome-settings-daemon 3.3.91-0ubuntu5 ProcVersionSignature: Ubuntu 3.2.0-18.29-generic 3.2.9 Uname: Linux 3.2.0-18-generic x86_64 ApportVersion: 1.94.1-0ubuntu2 Architecture: amd64 CasperVersion: 1.311 Date: Fri Mar 16 10:08:27 2012 ExecutablePath: /usr/lib/gnome-settings-daemon/gnome-settings-daemon ExecutableTimestamp: 1331836366LiveMediaBuild: Ubuntu 12.04 LTS "Precise Pangolin" - Alpha amd64 (20120316) ProcCmdline: /usr/lib/gnome-settings-daemon/gnome-settings-daemon ProcCwd: / ProcEnviron: LANGUAGE= TERM=linux PATH=(custom, no user) LANG= SegvAnalysis: Segfault happened at: 0x7f27b83aed89 <gnome_rr_screen_get_dpms_mode+73>: mov 0x18(%rdi),%rax PC (0x7f27b83aed89) ok source "0x18(%rdi)" (0x00000018) not located in a known VMA region (needed readable region)! destination "%rax" ok SegvReason: reading NULL VMA Signal: 11SourcePackage: gnome-settings-daemon StacktraceTop: gnome_rr_screen_get_dpms_mode () from /usr/lib/libgnome-desktop-3.so.2 gnome_rr_screen_set_dpms_mode () from /usr/lib/libgnome-desktop-3.so.2 ?? () from /usr/lib/gnome-settings-daemon-3.0/libpower.so ?? () from /usr/lib/gnome-settings-daemon-3.0/libpower.so ?? () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 Title: [power]: gnome-settings-daemon crashed with SIGSEGV in gnome_rr_screen_get_dpms_mode() UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
StacktraceTop: gnome_rr_screen_get_dpms_mode (screen=0x0, mode=0x7fff0036541c, error=0x7fff00365468) at gnome-rr.c:1157 gnome_rr_screen_set_dpms_mode (screen=0x0, mode=GNOME_RR_DPMS_ON, error=0x7fff00365468) at gnome-rr.c:1241 idle_set_mode (manager=0x1f01050, mode=<optimized out>) at gsd-power-manager.c:3021 idle_evaluate (manager=0x1f01050) at gsd-power-manager.c:3190 _g_closure_invoke_va (closure=0x1ff7720, return_value=0x0, instance=0x1f4fb80, args=0x7fff00365788, n_params=0, param_types=<optimized out>) at /build/buildd/glib2.0-2.31.20/./gobject/gclosure.c:840
others logfiles in the attached Launchpad url
launchpad bug: https://bugs.launchpad.net/bugs/956824 the full stacktrace: https://launchpadlibrarian.net/96988022/Stacktrace.txt
Created attachment 210421 [details] [review] test patch Does this patch fix things? Really, the problem is that the call to gnome_rr_screen_new() fails, but we certainly shouldn't crash GSD if that's the case.
do you have any idea why that call would fail? it seems to happen mostly on slow session, i.e liveCD or armel tester
No, not really, sorry. It's one of those "shouldn't really happen" type bugs.
the patch doesn't fix the issue, https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/971353 is from the version with it applied in ubuntu "https://launchpadlibrarian.net/99619420/Stacktrace.txt
+ Trace 230007
Comment on attachment 210421 [details] [review] test patch Patch doesn't work, as per comment 7.
I think we need to work out why gnome_rr_screen_new() is returning NULL. I'll re-assign to libgnome-desktop for further help.
Didn't we have a crasher in the DPMS code a few months ago? I think it got fixed. No idea if this is the same bug. (The date of the original bug report makes sense with my memory of the crashes, anyway...)
Created attachment 223710 [details] [review] Proposed patch I believe there were two ways to get the same crash. 1) In between a start()/stop() pairing, if gnome_rr_screen_new() somehow returned NULL and we early-exited from start() after connecting signals. This was fixed by the previous patch in this bug. 2) After a stop() call, if we weren't the only holders of a reference to the idletime alarm. idletime is a singleton that hands out references to ourselves. But stop() treated it like a normal object it owned, and assumed that unref'ing it would disconnect its signals. But it doesn't, so we have to manually do that. This patch includes both fixes.
Review of attachment 223710 [details] [review]: The great explanations in the bugzilla would be real nice in the commit message :) Could you please also split up the 2 fixes?
Created attachment 230719 [details] [review] Richard's patch Sorry, this dropped off my radar. I'm attaching a better-documented version of Richard's patch (attributing it to him). As for my value-add of fix #2, trunk has worked around it already. It now uses GnomeIdleMonitor which does not have the singleton semantics that confused the power plugin in the first place. So we can just forget about that fix. So this patch is the only one that needs to be applied.