Comment 0 for bug 1005642

/var/lib/lightdm/.cache/unity-greeter/state records the last username to be selected. In 0.2.8-0ubuntu1.1 a lot of binary garbage gets written as well (typically over 500KB).

The most visible consequence of this is a very slow response to switching users, eg using the arrow keys, on some systems. This may be what is being seen in several other bug reports (eg bug #945450), although it's hard to be sure.

The slowness seems to be due to the time taken to write all the garbage, and maybe the generation of a segmentation error at the end of it. Enabling lightdm logging with --log-dir=/var/log/lightdm on the exec line in /etc/init/lightdm.conf, I see the following:

unity-greeter.vala:496: Failed to write state: Error writing to file: Bad address

Judging by the timestamp, this seems to occur right at the time of the slowdown, and from the contents of the file the garbage seems to be a dump of memory contents following the correct data, maybe all the way to the end of the data segment.

There's also a log message at the startup about being unable to read the state, presumably due to the corruption. Unfortunately, deleting the state file just causes another garbage one to be created.

The relevant section of unity-greeter.vala is:

    state.set_value ("greeter", "last-user", username);
    var data = state.to_data ();
    try
    {
        state_file.replace_contents ((uint8[])data, null, false, FileCreateFlags.NONE, null);
    }
    catch (Error e)
    {
        debug ("Failed to write state: %s", e.message);
    }

so either state.to_data is returning garbage or state_file.replace_contents is writing out too much data.

If I build a local version of unity-greeter with the call to replace-contents removed, the log message goes away and, most importantly, so does the slowdown.

Unfortunately, I haven't been able to produce a full fix for the problem. I'm wondering if the real issue is to do with the passing of data between vala and glib.