unity-settings-daemon crashes on start with SIGABRT if xrandr provides two displays with the same name

Bug #1575867 reported by Rafał Cieślak on 2016-04-27
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
unity-settings-daemon (Ubuntu)
High
Unassigned

Bug Description

-- Symptoms --

I am experiencing this bug after a recent upgrade to Ubuntu 16.04, with unity-settings-daemon 15.04.1+16.04.20160209.

unity-settings-daemon always fails to start (leaving me with a quasi-functional desktop); when run from a command-line, it simply outputs:

    **
    ERROR:gsd-rr-config.c:661:gsd_rr_config_load_current: assertion failed: (gsd_rr_config_match (config, config))
    Aborted

and crashes with SIGABRT. This is 100% reproducible on my system.

I have investigated the cause of this crash, and I can provide a patch that solves this bug. I do not know whether I shall help fixing this bug here, or if should I work with the upstream directly, a word of advice in this matter would be very appreciated.

-- Bug analysis and proposed solution --

The mentioned assertion fails even though it compares the same configuration with itself. What gsd_rr_config_match does internally is that it takes each output from a configuration one by one, and searches - by name - for a matching output in the other config. If the search fails, or the found output does not match the one from first config, the gsd_rr_config_match check fails.

Because of that, this check should never fail when comparing a configuration to itself, with the exception of one (presumably rare) care. It happens that, for my multi-monitor setup, libxrandr reports that there are two different outputs that share the same name "DP-1". In this case, the gsd_rr_config_match fails, because when searching for a matching output named "DP-1", it will return the same output both times, and therefore one pair will be not matching (the find_output function returns the first output that matches requested name).

Therefore it appears that comparing configurations by checking whether outputs with matching names are equivalent may be wrong, because the output names are not guaranteed to be unique. I propose to modify both configuration comparing procedures (gsd_rr_config_match and gsd_rr_config_equal) so that they compare outputs matching them by their ids, which will always be unique due to their nature. Since the find_output function (which takes an output name as an argument) is only used by these two comparing functions, it makes sense to modify it so that it takes an output id as an argument instead.

This is a valid solution, because in this case even if output names happen to repeat, the output ids will be used to distinguish between them, and gsd_rr_config_match will no longer incorrectly fail. Also, the proposed change will never cause a configuration comparing function to return true where it would otherwise not, because each two outputs with a different name will always have a different id as well.

I attach to this bug report a patch that implements the proposed changes. Applying this patch entirely fixed the described symptoms on my machine.

Related branches

The attachment "A patch that implements the proposed fix." seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

tags: added: patch
Sebastien Bacher (seb128) wrote :

Thanks for your bug report and patch

Changed in unity-settings-daemon (Ubuntu):
importance: Undecided → High
status: New → Confirmed
Erich E. Hoover (ehoover) wrote :

I am trying to apply this fix for someone and, after some fighting getting everything setup, I was able to get everything installed to /usr/local and manually run the custom version. However, it appears that I still cannot use the Displays panel of unity-control-center to actually configure the orientation of their monitors. Is there something else that needs to be done for this application to work correctly?

Erich E. Hoover (ehoover) wrote :

Nevermind, this ended up being that I needed to set the LD_LIBRARY_PATH to /usr/local/lib when launching unity-control-center. I'm having other weird problems with this self-compiled version, but I doubt it has anything to do with this patch.

Kai-Heng Feng (kaihengfeng) wrote :

Hi Rafał Cieślak,

I made a merge proposal on your patch (with credit).
Thanks for it!

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers