Created attachment 628854 [details]
File: core_backtrace

Created attachment 628855 [details]
File: environ

Created attachment 628856 [details]
File: backtrace

Created attachment 628857 [details]
File: limits

Created attachment 628858 [details]
File: cgroup

Created attachment 628859 [details]
File: smolt_data

Created attachment 628860 [details]
File: maps

Created attachment 628861 [details]
File: dso_list

Created attachment 628862 [details]
File: proc_pid_status

Created attachment 628863 [details]
File: var_log_messages

Created attachment 628864 [details]
File: open_fds

Does this happen on every reboot? 

Were you in Xfce when you rebooted?

It happened on the first login after a reboot, but rebooting just now and logging in doesn't seem to reproduce the bug.

Yes I'm logging in to an XFCE desktop.

Just hit this bug and it seems like it happens only when I have the external monitor connected.

I'm also hitting this one when I have external monitor attached. And one of the following:
1) it is not configured through settings-manager
2) it is configured to a custom mode set through xrandr --newmode command

Pls see https://bugzilla.xfce.org/show_bug.cgi?id=9680

Very repeatable - also happens from the command line:
118% xfsettingsd 
119% 
(xfsettingsd:13066): Gdk-ERROR **: The program 'xfsettingsd' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadMatch (invalid parameter attributes)'.
  (Details: serial 132 error_code 8 request_code 139 minor_code 7)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

119% xfsettingsd --sync
120% rpm -qf /usr/bin/xfsettingsd 
xfce4-settings-4.10.0-3.fc18.x86_64
121% 

But always works if I add the --sync command.  I don't have a problem on my home 64-bit system, or another work 32-bit system.  But it's highly repeatable on this box.  Seems like a race condition.  Would you like output from a X11 protocol sniffer?

xfsettings was working fine for me in the office, but when I went home and plugged in my external monitor and booted, xfsettingsd crashed immediately on login.

I found this file only had knowledge of the laptop monitor and my monitor in the office on HDMI3:
  $ cat .config/xfce4/xfconf/xfce-perchannel-xml/displays.xml
  <channel name="displays" version="1.0">
    <property name="Default" type="empty">
      <property name="LVDS1" type="string" value="Laptop">
        ...
      </property>
      <property name="HDMI3" type="string" value="HDMI3">
        ...
      </property>
    </property>
  </channel>


I went to Settings -> Display and adjusted and applied the settings for my home monitor on HDMI1, then I looked at the displays.xml file and found it had created a new section for HDMI1:
  $ cat .config/xfce4/xfconf/xfce-perchannel-xml/displays.xml
  <channel name="displays" version="1.0">
    <property name="Default" type="empty">
      <property name="LVDS1" type="string" value="Laptop">
        ...
      </property>
      <property name="HDMI3" type="string" value="HDMI3">
        ...
      </property>
      <property name="HDMI1" type="string" value="HDMI1">
        ...
      </property>
    </property>
  </channel>


Now I can logout and login and xfsettingsd works fine every time.

(In reply to comment #17)
> I found this file only had knowledge of the laptop monitor and my monitor in
> the office on HDMI3:
>   $ cat .config/xfce4/xfconf/xfce-perchannel-xml/displays.xml
>   <channel name="displays" version="1.0">
>     <property name="Default" type="empty">
>       <property name="LVDS1" type="string" value="Laptop">

Thanks! This was key to fixing it for me.  I logged out, logged in on a console (i.e - no xsession) and
rm .config/xfce4/xfconf/xfce-perchannel-xml/displays.xml

On subsequent login this file was recreated correctly, and the issue is gone.  So the issue must happen when there are two displays, and I believe the name of the second display changed between my previous F16 install and this one.  Perhaps the logic assumes that if display.xml exists, and the first head exists, that the second head must also exist (or it crashes).

(In reply to comment #18)
> Perhaps the logic assumes that if display.xml exists, and the
> first head exists, that the second head must also exist (or it crashes).

Not quite, because I have 3 entries in my display.xml but I only ever have 2 connected at any one time.  In the office it's LVDS1 + HDMI3 (docking station) and at home it's LVDS1 + HDMI1.  And now I can go back and forth between home and the office and it's happy.

So maybe it crashes if there's a new display connected on a port that hasn't been used before and thus no entry in display.xml?

I should try connecting a plain VGA display and see what happens.

It first happened after system restart, and since then it re-appears upon each login.

backtrace_rating: 4
Package: xfce4-settings-4.10.0-3.fc18
OS Release: Fedora release 18 (Spherical Cow)

(In reply to comment #20)

In my case, it disappeared after running "yum reinstall xfce4-settings" and rebooting. I suppose the problem may have been caused by a corrupted config file that was rewritten during the re-installation process.

(In reply to comment #21)
> (In reply to comment #20)
> 
> In my case, it disappeared after running "yum reinstall xfce4-settings" and
> rebooting. I suppose the problem may have been caused by a corrupted config
> file that was rewritten during the re-installation process.

Oops, not true. Reinstall does not fix the bug. Actually it was a reboot with the "correct" external display plugged in.

Still happens when I have an external monitor plugged in.

Problem appears at startup (reproduceable); no other activity is occurring.

reporter:       libreport-2.1.5
backtrace_rating: 4
cmdline:        xfsettingsd --display :0.0 --sm-client-id 2b7dfdeff-3300-4862-8f5e-43d7414bede5
crash_function: handle_error
executable:     /usr/bin/xfsettingsd
kernel:         3.9.6-200.fc18.x86_64
package:        xfce4-settings-4.10.1-2.fc18
reason:         Process /usr/bin/xfsettingsd was killed by signal 5 (SIGTRAP)
runlevel:       unknown
uid:            1000

Potential duplicate: bug 994428

It still happens in Fedora19 (xfce4-settings-4.10.1-2.fc19, асtually), can someone update the metadata before it goes away with "WONTFIX"?

A good workaround for the bug is starting the daemon with the sync option. Is this possible to be done until it is fixed upstream? The upstream bug [1] does not take any attention as far as I see.

[1] https://bugzilla.xfce.org/show_bug.cgi?id=9680

Not sure thats a good idea... thats going to change things for all users, where only a small number of folks see this with multiple monitors. ;( 

You should be able to: 

cp /etc/xdg/autostart/xfsettingsd.desktop ~/.config/autostart/
edit ~/.config/autostart/xfsettingsd.desktop to add --sync
restart

I'll see if I can get anyone upstream more interested in looking into this. ;(

Would sync affect anything at all ? it's an app that is rarely doing anything, I don't think anybody would see any difference using sync or not.

This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.