gnome-settings-daemon crashed with SIGSEGV

I confirm that disabling the xrandr plugin make gnome-settings-daemon work

Same here.

I also noticed that I have two subtrees for gnome-settings-daemon in gconf: gnome-settings-daemon and gnome_settings_daemon. I had to disable the xrandr in the latter one to get things back to work.

A backtrace :

--- stack trace ---
#0 rw_output_by_id (info=0x0, id=77) at randrwrap.c:122
 output = <value optimized out>
#1 0xb6dc9990 in screen_info_new (screen=<value optimized out>) at randrwrap.c:606
 info = (ScreenInfo *) 0x80a4e50
#2 0xb6dc9f3b in rw_screen_new (gdk_screen=0x806e0b0, callback=0xb6e05340 <on_randr_event>, data=0x0) at randrwrap.c:391
 screen = (RWScreen *) 0x80a4c10
 dpy = (Display *) 0x8062878
 event_base = 98
 ignore = 173
#3 0xb6e05410 in gsd_xrandr_manager_start (manager=0x8078080, error=0xbf901500) at gsd-xrandr-manager.c:114
 rw_screen = <value optimized out>
#4 0xb6e0520f in impl_activate (plugin=0x80892c8) at gsd-xrandr-plugin.c:78
 res = <value optimized out>
 error = (GError *) 0x0
#5 0x0804b86e in gnome_settings_plugins_engine_activate_plugin (info=0x8087688) at gnome-settings-plugins-engine.c:533
 __PRETTY_FUNCTION__ = "gnome_settings_plugins_engine_activate_plugin"
#6 0x0804bb98 in activate_plugin (info=0x8087688, user_data=0x0) at gnome-settings-plugins-engine.c:244
 res = <value optimized out>
#7 0xb76af041 in IA__g_slist_foreach (list=0x8080fd0, func=0x804bb80 <activate_plugin>, user_data=0x0)
    at /build/buildd/glib2.0-2.15.6/glib/gslist.c:468
 next = (GSList *) 0x8080fe0
#8 0x0804beba in gnome_settings_plugins_engine_init (gconf_prefix=0x8082820 "/apps/gnome_settings_daemon/plugins")
    at gnome-settings-plugins-engine.c:346
 __PRETTY_FUNCTION__ = "gnome_settings_plugins_engine_init"
#9 0x0804acd3 in gnome_settings_manager_start (manager=0x8077f48, error=0xbf901634) at gnome-settings-manager.c:106
No locals.
#10 0x0804aa5a in main (argc=134712472, argv=0x2) at main.c:221
 manager = (GnomeSettingsManager *) 0x8077f48
 program = (GnomeProgram *) 0x80732b8
 res = <value optimized out>
 error = (GError *) 0x0
--- thread stack trace ---
.
Thread 2 (process 19530):
#0 0xb7fc6410 in __kernel_vsyscall ()
#1 0xb764d99b in read () from /lib/tls/i686/cmov/libpthread.so.0
#2 0xb7691cba in child_watch_helper_thread (data=0x0) at /build/buildd/glib2.0-2.15.6/glib/gmain.c:3910
 b = "\n\236d�(s��*\017u�\001\000\000\000\230K\b\b"
 list = (GSList *) 0x8084b98
#3 0xb76b8fef in g_thread_create_proxy (data=0x8084b98) at /build/buildd/glib2.0-2.15.6/glib/gthread.c:635
 __PRETTY_FUNCTION__ = "g_thread_create_proxy"
#4 0xb76464fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#5 0xb75c88ee in clone () from /lib/tls/i686/cmov/libc.so.6
.
Thread 1 (process 19528):
#0 rw_output_by_id (info=0x0, id=77) at randrwrap.c:122
 output = <value optimized out>
#1 0xb6dc9990 in screen_info_new (screen=<value optimized out>) at randrwrap.c:606
 info = (ScreenInfo *) 0x80a4e50
