Bug 100721 - Xorg crashes with SIGSEV in ProcXFixesGetCursorImageAndName()
Summary: Xorg crashes with SIGSEV in ProcXFixesGetCursorImageAndName()
Status: RESOLVED MOVED
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/General (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
: 99034 100799 (view as bug list)
Depends on:
Blocks:
 
Reported: 2017-04-19 10:55 UTC by Pierre Ossman
Modified: 2018-12-13 22:37 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Pierre Ossman 2017-04-19 10:55:28 UTC
We got this crash in Xvnc based on Xorg 1.14:

>  Core was generated by `/opt/thinlinc/libexec/Xvnc'.
>  Program terminated with signal 11, Segmentation fault.
>  #0  ProcXFixesGetCursorImageAndName (client=0x2d583b0) at cursor.c:517
>  517        width = pCursor->bits->width;

More detail in our bugzilla here:

https://www.cendio.com/bugzilla/show_bug.cgi?id=6234

It seems to be the same issue reported for Xorg 1.17 here:

https://bugzilla.redhat.com/show_bug.cgi?id=1357694

I.e. the XFixes code tries to access a cursor that has already been freed.

The code isn't obvious though, but our thinking is that a reference count is needed in CursorDisplayCursor(). Is this the right approach here?

(There's also bug 99034 and bug 18451 reported here, but they seem to be other crashes.)
Comment 1 Michel Dänzer 2017-04-28 06:17:50 UTC
*** Bug 99034 has been marked as a duplicate of this bug. ***
Comment 2 Michel Dänzer 2017-04-28 06:18:10 UTC
*** Bug 100799 has been marked as a duplicate of this bug. ***
Comment 3 Michel Dänzer 2017-04-28 07:56:50 UTC
Can somebody reproduce the problem with Xorg running in valgrind, to see where the cursor was freed?
Comment 4 Pierre Ossman 2017-04-28 08:12:39 UTC
Unfortunately not us. We got this via a customer report and have so far failed to reproduce it here. :/
Comment 5 Arie Miller 2017-04-28 14:09:32 UTC
I'm not familiar with valgrind but I can look into it this weekend.
Comment 6 Arie Miller 2017-04-30 02:22:34 UTC
So after reading a bit about valgrind I determined the relevant tool here would be callgrind to find a call to a method that releases the cursor, however running the following doesn't seem to be outputting any data to the logfile it creates called callgrind.out.<pid of xorg>.

kill <pid of xorg> && valgrind --tool=callgrind /usr/bin/Xorg

If anyone has an idea of what I should actually be looking for it would be helpful.
Comment 7 Michel Dänzer 2017-05-01 08:47:48 UTC
valgrind's default memcheck tool by default reports memory which is used after it was freed.
Comment 8 Arie Miller 2017-05-02 01:28:26 UTC
I don't believe anything was output that we didn't already know here, but here's a crash with valgrind running.

sudo valgrind /usr/bin/Xorg
==9674== Memcheck, a memory error detector
==9674== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==9674== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info
==9674== Command: /usr/bin/Xorg
==9674==

X.Org X Server 1.19.2
Release Date: 2017-03-02
X Protocol Version 11, Revision 0
Build Operating System: Linux 3.16.0-4-amd64 x86_64 Debian
Current Operating System: Linux media-server 4.9.0-2-amd64 #1 SMP Debian 4.9.18-1 (2017-03-30) x86_64
Kernel command line: BOOT_IMAGE=/vmlinuz-4.9.0-2-amd64 root=/dev/mapper/media--server--vg-root ro quiet
Build Date: 03 March 2017  03:14:41PM
xorg-server 2:1.19.2-1 (https://www.debian.org/support)
Current version of pixman: 0.34.0
        Before reporting problems, check http://wiki.x.org
        to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
        (++) from command line, (!!) notice, (II) informational,
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Mon May  1 07:12:16 2017
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
(EE)
(EE) Backtrace:
(EE) 0: /usr/lib/xorg/Xorg (xorg_backtrace+0x4a) [0x5598f330046a]
(EE) 1: /usr/lib/xorg/Xorg (0x5598f3147000+0x1bd219) [0x5598f3304219]
(EE) 2: /lib/x86_64-linux-gnu/libpthread.so.0 (0x7fa1a3bd3000+0x110c0) [0x7fa1a3be40c0]
(EE) 3: /usr/lib/xorg/Xorg (0x5598f3147000+0xe6f4f) [0x5598f322df4f]
(EE) 4: /usr/lib/xorg/Xorg (0x5598f3147000+0x545e5) [0x5598f319b5e5]
(EE) 5: /usr/lib/xorg/Xorg (0x5598f3147000+0x58568) [0x5598f319f568]
(EE) 6: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xf1) [0x7fa1a38552b1]
(EE) 7: /usr/lib/xorg/Xorg (_start+0x2a) [0x5598f318921a]
(EE)
(EE) Segmentation fault at address 0x14
(EE)
Fatal server error:
(EE) Caught signal 11 (Segmentation fault). Server aborting
(EE)
(EE)
Please consult the The X.Org Foundation support
         at http://wiki.x.org
 for help.
(EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information.
(EE)
(II) AIGLX: Suspending AIGLX clients for VT switch
(EE) Server terminated with error (1). Closing log file.
Aborted
Comment 9 Mark Mielke 2018-04-21 06:45:47 UTC
This issue matches my symptoms exactly. I found these upstream commits to address this problem:

https://cgit.freedesktop.org/xorg/xserver/commit/?id=aa6651f83c698e8cc40de61aad36c73ca7a6adcf
https://cgit.freedesktop.org/xorg/xserver/commit/?id=ceaf4277447407a7430b9bc3205462fbdbae0e39

After applying the above two changes to 1.17.2, the issue was resolved. I also noted that Adam Jackson had also applied these changes to the RHEL 7.4 xorg-x11-server package.

Confirm, but I think this issue can be closed.
Comment 10 GitLab Migration User 2018-12-13 22:37:35 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/518.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.