After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 673007 - [power]: gnome-settings-daemon crashed with SIGSEGV in engine_update_composite_device()
[power]: gnome-settings-daemon crashed with SIGSEGV in engine_update_composit...
Status: RESOLVED FIXED
Product: gnome-settings-daemon
Classification: Core
Component: general
3.2.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-settings-daemon-maint
gnome-settings-daemon-maint
Depends on:
Blocks:
 
 
Reported: 2012-03-28 16:07 UTC by RedSingularity
Modified: 2012-04-10 10:49 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Dependencies (4.43 KB, text/plain)
2012-03-28 21:58 UTC, RedSingularity
  Details
Disassembly (585 bytes, text/plain)
2012-03-28 21:59 UTC, RedSingularity
  Details
ProcMaps (43.82 KB, text/plain)
2012-03-28 21:59 UTC, RedSingularity
  Details
ProcStatus (795 bytes, text/plain)
2012-03-28 22:00 UTC, RedSingularity
  Details
Registers (474 bytes, text/plain)
2012-03-28 22:00 UTC, RedSingularity
  Details
SegvAnalysis (188 bytes, text/plain)
2012-03-28 22:01 UTC, RedSingularity
  Details
Stacktrace (2.25 KB, text/plain)
2012-03-28 22:01 UTC, RedSingularity
  Details
XsessionErrors (1.45 KB, text/plain)
2012-03-28 22:02 UTC, RedSingularity
  Details
Stacktrace (23.64 KB, application/octet-stream)
2012-03-30 02:29 UTC, RedSingularity
  Details
Proposed patch (2.29 KB, patch)
2012-04-09 16:51 UTC, Michael Terry
committed Details | Review

Description RedSingularity 2012-03-28 16:07:11 UTC
Gnome-settings-daemon crashes. Happens while in a live session. Easily reproducible. Boot a live session and choose to install ubuntu. Wait a few seconds and the message will come up.

Launchpad Link: 

https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/965487
Comment 1 RedSingularity 2012-03-28 16:25:08 UTC
Stacktrace and other relevant files can be found in the launchpad report.
Comment 2 Bastien Nocera 2012-03-28 21:53:16 UTC
Please attach all relevant files here.
Comment 3 RedSingularity 2012-03-28 21:58:43 UTC
Created attachment 210815 [details]
Dependencies
Comment 4 RedSingularity 2012-03-28 21:59:25 UTC
Created attachment 210816 [details]
Disassembly
Comment 5 RedSingularity 2012-03-28 21:59:54 UTC
Created attachment 210817 [details]
ProcMaps
Comment 6 RedSingularity 2012-03-28 22:00:22 UTC
Created attachment 210818 [details]
ProcStatus
Comment 7 RedSingularity 2012-03-28 22:00:51 UTC
Created attachment 210819 [details]
Registers
Comment 8 RedSingularity 2012-03-28 22:01:14 UTC
Created attachment 210820 [details]
SegvAnalysis
Comment 9 RedSingularity 2012-03-28 22:01:34 UTC
Created attachment 210821 [details]
Stacktrace
Comment 10 RedSingularity 2012-03-28 22:02:01 UTC
Created attachment 210822 [details]
XsessionErrors
Comment 11 Bastien Nocera 2012-03-28 22:40:20 UTC
The stacktrace is missing debug information symbols. Please check http://live.gnome.org/GettingTraces to get those debuginfo symbols available.
Comment 12 RedSingularity 2012-03-29 02:11:49 UTC
I am having some trouble with the symbols.  This problem occurs within a live CD environment.  If I install the debug symbols and then reboot, they are no longer there.  I have tried the debug symbols from inside a live session anyway (no reboot), but they are not producing any more output than what was produced in the original report.  The problem does not occur from inside a fully installed system. 

Where should i go from here?
Comment 13 Bastien Nocera 2012-03-29 02:22:09 UTC
Asking your distribution? I have no idea about Ubuntu's live disks. Fedora's can have persistent storage bolted on, so one would just install the debuginfo packages on the USB key and reproduce the problem.
Comment 14 RedSingularity 2012-03-30 02:29:13 UTC
Created attachment 210911 [details]
Stacktrace

I managed to pull a better stacktrace from the crash.
Comment 15 Sebastien Bacher 2012-04-04 08:51:24 UTC
the bug is getting quite some duplicates it seems to happen mostly on liveCD, could be due to the slowness or because the installer inhibit suspend etc

the code hitting the issue is

"        /* update the composite device */
        array = manager->priv->devices_array;
->        for (i=0;i<array->len;i++) {"

so somehow "array" is invalid there and trying to access len must hit the bug
Comment 16 Sebastien Bacher 2012-04-04 08:52:53 UTC
https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/969535 seems a similar issue in engine_get_icon_priv()

"#0  engine_get_icon_priv (manager=0xdfb080, device_kind=UP_DEVICE_KIND_BATTERY, warning=WARNING_CRITICAL, use_state=0) at gsd-power-manager.c:596
        i = 0
        array = 0x0
        device = <optimized out>
        warning_temp = <optimized out>
        kind = 32545
        state = 3489716016
        is_present = 32545
  • #1 engine_get_icon
    at gsd-power-manager.c line 637
  • #2 engine_get_icon_property_variant
    at gsd-power-manager.c line 347
  • #3 invoke_get_all_properties_in_idle_cb
    at /build/buildd/glib2.0-2.32.0/./gio/gdbusconnection.c line 4354
  • #4 invoke_get_all_properties_in_idle_cb
    at /build/buildd/glib2.0-2.32.0/./gio/gdbusconnection.c line 4318

Comment 17 Michael Terry 2012-04-09 16:23:04 UTC
Here's what it looks like to me.  I haven't hit the crash myself, but I can see how we would.

The crash is happening because engine_device_changed_cb() is getting called after the manager is 'stopped' (during which, devices_array is set to NULL).  So why is it getting called?

Normally it wouldn't, since the stop() function unrefs its UpClient which would disconnect all signals if the manager held the only reference to it.

But UpClients are ref-counted singletons.  And both the 'updates' and 'xrandr' plugins also use UpClients.  So when a manager is stopped, it may not be actually finalizing its own UpClient and thus not disconnecting its signals.

So a simple fix is to add an explicit g_signal_handlers_disconnect_by_data (to all three plugins).  Patch coming.
Comment 18 Michael Terry 2012-04-09 16:51:17 UTC
Created attachment 211657 [details] [review]
Proposed patch
Comment 19 Matthias Clasen 2012-04-09 23:19:35 UTC
Review of attachment 211657 [details] [review]:

Looks right to me.
Comment 20 Richard Hughes 2012-04-10 10:48:26 UTC
Review of attachment 211657 [details] [review]:

Looks great, thanks for finding the root cause.