#2 0xb6dc9f3b in rw_screen_new (gdk_screen=0x806e0b0, callback=0xb6e05340 <on_randr_event>, data=0x0) at randrwrap.c:391
 screen = (RWScreen *) 0x80a4c10
 dpy = (Display *) 0x8062878
 event_base = 98
 ignore = 173
#3 0xb6e05410 in gsd_xrandr_manager_start (manager=0x8078080, error=0xbf901500) at gsd-xrandr-manager.c:114
 rw_screen = <value optimized out>
#4 0xb6e0520f in impl_activate (plugin=0x80892c8) at gsd-xrandr-plugin.c:78
 res = <value optimized out>
 error = (GError *) 0x0
#5 0x0804b86e in gnome_settings_plugins_engine_act...

StacktraceTop:?? ()
?? ()
?? ()
?? ()
?? ()

thank you for your bug report. That's due to the new xrandr changes

what video driver and xorg configuration are you using?

graphic card : intel 855 GM

Attached is my xorg.conf

Tried this with the fglrx and the radeonhd driver. Both give same problem.
Attached is my xorg.conf

On 01-03-08 15:26, Sebastien Bacher wrote:
> what video driver and xorg configuration are you using?
>
>

--
Regards,

Jacco van Koll

<email address hidden>

# xorg.conf (xorg X Window System server configuration file)
#
# This file was generated by dexconf, the Debian X Configuration tool, using
# values from the debconf database.
#
# Edit this file with caution, and see the xorg.conf manual page.
# (Type "man xorg.conf" at the shell prompt.)
#
# This file is automatically updated on xserver-xorg package upgrades *only*
# if it has not been modified since the last upgrade of the xserver-xorg
# package.
#
# If you have edited this file but would like it to be automatically updated
# again, run the following command:
# sudo dpkg-reconfigure -phigh xserver-xorg

Section "ServerLayout"
 Identifier "Default Layout"
 Screen "aticonfig-Screen[0]" 0 0
 InputDevice "Generic Keyboard"
 InputDevice "Configured Mouse"
EndSection

Section "Files"

 # path to defoma fonts
 FontPath "/usr/share/fonts/X11/misc"
 FontPath "/usr/share/fonts/X11/cyrillic"
 FontPath "/usr/share/fonts/X11/100dpi/:unscaled"
 FontPath "/usr/share/fonts/X11/75dpi/:unscaled"
 FontPath "/usr/share/fonts/X11/Type1"
 FontPath "/usr/share/fonts/X11/100dpi"
 FontPath "/usr/share/fonts/X11/75dpi"
 FontPath "/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType"
EndSection

Section "Module"
 Load "i2c"
 Load "GLcore"
 Load "bitmap"
 Load "ddc"
 Load "dri"
 Load "extmod"
 Load "freetype"
 Load "glx"
 Load "int10"
 Load "vbe"
 Load "type1"
 Load "xv"
EndSection

Section "InputDevice"
 Identifier "Generic Keyboard"
 Driver "kbd"
 Option "CoreKeyboard"
 Option "XkbRules" "xorg"
 Option "XkbModel" "pc105"
 Option "XkbLayout" "us"
EndSection

Section "InputDevice"
 Identifier "Configured Mouse"
 Driver "mouse"
 Option "CorePointer"
 Option "Device" "/dev/input/mice"
 Option "Protocol" "ImPS/2"
 Option "ZAxisMapping" "4 5"
 Option "Emulate3Buttons" "true"
EndSection

Section "Monitor"

 # ModeLine "1680x1050" 146.2 1680 1784 1960 2240 1050 1053 1059 1089
 Identifier "aticonfig-Monitor[0]"
 HorizSync 24.0 - 83.0
 VertRefresh 55.0 - 76.0
 Option "VendorName" "ATI Proprietary Driver"
 Option "ModelName" "Generic Autodetecting Monitor"
 Option "DPMS" "true"
EndSection

Section "Device"
 Identifier "aticonfig-Device[0]"
 Driver "radeonhd"
 Option "VideoOverlay" "on"
 Option "OpenGLOverlay" "off"
 Option "UseInternalAGPGART" "yes"
 Option "MonitorLayout" "AUTO, AUTO"
 BusID "PCI:2:0:0"
