I need the full backtrace. Look for it in /var/log/Xorg.0.log (or friends). If you can grab it using gdb, that would be very helpful.

Created attachment 104999 [details]
xorg log files

Attached the logs which contain the full backtrace

==14408== Invalid read of size 8
==14408==    at 0x21EEC4: RRChangeOutputProperty (rrproperty.c:224)
==14408==    by 0x21F8B1: ProcRRChangeOutputProperty (rrproperty.c:539)
==14408==    by 0x15D8EE: Dispatch (dispatch.c:433)
==14408==    by 0x1619E5: dix_main (main.c:294)
==14408==    by 0x6D55EC4: (below main) (libc-start.c:287)
==14408==  Address 0x85ae678 is 56 bytes inside a block of size 88 free'd
==14408==    at 0x4C2BDEC: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==14408==    by 0x21EB0E: RRDeleteProperty.isra.0 (rrproperty.c:79)
==14408==    by 0xA9818B8: sna_output_backlight_set (sna_display.c:612)
==14408==    by 0xA989DAA: sna_output_set_property (sna_display.c:3174)
==14408==    by 0x21EEB6: RRChangeOutputProperty (rrproperty.c:217)
==14408==    by 0x21F8B1: ProcRRChangeOutputProperty (rrproperty.c:539)
==14408==    by 0x15D8EE: Dispatch (dispatch.c:433)
==14408==    by 0x1619E5: dix_main (main.c:294)
==14408==    by 0x6D55EC4: (below main) (libc-start.c:287)

Hmm, actually not returning FALSE from ChangeProperty is the failure mode here.

commit 9b2cf5c7ab6e1a4a9aa46b297fb2f90cb09124ec
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Aug 21 08:17:41 2014 +0100

    sna: Propagate failure from changing backlight value
    
    Especially when we delete the output property halfway through and the
    ChangeProperty routine then attempts to wire it back up...
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82833
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Jani, um, please fix asap. O is the backlight interface for minimum value, whatever you choose that to be.

Let's get a drm.debug=6 dmesg to dig deeper into the failure to set the backlight

Or maybe actually drm.debug=0xf just to be sure.

Looking closer, it is acpi_video0 and not intel_backlight so not a result of any recent i915.ko changes. Oops, sorry Jani.

Please ls /usr/libexec and ps ax.

So that make that "ls -l /usr/libexec" and "pkexec --version"

$ ls -l /usr/libexec
ls: cannot access /usr/libexec: No such file or directory

$ pkexec --version
pkexec version 0.112

Your system relies on the xf86-video-intel-backlight-helper (since you are using an unprivileged Xserver) and that does not appear to be available. Closing as the original bug is now fixed.

I have the same problem on an updated Arch Linux, but I didn't understand, is there anything I can do to fix it? I have posted my question here:

https://bbs.archlinux.org/viewtopic.php?id=186939

Thanks

It's an issue with the Arch configuration: they have disabled root privileges for Xorg which prevents us from changing the backlight value directly, and instead have a setuid helper with which we communicate to do so. However, that helper is not installed on your system and so it fails. The crash itself is fixed upstream, which should now be available in the 2.99.916 package.

Thank you for the explanation, I just done an update and xf86-video-intel 2.99.916-1 is installed. But there is no difference. Is there nothing I can manually do to allow root access to xorg?

I do have to add that it isn't only Xorg that can't load the dell-backlight. In the Linux boot log, I get this:

[FAILED] Failed to start Load/Save Screen Backlight Brightness of backlight:dell_backlight
See 'systemctl status systemd-backligh@backlight:dell_backlight.service

But after failing with dell_backlight, it succeeds in starting intell_backlight and the boot loading continues. 

Is there any way I can tell Xorg to also try intel_backlight when it fails with dell_backlight?

Thanks in advance

It can be just as simple as setting the setuid bit on the Xorg binary (chmod +s). To override the choice in backlight use

Section "Device"
  Identifier "intel"
  Option "backlight" "intel_backlight"
EndSection

(and place that in /etc/X11/xorg.conf or /etc/X11/xorg.conf.d/backlight.conf)

Thank you, I changed the dell_backlight to intel_backlight, but only the name in the error changed. So this wan't the solution. 

I have to apologize for my ignorance, but could you guide me on how I can find The Xorg binary? I have 'Xorg' and 'Xorg.bin' in both the /bin and /usr/bin directories. So I applied 'chmod +s' to Xorg* files in both these directories but nothing changed.

Could be that it is using the wrapper to drop any root privileges when run anyway. Try:

echo need_root_rights=yes >> /etc/X11/Xorg.wrapper

(I think at least from reading the code.)

thank you, this seems to have fixed it. however, it seems that I still need to disable systemd-backligh@backlight:dell_backlight.service for X to load. if I don't disable it, startx will fail the next time. 

Event though I used 'systemctl disable' it doesn't seem to stop its loading on the next time. is there a way I can permanently disable or delete dell_backlight?

I really appreciate your help, thank you.

Maybe try acpi_backlight=vendor on the kernel commandline. (I am never certain which option is the right one).

Alternatively, you can try

echo blacklist dell-laptop >> /etc/modprobe.d/backlight.conf

and rebuild your initramfs just in case.

I applied these steps, and there is no more complaints about the dell_backlight. but when I run startx, it doesn't load, it seems it can't find the hardware! Here are the last four lines of /var/log/Xorg.0.log:

evdev: video Bus: Close
UnloadModule: "evdev" 
systemd-logins: releasing fd for 13:76
Server terminated successfully (0). Closing log file

The first three lines are repeated several times for the following issues too: 

Dell WMI hotkeys, AlpsPS/2 ALPS GuidePoint, AlpsPS/2 Device, AT translated Set 2 keyboard, Integrated_Webcam_1.3M, HID 413c:8162, HID 413c:8161, Sleep Button and Power Button.