Public bug reported:
-- 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.
** Affects: unity-settings-daemon (Ubuntu)
Importance: Undecided
Status: New
** Patch added: "A patch that implements the proposed fix."
https://bugs.launchpad.net/bugs/1575867/+attachment/4649396/+files/fix_config_matching.patch
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to unity-settings-daemon in Ubuntu.
https://bugs.launchpad.net/bugs/1575867
Title:
unity-settings-daemon crashes on start with SIGABRT if xrandr provides
two displays with the same name
Status in unity-settings-daemon package in Ubuntu:
New
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.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unity-settings-daemon/+bug/1575867/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : [email protected]
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