EndSection

Section "Screen"
 Identifier "aticonfig-Screen[0]"
 Device "aticonfig-Device[0]"
 Monitor "aticonfig-Monitor[0]"
 DefaultDepth 24
 SubSection "Display"
  Depth 1
  Modes "1680x1050" "1600x1200" "1280x1024" "1024x768" "832x624" "800x600" "720x400" "640x480"
 EndSubSection
 SubSection "Display"
  Depth 4
  Modes "1680x1050" "1600x1200" "1280x1024" "1024x768" "832x624" "800x600" "720x400" "640x480"
 EndSubSection
 SubSection "Displa...

No problem with the i810 driver, but i guess it's because it don't support randr 1.2

Not sure if I'm allowed to mark this as confirmed, but I would like to.

1. I installed Gutsy
2. I applied all updates as of March,2008
3. I upgrade to Hardy, on March 1, 2008
4. Upon logging in gnome-settings-daemon error occured
5. Apport launched, and brought me here, where I found this error.

As apport brought me here, I can attach messages and files but I'm not sure where apport puts them.

Hi Arthur,

I think that there may be enough information already, so the
apport files are not needed.

Could you please confirm your video card type and the driver
you use, and attach your xorg.conf please?

Thanks,

James

I'm stumbling upon the same problem, using the intel driver. Should I attach any information or is there enough now to debug this issue?

By the way, what exactly does it mean that gnome-settings-daemon has xrandr to capabilities?

James Westby wrote:
> Hi Arthur,
>
> I think that there may be enough information already, so the
> apport files are not needed.
>
> Could you please confirm your video card type and the driver
> you use, and attach your xorg.conf please?
>
> Thanks,
>
> James
>
>
Dear James,

Here is output of lspci | grep graphics:

arthur@archnix:~$ lspci | grep Graphics
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS,
943/940GML Express Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME,
943/940GML Express Integrated Graphics Controller (rev 03)

I will attach output of cat /etc/X11/xorg.conf.

I will attach output of lsmod once I reboot into the hardy system.

Best wishes,

AA.

arthur@archnix:/nix/testing/etc/X11$ cat xorg.conf
# I have cut irrelevant info. Please not that I am doing this from my working gutsy system, thus, the path above.
Section "Device"
        Identifier "Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller"
        Driver "intel"
        BusID "PCI:0:2:0"
EndSection

Section "Monitor"
        Identifier "Generic Monitor"
        Option "DPMS"
EndSection

Section "Screen"
        Identifier "Default Screen"
        Device "Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller"
        Monitor "Generic Monitor"
        DefaultDepth 24
        SubSection "Display"
                Modes "1280x800"
        EndSubSection
EndSection

Section "ServerLayout"
        Identifier "Default Layout"
        Screen "Default Screen"
        InputDevice "Generic Keyboard"
        InputDevice "Configured Mouse"
        InputDevice "Synaptics Touchpad"

I'm affected by that problem and that "force" to use the default gnome theme.
My video card is: Intel 82855GME

And now my xorg.conf below:

I see the same problem with the radeonhd driver (latest from git).

My xorg.conf is Hardy default except for adding the line

Driver "radeonhd"

to the device section.

System behaves normally when using the vesa driver.

The workaround works for me, I used gconf-editor to disable the plugin.

I also see this behavior. I'm using the nvidia driver on i386 on a machine that I recently upgraded from gutsy to hardy. I have

(==) RandR enabled

in my X log, but

$ xrandr -q
X Error of failed request: BadRequest (invalid request code or no such operation)
  Major opcode of failed request: 151 (RANDR)
  Minor opcode of failed request: 6 ()
  Serial number of failed request: 9
  Current serial number in output stream: 9

Appear to have same problem with AMD64 on a MSI MS-7093 motherboard and NVIDIA GeForce 7300 GS running nvidia-glx-new 169.12+2.6.24.10-11.29 (NVIDIA 169.12 driver). I've attached my xorg.conf file.

