==17386== 1,669 (88 direct, 1,581 indirect) bytes in 1 blocks are definitely lost in loss record 4,090 of 4,151
==17386== at 0x4C24AF4: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==17386== by 0x691B099: g_malloc0 (in /usr/lib/libglib-2.0.so.0.2800.8)
==17386== by 0x692006A: g_option_context_new (in /usr/lib/libglib-2.0.so.0.2800.8)
==17386== by 0x5124C57: meta_get_option_context (in /usr/lib/libmutter.so.0.0.0)
==17386== by 0x401D4F: main (in /usr/bin/gnome-shell)
https://bugzilla.gnome.org/show_bug.cgi?id=654269
A new envrionment variable GNOME_SHELL_ENABLE_CLEANUP is added which
causes us to attempt freeing global data. The reason this isn't
enabled by default is that it's a waste of time at best, and at
worst in corner cases could cause crashes which would fill up
crash databases. Better to leave it as a developer-only tool.
Start stubbing out some cleanup in ShellGlobal.
https://bugzilla.gnome.org/show_bug.cgi?id=649517
We weren't specifying _ALLOW_REPLACEMENT for anything except
org.gnome.Shell, which created a race - if the exiting process
didn't exit fast enough, the replacing process would fail
to get the name.
https://bugzilla.gnome.org/show_bug.cgi?id=646257
Previously (because I suck) we were ignoring the return value of
RequestName, and so we'd totally ignore the fact that we failed
to acquire the DBus name.
Make this consistent by using meta_get_replace_current_wm() and
if we're in --replace, actually replace immediately.
https://bugzilla.gnome.org/show_bug.cgi?id=645593
Build gnome-shell as a binary linked against libmutter-wm, instead of
a module to be loaded by libmutter-wm. Move the majority of
initialization-type stuff from gnome_shell_plugin_start() into main().
We still build libgnome-shell as a shared library, so that the linker
doesn't discard all the methods that are never called from C.
https://bugzilla.gnome.org/show_bug.cgi?id=641724