deja-dup-monitor crashed with SIGSEGV in g_hash_table_lookup_node()

[Kurt Semler]

On system launch.

ProblemType: Crash
DistroRelease: Ubuntu 17.10
Package: deja-dup 36.2-0ubuntu1
ProcVersionSignature: Ubuntu 4.13.0-15.16-generic 4.13.4
Uname: Linux 4.13.0-15-generic x86_64
ApportVersion: 2.20.7-0ubuntu2
Architecture: amd64
CurrentDesktop: X-Cinnamon
Date: Fri Oct 6 03:01:31 2017
ExecutablePath: /usr/lib/x86_64-linux-gnu/deja-dup/deja-dup-monitor
InstallationDate: Installed on 2017-09-27 (8 days ago)
InstallationMedia: Ubuntu-MATE 17.04 "Zesty Zapus" - Release amd64 (20170412)
ProcCmdline: /usr/lib/x86_64-linux-gnu/deja-dup/deja-dup-monitor
ProcEnviron:
 LANGUAGE=en_US
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
Signal: 11
SourcePackage: deja-dup
StacktraceTop:
 ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
 ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
 g_source_attach () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
 ?? () from /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
 g_dbus_connection_send_message_with_reply () from /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
Title: deja-dup-monitor crashed with SIGSEGV in g_source_attach()
UpgradeStatus: Upgraded to artful on 2017-09-27 (8 days ago)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo

[Apport retracing service (apport)]

StacktraceTop:
 g_hash_table_lookup_node (hash_return=<synthetic pointer>, key=0xc5e7, hash_table=0x55d5485a5060) at ../../../../glib/ghash.c:408
 g_hash_table_insert_internal (hash_table=0x55d5485a5060, key=0xc5e7, value=0x7f8fd4837030, keep_new_key=0) at ../../../../glib/ghash.c:1233
 g_source_attach_unlocked (source=source@entry=0x7f8fd4837030, context=context@entry=0x55d5485a00c0, do_wakeup=do_wakeup@entry=1) at ../../../../glib/gmain.c:1159
 g_source_attach (source=0x7f8fd4837030, context=0x55d5485a00c0) at ../../../../glib/gmain.c:1217
 g_task_attach_source (task=task@entry=0x7f8fd43c2d50, source=<optimized out>, callback=callback@entry=0x7f8ff6b88410 <send_message_with_reply_timeout_cb>) at ../../../../gio/gtask.c:1534

[Michael Terry (mterry)]

From the retraced Stacktrace.txt, it looks like a client dconf thread is sending a message to the session DBus daemon which ends up trying to use a bogus GTask structure.

So I'm guessing we are either trashing dconf's memory or this is a dconf-internal bug? Assigning to dconf to see if this looks familiar to them. Please assign back if you all don't think it's yours.

[Launchpad Janitor (janitor)]

[Expired for dconf (Ubuntu) because there has been no activity for 60 days.]