Another confirmation with newest update on March 2. Using radeonhd driver.

Another confirmation running nvidia-glx-new. I have two video cards set up in dual head mode, similar to that described in bug #197354.

From the confirmations, it sounds like all the reporters are using drivers or hardware without proper xrandr 1.2 support. I would imagine fglrx users would have the same problem.

This will require adding some checks to verify 1.2 capabilities of the drivers in g-s-d I suppose. I'll work on it this week; meanwhile disabling the xrandr module is probably the best workaround for now.

@Bryce: Not true, I mentioned I'm using the intel driver which indeed has proper xrandr 1.2 support. Do you want me to post my xorg.conf?

2008/3/3, Bryce Harrington <email address hidden>:
>
> >From the confirmations, it sounds like all the reporters are using
> drivers or hardware without proper xrandr 1.2 support. I would imagine
> fglrx users would have the same problem.

Do you mean that the intel driver with an intel 855 card is not enough
for proper xrandr 1.2 support ?

I have this problem on my system as well. I use the radeonhd driver. It goes away if I set /apps/gnome-settings-daemon/plugins/xrandr/active and /apps/gnome_settings_daemon/plugins/xrandr/active both to false (perhaps one of the might have been enough).

Based on Bryce's instructions on IRC, I verified that the driver seems to have xrandr 1.2 support:

xrandr -q reports sensible stuff

xrandr --output VGA_1 --mode 1024x768 sets the mode correctly

xrandr --output VGA_1 --auto correctly resets the mode back to what it should be

I don't believe Bug #197665 is a duplicate of this one, in my case it doesn't seem to segfault.

Tested bug's workaround and disabling xrandr pluggin does gnome_setting_deamon stop crashing.

could somebody not getting the crash but a xorg bad request install llibgtk2.0-0-dbgsym libgnome-desktop-2-dbgsym gnome-settings-daemon-dbgsym, run it under gdb, break on gdk_x_error and get a stacktrace?

On Mon, Mar 03, 2008 at 09:09:54PM -0000, Sebastien Bacher wrote:
> could somebody not getting the crash but a xorg bad request install
> llibgtk2.0-0-dbgsym libgnome-desktop-2-dbgsym gnome-settings-daemon-
> dbgsym, run it under gdb, break on gdk_x_error and get a stacktrace?

Those packages don't seem to exist under hardy.

llibgtk2.0-0-dbgsym -> libgtk2.0-0-dbg
libgnome-desktop-2-dbgsym -> ?
gnome-settings-daemon-dbgsym -> ?

Ryan

> Those packages don't seem to exist under hardy.

Use this repo :

deb http://ddebs.ubuntu.com hardy main universe

Hi Ryan,

Please see

https://wiki.ubuntu.com/DebuggingProgramCrash

for information on getting those packages.

Thanks,

James

Looking at all the bug reports, the issue is identical - in gnome-desktop, the output_initialize() routine, output->info is not getting checked for a NULL pointer.

Here's a trivial patch to add a check for the aforementioned null pointer. It doesn't address the underlying issue of why the pointer is null in the first place (likely lack of xrandr 1.2 support); I'll investigate that further.

In looking further, I notice that the new code dropped an #ifdef HAVE_RANDR which actually we probably still need. Attached is a patch to resolve that.

This probably only addresses cases where Xrandr is not used at all - like Xinerama configs or drivers with absolutely no xrandr support.

I also a lack of checks for xrandr 1.2 as opposed to xrandr 1.0. I'll look into that next.

>(likely lack of xrandr 1.2 support)
Just for the record, Bryce, I'm sure using xrandr 1.2. I switch between, external, internal and dual screen setups all the time using randr and xrandr 1.2.

I've posted some packages to http://people.ubuntu.com/~bryce/Uploads/ for testing, including debs.

These include checks for if xrandr is available (which should help Xinerama users), if the xrandr version is 1.2 (which should help nvidia and fglrx users, and maybe others), and the null pointer check I posted above.

