[Bug 95185] New: sna_driver causes X-server to get SIGSEGV
bugzilla-daemon at freedesktop.org
bugzilla-daemon at freedesktop.org
Thu Apr 28 12:22:58 UTC 2016
https://bugs.freedesktop.org/show_bug.cgi?id=95185
Bug ID: 95185
Summary: sna_driver causes X-server to get SIGSEGV
Product: xorg
Version: git
Hardware: Other
OS: All
Status: NEW
Severity: normal
Priority: medium
Component: Driver/intel
Assignee: chris at chris-wilson.co.uk
Reporter: jason.vas.dias at gmail.com
QA Contact: intel-gfx-bugs at lists.freedesktop.org
Here is a GDB stack trace of Xorg server version 1.18.3,
caused by xf86-video-intel version 2.99.917, with the patches
of Bug #95140 that allows the Xserver to start without coredumping,
gathered by setting the xorg.conf
ServerFlags 'Option "NoTrapSignals" "true"', starting up Xorg with :
$ ulimit -c unlimited
$ Xorg -logverbose 7 :0 vt04 & (sleep 1; xterm -fg white -bg black &),
and then, in the xterm , starting up DBUS & attempting to start the
Window Manager (enlightenment) with 'enlightenment_start' ; the server
gets a SIGSEGV, and hangs the machine, but upon hard poweroff & restart,
I find a core file was created - here is the stack trace & gdb output
showing the cause of the problem :
$ echo 't a a bt
up
p rq->bo
' > gdb.cmds
$ gdb -batch -x gdb.cmds $BLD/xserver/hw/xfree86/Xorg core >
gdb.stack.trace
$ cat gdb.stack.trace
[New LWP 4411]
[New LWP 4421]
[New LWP 4422]
[New LWP 4423]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib64/libthread_db.so.1".
Core was generated by `Xorg -logverbose 7 :0 vt04'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 __kgem_busy (handle=<error reading variable: Cannot access memory at
address 0x80>, kgem=0x7f5898063000) at
/usr/os_src/xorg/driver/xf86-video-intel/src/sna/kgem.c:620
620 busy.handle = handle;
[Current thread is 1 (Thread 0x7f58980fc8c0 (LWP 4411))]
Thread 4 (Thread 0x7f58903bd700 (LWP 4423)):
#0 pthread_cond_wait@@GLIBC_2.3.2 () at
../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1 0x00007f5892780761 in __run__ (arg=0x1617c40) at
/usr/os_src/xorg/driver/xf86-video-intel/src/sna/sna_threads.c:70
#2 0x00007f5896112394 in start_thread (arg=0x7f58903bd700) at
pthread_create.c:333
#3 0x00007f589640f8ed in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 3 (Thread 0x7f5890bbe700 (LWP 4422)):
#0 pthread_cond_wait@@GLIBC_2.3.2 () at
../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1 0x00007f5892780761 in __run__ (arg=0x1617bd0) at
/usr/os_src/xorg/driver/xf86-video-intel/src/sna/sna_threads.c:70
#2 0x00007f5896112394 in start_thread (arg=0x7f5890bbe700) at
pthread_create.c:333
#3 0x00007f589640f8ed in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 2 (Thread 0x7f58913bf700 (LWP 4421)):
#0 pthread_cond_wait@@GLIBC_2.3.2 () at
../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1 0x00007f5892780761 in __run__ (arg=0x1617b60) at
/usr/os_src/xorg/driver/xf86-video-intel/src/sna/sna_threads.c:70
#2 0x00007f5896112394 in start_thread (arg=0x7f58913bf700) at
pthread_create.c:333
#3 0x00007f589640f8ed in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 1 (Thread 0x7f58980fc8c0 (LWP 4411)):
#0 __kgem_busy (handle=<error reading variable: Cannot access memory at
address 0x80>, kgem=0x7f5898063000) at
/usr/os_src/xorg/driver/xf86-video-intel/src/sna/kgem.c:620
#1 kgem_commit (kgem=0x7f5898063000) at
/usr/os_src/xorg/driver/xf86-video-intel/src/sna/kgem.c:2972
#2 _kgem_submit (kgem=kgem at entry=0x7f5898063000) at
/usr/os_src/xorg/driver/xf86-video-intel/src/sna/kgem.c:3731
#3 0x00007f5892731bbd in sna_accel_wakeup_handler
(sna=sna at entry=0x7f5898063000) at
/usr/os_src/xorg/driver/xf86-video-intel/src/sna/sna_accel.c:18096
#4 0x00007f589274c4d4 in sna_wakeup_handler (arg=<optimized out>, result=0,
read_mask=0x821a40 <LastSelectMask>) at
/usr/os_src/xorg/driver/xf86-video-intel/src/sna/sna_driver.c:773
#5 0x00000000004393ba in WakeupHandler (result=result at entry=0,
pReadmask=pReadmask at entry=0x821a40 <LastSelectMask>) at
/usr/os_src/xorg/xserver/dix/dixutils.c:426
#6 0x000000000057c837 in WaitForSomething
(pClientsReady=pClientsReady at entry=0x19d1840) at
/usr/os_src/xorg/xserver/os/WaitFor.c:230
#7 0x000000000043487e in Dispatch () at
/usr/os_src/xorg/xserver/dix/dispatch.c:359
#8 0x0000000000438883 in dix_main (argc=5, argv=0x7fff2b5de638,
envp=<optimized out>) at /usr/os_src/xorg/xserver/dix/main.c:300
#9 0x00007f5896348710 in __libc_start_main (main=0x424030 <main>, argc=5,
argv=0x7fff2b5de638, init=<optimized out>, fini=<optimized out>,
rtld_fini=<optimized out>, stack_end=0x7fff2b5de628) at ../csu/libc-start.c:289
#10 0x0000000000424069 in _start () at ../sysdeps/x86_64/start.S:118
#1 kgem_commit (kgem=0x7f5898063000) at
/usr/os_src/xorg/driver/xf86-video-intel/src/sna/kgem.c:2972
2972 __kgem_busy(kgem, rq->bo->handle))
$1 = (struct kgem_bo *) 0x0
The problem here is that the 'rq->bo' parameter is NULL -
access to invalid memory addresses will cause a segmentation violation,
indicated by a SIGSEGV signal being sent to the process, which causes
it to dump core (if ulimits allow) .
Really, the xf86-video-intel driver should pay more attention to not generating
or using invalid memory addresses ! The current latest version of it cannot
start without a patch to avoid one being accessed, and cannot start the
window manager without another patch to avoid this invalid memory access.
Here is my first guess at a patch to fix:
$ diff -U0 kgem.c~ kgem.c
--- kgem.c~ 2016-04-25 23:32:41.073898879 +0000
+++ kgem.c 2016-04-28 12:20:41.006474178 +0000
@@ -2789 +2789 @@
- kgem->retire(kgem);
+ if(NULL != kgem->retire) kgem->retire(kgem);
@@ -2971 +2971,2 @@
- if (kgem->fence[rq->ring] == NULL &&
+ if ((kgem->fence[rq->ring] == NULL) &&
+ (NULL != rq) && (NULL != rq->bo) && (NULL !=
rq->bo->handle) &&
(this also shows the patch from Bug #95140 allowing Xorg to start up).
Please could the xf86-video-intel developers pay more attention to
not generating invalid memory address accesses.
--
You are receiving this mail because:
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20160428/75edc402/attachment.html>
More information about the intel-gfx-bugs
mailing list