Bug 867455 - [abrt] xfce4-settings-4.10.0-3.fc18: handle_error: Process /usr/bin/xfsettingsd was killed by signal 5 (SIGTRAP)
[abrt] xfce4-settings-4.10.0-3.fc18: handle_error: Process /usr/bin/xfsetting...
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: xfce4-settings (Show other bugs)
19
x86_64 Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Kevin Fenzi
Fedora Extras Quality Assurance
abrt_hash:aafe3bd6ca143f8c822a402337b...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-17 10:40 EDT by John Ellson
Modified: 2016-02-25 03:08 EST (History)
16 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-02-18 08:46:30 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
File: core_backtrace (1.86 KB, text/plain)
2012-10-17 10:40 EDT, John Ellson
no flags Details
File: environ (2.11 KB, text/plain)
2012-10-17 10:40 EDT, John Ellson
no flags Details
File: backtrace (30.70 KB, text/plain)
2012-10-17 10:40 EDT, John Ellson
no flags Details
File: limits (1.29 KB, text/plain)
2012-10-17 10:40 EDT, John Ellson
no flags Details
File: cgroup (129 bytes, text/plain)
2012-10-17 10:40 EDT, John Ellson
no flags Details
File: smolt_data (3.44 KB, text/plain)
2012-10-17 10:40 EDT, John Ellson
no flags Details
File: maps (34.46 KB, text/plain)
2012-10-17 10:40 EDT, John Ellson
no flags Details
File: dso_list (7.15 KB, text/plain)
2012-10-17 10:40 EDT, John Ellson
no flags Details
File: proc_pid_status (919 bytes, text/plain)
2012-10-17 10:40 EDT, John Ellson
no flags Details
File: var_log_messages (1.29 KB, text/plain)
2012-10-17 10:40 EDT, John Ellson
no flags Details
File: open_fds (324 bytes, text/plain)
2012-10-17 10:40 EDT, John Ellson
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Xfce 9680 None None None Never

  None (edit)
Description John Ellson 2012-10-17 10:40:03 EDT
Description of problem:
Rebooted system and logged in.  Errors reportd immediately without further action.

Version-Release number of selected component:
xfce4-settings-4.10.0-3.fc18

Additional info:
libreport version: 2.0.16
abrt_version:   2.0.15
backtrace_rating: 4
cmdline:        xfsettingsd --display :0.0 --sm-client-id 28f4476f9-90f1-4c5b-b649-c15418ae10ae
crash_function: handle_error
kernel:         3.6.1-1.fc18.x86_64

truncated backtrace:
:Thread no. 1 (8 frames)
: #4 handle_error at xcb_io.c:212
: #5 handle_response at xcb_io.c:324
: #7 _XiGetExtensionVersionRequest at XGetVers.c:93
: #8 _XiGetExtensionVersion at XGetVers.c:116
: #9 XGetExtensionVersion at XGetVers.c:71
: #10 xfce_pointers_helper_init at pointers.c:129
: #11 g_type_create_instance at gtype.c:1890
: #12 g_object_constructor at gobject.c:1854
Comment 1 John Ellson 2012-10-17 10:40:07 EDT
Created attachment 628854 [details]
File: core_backtrace
Comment 2 John Ellson 2012-10-17 10:40:09 EDT
Created attachment 628855 [details]
File: environ
Comment 3 John Ellson 2012-10-17 10:40:11 EDT
Created attachment 628856 [details]
File: backtrace
Comment 4 John Ellson 2012-10-17 10:40:14 EDT
Created attachment 628857 [details]
File: limits
Comment 5 John Ellson 2012-10-17 10:40:16 EDT
Created attachment 628858 [details]
File: cgroup
Comment 6 John Ellson 2012-10-17 10:40:17 EDT
Created attachment 628859 [details]
File: smolt_data
Comment 7 John Ellson 2012-10-17 10:40:19 EDT
Created attachment 628860 [details]
File: maps
Comment 8 John Ellson 2012-10-17 10:40:25 EDT
Created attachment 628861 [details]
File: dso_list
Comment 9 John Ellson 2012-10-17 10:40:27 EDT
Created attachment 628862 [details]
File: proc_pid_status
Comment 10 John Ellson 2012-10-17 10:40:28 EDT
Created attachment 628863 [details]
File: var_log_messages
Comment 11 John Ellson 2012-10-17 10:40:30 EDT
Created attachment 628864 [details]
File: open_fds
Comment 12 Kevin Fenzi 2012-10-17 13:47:37 EDT
Does this happen on every reboot? 

Were you in Xfce when you rebooted?
Comment 13 John Ellson 2012-10-17 15:47:42 EDT
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.
Comment 14 Jiri Moskovcak 2012-11-09 13:10:23 EST
Just hit this bug and it seems like it happens only when I have the external monitor connected.
Comment 15 Aleksandar Kostadinov 2012-12-23 16:48:33 EST
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
Comment 16 Bob Arendt 2013-01-23 14:07:28 EST
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?
Comment 17 Jeff Bastian 2013-01-24 16:45:18 EST
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.
Comment 18 Bob Arendt 2013-01-25 10:25:23 EST
(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).
Comment 19 Jeff Bastian 2013-01-25 11:17:56 EST
(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.
Comment 20 darton 2013-02-01 07:09:11 EST
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)
Comment 21 darton 2013-02-04 09:58:21 EST
(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.
Comment 22 darton 2013-02-22 09:40:59 EST
(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.
Comment 23 Jiri Moskovcak 2013-06-24 03:53:31 EDT
Still happens when I have an external monitor plugged in.
Comment 24 Harry Sutton 2013-07-02 07:07:54 EDT
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
Comment 25 markusN 2013-08-07 05:33:13 EDT
Potential duplicate: bug 994428
Comment 26 darton 2013-08-29 11:53:49 EDT
It still happens in Fedora19 (xfce4-settings-4.10.1-2.fc19, асtually), can someone update the metadata before it goes away with "WONTFIX"?
Comment 27 Aleksandar Kostadinov 2013-08-30 01:37:00 EDT
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
Comment 28 Kevin Fenzi 2013-08-30 17:23:17 EDT
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. ;(
Comment 29 Aleksandar Kostadinov 2013-09-01 05:18:38 EDT
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.
Comment 30 Fedora End Of Life 2015-01-09 17:01:08 EST
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.
Comment 31 Fedora End Of Life 2015-02-18 08:46:30 EST
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.

Note You need to log in before you can comment on or make changes to this bug.