For radeonhd and intel 8xx, both of which say they support xrandr 1.2, I don't think this will fix the issues, but the null pointer check will change the behavior a bit (probably will still crash but in a different spot).

Please test these debs and let me know whether it addressed the issue or not, and what video driver you tested with.

This bug was fixed in the package gnome-desktop - 1:2.21.92-0ubuntu3

---------------
gnome-desktop (1:2.21.92-0ubuntu3) hardy; urgency=low

  * debian/patches/102_gd-xrandr-null-pointer-check.patch:
    - Adds a null pointer check to prevent an assertion at a later point
      in the code, which has been causing gnome-settings-daemon to fail
      (LP: #197153)

 -- Bryce Harrington <email address hidden> Mon, 03 Mar 2008 23:23:39 -0800

the change fixes the crash when using radeonhd, I've uploaded the new revision

Confirmed that switching from a Xinerama based dual-head config to a TwinView based config (Nvidia 7800GTX with proprietary driver in both cases) stops the crash from happening. It's clearly something that disagrees with Xinerama, which unfortunately is the config used when the GUI admin tool "Screens and Graphics" is used to enable the second monitor.

If xrandr is supposedly the way to do this properly and non-proprietarily, shouldn't the "Screens and Graphics" tool be outputting that style of config where the driver supports it ?

On Tue, 2008-03-04 at 07:44 +0000, Bryce Harrington wrote:
> I've posted some packages to http://people.ubuntu.com/~bryce/Uploads/
> for testing, including debs.
>
> These include checks for if xrandr is available (which should help
> Xinerama users), if the xrandr version is 1.2 (which should help nvidia
> and fglrx users, and maybe others), and the null pointer check I posted
> above.
>
> For radeonhd and intel 8xx, both of which say they support xrandr 1.2, I
> don't think this will fix the issues, but the null pointer check will
> change the behavior a bit (probably will still crash but in a different
> spot).
>
> Please test these debs and let me know whether it addressed the issue or
> not, and what video driver you tested with.
>
video card/driver ATI X1950XTX using radeonhd (latest from git)

gnome-desktop1:2:21.92-ubuntu3 (installed via update) changed behavior a
bit but did not solve the problem gnome-settings-daemon crash.

installing gnome-settings-daemon_2.21.91-0ubuntu6_i386.deb from Bryce's
download site appartently has solved the gnome-settings-daemon problem
and my system appears to work normally.

tks to all

Excellent news that the gnome-desktop changed fixed the problems on radeonhd. I'll forward the fix upstream.

I'd like to hear from the folks on intel with this problem, to see if it solves the issue there as well.

Rick, Xinerama and Xrandr are sort of ying and yang; Xinerama being the old, deprecated method and Xrandr the future. These days only a few drivers (such as the proprietary ones) still support Xinerama. Screens and Graphics (aka displayconfig-gtk) is a Xinerama-based tool; it was developed back before Xrandr was very widely available. These days with so many drivers now using Xrandr, this has rendered displayconfig-gtk obsolete. Thus these efforts into switching over to this new Xrandr config tool.

So the plan is to drop displayconfig-gtk. For all the Xrandr based drivers, this new tool will be better (the only remaining missing capability is driver switching, but I guess we can go back to xorg.conf editing for that for now). For proprietary drivers, nvidia and fglrx both include their own config update tools. The remaining non-Xrandr drivers are much less commonly used; often they're deployed using static xorg.conf's anyway.

Thanks for the swift testing guys. Seb128, based on rbmorse's tests, the g-s-d change should be uploaded as well. It just adds checks that xrandr 1.2 is present (as jcristau suggested yesterday), so should be very safe and regression free.

Some results with an intel 855 GM :

With gnome-settings-daemon 2.21.91-0ubuntu6 and gnome-desktop 2:21.92-ubuntu3
gnome-settings-daemon don't crash anymore at startup.

However, gnome-display-properties still crash with a sligthly different backtrace :

#0 rw_output_by_id (info=0x1af28, id=77) at randrwrap.c:122
 output = <value optimized out>
#1 0xb7ef7970 in screen_info_new (screen=<value optimized out>)
    at randrwrap.c:606
 info = (ScreenInfo *) 0x81d2f90
#2 0xb7ef7f0b in rw_screen_new (gdk_screen=0x80710b0,
    callback=0x804cdb0 <gdk_x11_get_default_xdisplay@plt+4584>, data=0x8077128)
    at randrwrap.c:391
 screen = (RWScreen *) 0x81d2f00
 dpy = (Display *) 0x8065578
 event_base = 98
 ignore = 173
#3 0x0804cfea in main ()

Let me confirm what Florent reported.

I'm using the radeonhd driver (latest from git).

I previously indicated the gnome-setting-daemon_2.21.91-0ubuntu6-i386.deb package had fixed the problem, but further poking around reveals that only the crash on startup symptom was fixed.

Selecting system>preferences>screen resolution from the menu still triggers a crash.

@Bryce: that's good to hear there's a new tool being developed. You don't actually seem to mention its name anywhere though - are you referring to the individual per-driver proprietary settings tools (like nvidia-settings) as the successor to displayconfig-gtk ? or is there something else.

For the record, I like the approach of having a display config tool that is independent of the driver to a degree (or at least always in the same menu spot like displayconfig-gtk is). Would it be possible to make the "Screens and graphics" link be some sort of switching alias that launches the specific config tool (e.g. nvidia-settings) for the loaded X driver if available, and the deprecated displayconfig-gtk as a fallback ?

@Florent and rbmorse: Thanks for confirming that the crash is gone on 855, that's a relief. So technically this bug is solved - system start up is no longer prevented. I'm dropping the priority and milestone.

For the separate gnome-display-properties crash, unfortunately that means this tool is not going to function on your system for now. I will add an error dialog so it errors out gracefully rather than gives a crash in these cases, but we need to explore that in more detail - please open new bugs (against the specific graphic driver) that gnome-display-properties does not run on your hardware? (This bug is getting rather long, so if/when we upstream the bug, it'll be clearer if it's focused on this one specific issue.)

I'll consider this bug closed once we have the error dialog in place. That will be post-alpha6 though.

Bryce Harrington schrieb:
> @Florent and rbmorse: Thanks for confirming that the crash is gone on
> 855, that's a relief. So technically this bug is solved - system start
> up is no longer prevented. ...
same here, crash gone (855GM in FSC lifebook P7010), I also tried
meanwhile two other machines, they weren't affected by the bug at all
(915GM based, FSC Lifebook P7120 and transtec Levio 210).

Thanks

Albrecht

Bryce Harrington a écrit :
> @Florent and rbmorse: Thanks for confirming that the crash is gone on
> 855, that's a relief. So technically this bug is solved - system start
> up is no longer prevented. I'm dropping the priority and milestone.
>
> For the separate gnome-display-properties crash, unfortunately that
> means this tool is not going to function on your system for now. I will
> add an error dialog so it errors out gracefully rather than gives a
> crash in these cases, but we need to explore that in more detail -
> please open new bugs (against the specific graphic driver) that gnome-
> display-properties does not run on your hardware? (This bug is getting
> rather long, so if/when we upstream the bug, it'll be clearer if it's
> focused on this one specific issue.)
>

I opened a new one for intel 855GM : #198951

Thanks

This one seems to have recurred in 2.21.92-0ubuntu1, please review bug 199960

I confirm this problem has reemerged. Gnome-Settings-Daemon crashes during IPL sequence when xrandr 1.2 is active. The video driver is radeonhd (latest from git).

This seem to have recurred as bug 199960, can somebody take a look?

could you stop adding comments? today is sunday and not every is working, don't use an unstable version if you don't want issues

On Sun, 2008-03-09 at 18:51 +0000, Sebastien Bacher wrote:
> could you stop adding comments? today is sunday and not every is
> working, don't use an unstable version if you don't want issues
>
Am I supposed to not report problems? I thought the whole purpose of
testing the unstable version was to identify problems and report them.

reporting bugs is useful but sending several comments on different bugs is not, just using the new opened one would be enough and the comment was rather about the other requests which were the same question repeted and doesn't bring anything constructive there

I worked a bit on the dialog Friday, but unfortunately I found that the way the gui and daemon work, the settings are applied and *then* tested, rather than vice versa as the old Screen Resolution tool did, so it's not 100% obvious how to implement a revert capability. I've asked upstream for direction, and am awaiting feedback.

It seems there is a new bug report entered about the need for a revert dialog (197673), so I'm going to start tracking that issue there instead of on this bug report, and mark that task of this bug as invalid. All other subsequent issues (including the regressions after latest gnome upgrades) have been reported to new bug reports, so since the original issue was addressed this can be closed.

I will be tracking other issues on the following bug reports:
197673: Automatic revert dialog needed
197740: 1280x1024 used instead of LVDS/DVI preferred resolutions
199718: After upgrade, Xrandr GUI works only after logging out / back in
198951: gnome-display-properties crashes for i855, fglrx, radeonhd, etc. (request_code 151 minor_code 6) - reversion due to XRANDR becoming defined in recent gsd upload

Sebastien,

I apologize if my double/excessive posting caused you any inconvenience.
I commend you for your work on Ubuntu and look forward to any pointers on bug etiquette I should follow in the future.

Thanks an best regards,
Alex

----- Original Message ----
From: Sebastien Bacher <email address hidden>
To: <email address hidden>
Sent: Sunday, March 9, 2008 3:35:21 PM
Subject: [Bug 197153] Re: gnome-settings-daemon crashed with SIGSEGV

 reporting bugs is useful but sending several comments on different bugs
is not, just using the new opened one would be enough and the comment
was rather about the other requests which were the same question repeted
and doesn't bring anything constructive there

--
gnome-settings-daemon crashed with SIGSEGV
https://bugs.launchpad.net/bugs/197153
You received this bug notification because you are a direct subscriber
of a duplicate bug.

Btw, for those not yet subscribed to bug 198951:

I believe this issue is due to bugs in xrandr rather than an issue in gnome-settings-daemon itself. I've backported several bug fixes from upstream that look relevant to making xrandr work properly - these are from one of the radeonhd developers, so will be especially relevant for radeonhd users (and I suspect also relevant for other users).

Please install the three X server debs from this url which have been patched with the fixes, re-test, and let me know if it improves things:

  http://people.ubuntu.com/~bryce/Testing/XrandrGui/

After installing those debs, I only get this in the terminal when running it:

blah@blah-laptop:~$ gnome-display-properties
Resource Timestamp: 59462
Resource Configuration Timestamp: 59462
CRTC 41 Timestamp: 59462
CRTC 42 Timestamp: 59462
Output 43 Timestamp: 59462
Segmentation fault (core dumped)

Using RadeonHD drivers

Arthur, these are fixes to gnome-settings-daemon, not gnome-display-properties. For the gnome-display-properties issue, you'll need to install the .deb posted to bug 198951.

I have the same problems and unfortunately posted all my information to Bug #83152 as it was the first one I found with the summary I was searching for.

I'm still getting this with an update hardy, though the bug says fix released.
jan@osprey:~$lspci|grep Graph
00:02.0 VGA compatible controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02)
00:02.1 Display controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02)

jan@osprey:~$gnome-settings-daemon
Resource Timestamp: 103669
Resource Configuration Timestamp: 103669
CRTC 49 Timestamp: 103669
CRTC 4a Timestamp: 103669
Output 4b Timestamp: 103669
Segmentation fault (core dumped)

jan@osprey:~$cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=8.04
DISTRIB_CODENAME=hardy
DISTRIB_DESCRIPTION="Ubuntu hardy (development branch)"
jan@osprey:~$grep Driver /etc/X11/xorg.conf
 Driver "kbd"
 Driver "mouse"
 Driver "synaptics"
 Driver "wacom"
 Driver "wacom"
 Driver "wacom"
 Driver "intel"

The bug reappeared on my intel 855 based laptop (FSC P7120) too (it was fixed with some intermediate release)

Albrecht

I'm experiencing this bug on an intel 855 based laptop but it has NOT been fixed as of Mar 16 CST 5:27 (DST).
This is after implementing some fixes I've described on a seemingly adjacent bug report concering the intel driver w/ Xorg.

I can confirm that disabling xrandr with gconf-editor fixes this issue, along with a related crash-on logoff issue.

I can confirm the same on an Intel 855GM card. After implementing fixes from this bug (where you'll see my other comments) and disabling xrandr in gconf-editor I am able to use the intel driver, at the correct resolution and DPI without xrandr crashing.
(https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/151311)

On the other hand, this may be a bug with the actual intel driver, it feels slower than th i810 driver. It seems like its taking much longer to redraw/rerender windows...

Same here but I have an Nvidia GF7300...
Disabling xrandr in gconf-editor seems to fix it, at least I can login.

After the latest updates everything seems to work fine for me; the xrandr module in gnome-settings-daemon as well as the gnome-display-properties utility. This is on 855GM hardware, using the intel driver.

Cheers!

Simone, this bug has been fixed, if you still have an issue that's a different one so open a new bug

Hi

On Wed, Mar 19, 2008 at 05:31:19PM -0000, Sebastien Bacher wrote:
> Simone, this bug has been fixed, if you still have an issue that's a
> different one so open a new bug

Latest update and this is fixed for me, xrandr on,
gnome-settings-daemon starts, intel driver.

great.

Jan
--
   .~.
   /V\ Jan Groenewald
  /( )\ www.aims.ac.za
  ^^-^^

I still have this issue (nvidia driver) and cannot start gnome-settings-daemon with xrandr enabled (8.04 fully updated). So either i am experiencing another bug or this issue is still there.

The program 'gnome-settings-daemon' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadRequest (invalid request code or no such operation)'.
  (Details: serial 5739 error_code 1 request_code 151 minor_code 6)
  (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.)
[1206174351,000,xklavier.c:xkl_engine_start_listen/] The backend does not require manual layout management - but it is provided by the application

Longsleep, this is a different bug. please see Bug #199960

Thanks

This bug has been reported on the Ubuntu localized ISO testing tracker.

A list of all reports related to this bug can be found here:
http://localized-iso.qa.ubuntu.com/qatracker/reports/bugs/197153

12.04 Beta 2 booted ran a few minutes and got this bug.

Jerry

Eh, just trying the new LTS - looking to get the text instead of icons - One of those who reads not looks.
This error just popped up when I was looking at Settings - running form live CD - maybe after 2 minutes after booting.
EDITORIAL: Oh my, looks like a fun time ahead... Ugh!
MRK

Every time I boot quantal 12.10 daily image I get one or more of these errors on netbook, notebook, tower. My daily image is up to date as of yesterday 1 June.

Jerry

Occurred again on quantal daily build just now, 2 June, on booting startup-disk

At least apport is working now, for the last days and days it didn't follow through to launchpad.

Jerry

6 June Quantal daily build install all up to date 3.4.0-5 likely near Alpha 1 level still occurring on widescreen notebook.

Jerry

Up-to-date Quantal Alpha-1 with Fallback No Effects on ASUS eeePC900 + ext mon. Still producing these at random.

This bug is closed; it's better to open a new bug (with fresh backtrace and logs) than to comment on this one.

In investigating further it appears that something (apport?) is linking people to this bug report. However, this bug was fixed four years ago. It's likely the logic in whatever is linking to this is faulty in some fashion, rather than that this ancient crash has "come back".

In any case, like I said, a new bug should be filed for this issue.

Bryce, note that apport is now implementing client-side dupe checking which may be to blame here for bugs being considered duplicates. People are going to have a hard time filing a new bug report if that's the case. At any rate, if apport thinks they're duplicates, that implies the signature of the new backtrace matches this one.