| Summary: | Xorg crashes in VT switch | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | xorg | Reporter: | JM9 <jhnmlkvch9> | ||||||||||||
| Component: | Driver/intel | Assignee: | Chris Wilson <chris> | ||||||||||||
| Status: | RESOLVED FIXED | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||||||||||
| Severity: | critical | ||||||||||||||
| Priority: | medium | ||||||||||||||
| Version: | unspecified | ||||||||||||||
| Hardware: | x86-64 (AMD64) | ||||||||||||||
| OS: | Linux (All) | ||||||||||||||
| Whiteboard: | |||||||||||||||
| i915 platform: | i915 features: | ||||||||||||||
| Attachments: |
|
||||||||||||||
|
Description
JM9
2016-03-09 18:02:15 UTC
It is unclear since this is just a delayed memcorruption. We need to catch the error as it occurs, for which we need valgrind. Any chance you can run the Xserver undr valgrind? I can try. Do I need to build Xorg with debug symbols? Created attachment 122187 [details]
valgrind log
I've attached output of valgrind. Not sure how useful this is, as X fails to start with error Xorg.wrap permission denied
Created attachment 122188 [details]
vargrind log archive
The crash happens only when at least one intel-virtual-outputs is active. So here are the steps to reproduce the crash: 1. startx on tty1 2. run 'intel-virtual-output -fv' 3. run xrandr and make sure at least one VIRTUAL<n> outuputs is 'connected' 4. switch VT to tty2 using Ctrl-Alt-F2 5. switch back to tty1 using Ctrl-Alt-F1 6. switch to tty2 for a second time using Ctrl-Alt-F2 7. try to switch back to tty1 once again using Ctrl-Alt-F1 Step 7 will crash Xorg. I was able to run X under valgrind. Here is the log. Let me know if you want me to try and build X with -g and try. =============================================================================== ==705== Memcheck, a memory error detector ==705== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. ==705== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info ==705== Command: /usr/bin/X.bak -nolisten tcp :0 vt1 -auth /tmp/serverauth.hCDZMJjusX ==705== Parent PID: 704 ==705== --705-- --705-- Valgrind options: --705-- -v --705-- --leak-check=full --705-- --show-leak-kinds=all --705-- --error-limit=no --705-- --log-file=/var/log/Xorg-valgrind.log --705-- Contents of /proc/version: --705-- Linux version 4.4.5-1-ARCH (builduser@tobias) (gcc version 5.3.0 (GCC) ) #1 SMP PREEMPT Thu Mar 10 07:38:19 CET 2016 --705-- --705-- Arch and hwcaps: AMD64, LittleEndian, amd64-cx16-lzcnt-rdtscp-sse3-avx-avx2-bmi --705-- Page sizes: currently 4096, max supported 4096 --705-- Valgrind library directory: /usr/lib/valgrind --705-- Reading syms from /usr/bin/bash --705-- object doesn't have a symbol table --705-- Reading syms from /usr/lib/ld-2.23.so --705-- Reading syms from /usr/lib/valgrind/memcheck-amd64-linux --705-- object doesn't have a symbol table --705-- object doesn't have a dynamic symbol table --705-- Scheduler: using generic scheduler lock implementation. --705-- Reading suppressions file: /usr/lib/valgrind/default.supp ==705== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-705-by-root-on-??? ==705== embedded gdbserver: writing to /tmp/vgdb-pipe-to-vgdb-from-705-by-root-on-??? ==705== embedded gdbserver: shared mem /tmp/vgdb-pipe-shared-mem-vgdb-705-by-root-on-??? ==705== ==705== TO CONTROL THIS PROCESS USING vgdb (which you probably ==705== don't want to do, unless you know exactly what you're doing, ==705== or are doing some strange experiment): ==705== /usr/lib/valgrind/../../bin/vgdb --pid=705 ...command... ==705== ==705== TO DEBUG THIS PROCESS USING GDB: start GDB like this ==705== /path/to/gdb /usr/bin/X.bak ==705== and then give GDB the following command ==705== target remote | /usr/lib/valgrind/../../bin/vgdb --pid=705 ==705== --pid is optional if only one valgrind process is running ==705== --705-- REDIR: 0x401a970 (ld-linux-x86-64.so.2:strlen) redirected to 0x3809e1b1 (???) --705-- Reading syms from /usr/lib/valgrind/vgpreload_core-amd64-linux.so --705-- object doesn't have a symbol table --705-- Reading syms from /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so --705-- object doesn't have a symbol table ==705== WARNING: new redirection conflicts with existing -- ignoring it --705-- old: 0x0401a970 (strlen ) R-> (0000.0) 0x3809e1b1 ??? --705-- new: 0x0401a970 (strlen ) R-> (2007.0) 0x04c2dc60 strlen --705-- REDIR: 0x40192c0 (ld-linux-x86-64.so.2:index) redirected to 0x4c2d800 (index) --705-- REDIR: 0x40194e0 (ld-linux-x86-64.so.2:strcmp) redirected to 0x4c2ed10 (strcmp) --705-- Reading syms from /usr/lib/libreadline.so.6.3 --705-- Reading syms from /usr/lib/libncursesw.so.6.0 --705-- object doesn't have a symbol table --705-- Reading syms from /usr/lib/libdl-2.23.so --705-- object doesn't have a symbol table --705-- Reading syms from /usr/lib/libc-2.23.so --705-- REDIR: 0x55737e0 (libc.so.6:strcasecmp) redirected to 0x4a266be (_vgnU_ifunc_wrapper) --705-- REDIR: 0x556f160 (libc.so.6:strcspn) redirected to 0x4a266be (_vgnU_ifunc_wrapper) --705-- REDIR: 0x5575ad0 (libc.so.6:strncasecmp) redirected to 0x4a266be (_vgnU_ifunc_wrapper) --705-- REDIR: 0x55715f0 (libc.so.6:strpbrk) redirected to 0x4a266be (_vgnU_ifunc_wrapper) --705-- REDIR: 0x5571980 (libc.so.6:strspn) redirected to 0x4a266be (_vgnU_ifunc_wrapper) --705-- REDIR: 0x5572f2a (libc.so.6:memcpy@GLIBC_2.2.5) redirected to 0x4a266be (_vgnU_ifunc_wrapper) --705-- REDIR: 0x5571300 (libc.so.6:rindex) redirected to 0x4c2d4e0 (rindex) --705-- REDIR: 0x556dbf0 (libc.so.6:__GI_strcmp) redirected to 0x4c2ec20 (__GI_strcmp) --705-- REDIR: 0x556f620 (libc.so.6:strlen) redirected to 0x4c2dba0 (strlen) --705-- REDIR: 0x556fa70 (libc.so.6:__GI_strncmp) redirected to 0x4c2e350 (__GI_strncmp) --705-- REDIR: 0x556d990 (libc.so.6:__GI_strchr) redirected to 0x4c2d640 (__GI_strchr) --705-- REDIR: 0x5572640 (libc.so.6:memchr) redirected to 0x4c2edb0 (memchr) --705-- REDIR: 0x557a1a0 (libc.so.6:strchrnul) redirected to 0x4c319e0 (strchrnul) --705-- REDIR: 0x55698d0 (libc.so.6:malloc) redirected to 0x4c2ab49 (malloc) --705-- REDIR: 0x5578260 (libc.so.6:__GI_memcpy) redirected to 0x4c2f740 (__GI_memcpy) --705-- REDIR: 0x5569fe0 (libc.so.6:free) redirected to 0x4c2bc63 (free) --705-- REDIR: 0x556f040 (libc.so.6:strcpy) redirected to 0x4a266be (_vgnU_ifunc_wrapper) --705-- REDIR: 0x5585380 (libc.so.6:__strcpy_sse2_unaligned) redirected to 0x4c2dc80 (strcpy) --705-- REDIR: 0x556fa20 (libc.so.6:strncmp) redirected to 0x4a266be (_vgnU_ifunc_wrapper) --705-- REDIR: 0x560fa40 (libc.so.6:__strncmp_sse42) redirected to 0x4c2e430 (__strncmp_sse42) --705-- REDIR: 0x556dbb0 (libc.so.6:strcmp) redirected to 0x4a266be (_vgnU_ifunc_wrapper) --705-- REDIR: 0x557ef20 (libc.so.6:__strcmp_sse2_unaligned) redirected to 0x4c2ebd0 (strcmp) --705-- REDIR: 0x556f7c0 (libc.so.6:strnlen) redirected to 0x4c2db20 (strnlen) --705-- REDIR: 0x556a360 (libc.so.6:calloc) redirected to 0x4c2c8b1 (calloc) --705-- REDIR: 0x5573670 (libc.so.6:__GI_stpcpy) redirected to 0x4c30bc0 (__GI_stpcpy) --705-- REDIR: 0x5571f60 (libc.so.6:__GI_strstr) redirected to 0x4c32110 (__strstr_sse2) --705-- REDIR: 0x55729d0 (libc.so.6:__GI_memcmp) redirected to 0x4c307d0 (__GI_memcmp) --705-- REDIR: 0x5579f90 (libc.so.6:rawmemchr) redirected to 0x4c31a10 (rawmemchr) --705-- REDIR: 0x55e64f0 (libc.so.6:__strcpy_chk) redirected to 0x4c31a50 (__strcpy_chk) --705-- REDIR: 0x556d960 (libc.so.6:index) redirected to 0x4a266be (_vgnU_ifunc_wrapper) --705-- REDIR: 0x55781e0 (libc.so.6:memcpy@@GLIBC_2.14) redirected to 0x4a266be (_vgnU_ifunc_wrapper) --705-- REDIR: 0x5617e50 (libc.so.6:__memcpy_avx_unaligned) redirected to 0x4c2f0e0 (memcpy@@GLIBC_2.14) --705-- REDIR: 0x5572f90 (libc.so.6:memset) redirected to 0x4a266be (_vgnU_ifunc_wrapper) --705-- REDIR: 0x563c920 (libc.so.6:__memset_avx2) redirected to 0x4c31100 (memset) --705-- REDIR: 0x556a080 (libc.so.6:realloc) redirected to 0x4c2ca53 (realloc) trace from the journal:
======================================
systemd-coredump[7104]: Process 7036 (intel-virtual-o) of user 1000 dumped core.
Stack trace of thread 7036:
#0 0x00007f6c3f9b52a8 raise (libc.so.6)
#1 0x00007f6c3f9b672a abort (libc.so.6)
#2 0x0000000000406788 n/a (intel-virtual-output)
#3 0x00007f6c3fd6791e _XIOError (libX11.so.6)
#4 0x00007f6c3fd6537a _XReadEvents (libX11.so.6)
#5 0x00007f6c3fd54538 XNextEvent (libX11.so.6)
#6 0x00000000004049a9 n/a (intel-virtual-output)
#7 0x00007f6c3f9a2710 __libc_start_main (libc.so.6)
#8 0x0000000000406409 n/a (intel-virtual-output)
systemd-coredump[7100]: Process 5094 (Xorg) of user 1000 dumped core.
Stack trace of thread 5094:
#0 0x00007fd4619392a8 raise (libc.so.6)
#1 0x00007fd46193a72a abort (libc.so.6)
#2 0x00007fd461975369 __libc_message (libc.so.6)
#3 0x00007fd46197ad96 malloc_printerr (libc.so.6)
#4 0x00007fd46197b57e _int_free (libc.so.6)
#5 0x00007fd46197f2dd realloc (libc.so.6)
#6 0x00000000004b832e n/a (Xorg)
#7 0x00000000004b916b n/a (Xorg)
#8 0x00007fd45f32cbbf n/a (libglx.so)
#9 0x00000000004773b8 xf86VTEnter (Xorg)
#10 0x00000000004a0c47 n/a (Xorg)
#11 0x00000000004a0f4b n/a (Xorg)
#12 0x00007fd4635ce085 dbus_connection_dispatch (libdbus-1.so.3)
#13 0x00007fd4635ce3ed n/a (libdbus-1.so.3)
#14 0x000000000049a0b1 n/a (Xorg)
#15 0x000000000043ae0d WakeupHandler (Xorg)
#16 0x000000000059139f WaitForSomething (Xorg)
#17 0x000000000043609e n/a (Xorg)
#18 0x000000000043a283 n/a (Xorg)
#19 0x00007fd461926710 __libc_start_main (libc.so.6)
#20 0x0000000000424649 _start (Xorg)
Stack trace of thread 5096:
#0 0x00007fd4616f603f pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
#1 0x00007fd45c753669 n/a (intel_drv.so)
#2 0x00007fd4616f0424 start_thread (libpthread.so.0)
#3 0x00007fd4619edcbd __clone (libc.so.6)
Stack trace of thread 5095:
#0 0x00007fd4616f603f pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
#1 0x00007fd45c753669 n/a (intel_drv.so)
#2 0x00007fd4616f0424 start_thread (libpthread.so.0)
#3 0x00007fd4619edcbd __clone (libc.so.6)
Stack trace of thread 5097:
#0 0x00007fd4616f603f pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
#1 0x00007fd45c753669 n/a (intel_drv.so)
#2 0x00007fd4616f0424 start_thread (libpthread.so.0)
#3 0x00007fd4619edcbd __clone (libc.so.6)
(In reply to JM9 from comment #6) > I was able to run X under valgrind. Here is the log. Let me know if you want > me to try and build X with -g and try. This was just the startup. Hmm, maybe try valgrind --log-file=/tmp/vg-xorg.txt The coredumps are consistent with the memcorruption and are just victims of an earlier bug. (In reply to Chris Wilson from comment #8) > (In reply to JM9 from comment #6) > > I was able to run X under valgrind. Here is the log. Let me know if you want > > me to try and build X with -g and try. > > This was just the startup. Hmm, maybe try valgrind > --log-file=/tmp/vg-xorg.txt > The coredumps are consistent with the memcorruption and are just victims of > an earlier bug. So I tried to create the log in /tmp. Still no luck, it only logs the startup not the crash. So then I tried to run valgrind with --trace-children=yes This produces a full log, but when I run X under valgrind with --trace-children=yes option, I can't reproduce the crash anymore! Any idea how I should proceed? While running X under valgrind with this option seems like a workaround for the crash, I'm sure there is a penalty to running X this way all the time. At any rate, I'm attaching the latest log. I hope this contains some clue as to where to look for the problem. Let me know. Thx. Created attachment 122260 [details]
X under valgrind trace-children
log for running X as follows:
exec valgrind --trace-children=yes --log-file=/tmp/vg-xorg.txt /usr/bin/X.bak
(In reply to JM9 from comment #10) > Created attachment 122260 [details] > X under valgrind trace-children > > log for running X as follows: > > exec valgrind --trace-children=yes --log-file=/tmp/vg-xorg.txt /usr/bin/X.bak Darn, that was with xf86-video-intel not built for valgrind so valgrind doesn't understand the allocations/usage of video memory. Can you please build xf86-video-intel with ./configure --enable-debug --enable-valgrind ? Even if it does not crash with valgrind, valgrind probably detected the error. Probably. (There are a number of causes (from using the GPU) that valgrind could not and simply changing the timing would be enough.) But since this sounds i-v-o related, I expect valgrinid to catch the error. (In reply to Chris Wilson from comment #11) > (In reply to JM9 from comment #10) > > Created attachment 122260 [details] > > X under valgrind trace-children > > > > log for running X as follows: > > > > exec valgrind --trace-children=yes --log-file=/tmp/vg-xorg.txt /usr/bin/X.bak > > Darn, that was with xf86-video-intel not built for valgrind so valgrind > doesn't understand the allocations/usage of video memory. Can you please > build xf86-video-intel with ./configure --enable-debug --enable-valgrind ? > > Even if it does not crash with valgrind, valgrind probably detected the > error. Probably. (There are a number of causes (from using the GPU) that > valgrind could not and simply changing the timing would be enough.) But > since this sounds i-v-o related, I expect valgrinid to catch the error. Built with ./autogen.sh --enable-debug --enable-valgrind as suggested. Still can't reproduce crash. Log file attached. Only other thing I notice is that xbacklight won't work anymore when running under valgrind. Created attachment 122270 [details]
valgrind log
command used to produce log:
valgrind --verbose --trace-children=yes --leak-check=full --show-leak-kinds=all --error-limit=no --log-file=/tmp/vg-xorg.txt /usr/bin/X.bak
Hope this has more info. Let me know if we want to try something else.
Thx.
Yes! Almost there: ==596== Invalid free() / delete / delete[] / realloc() ==596== at 0x4C2BCEA: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==596== by 0x4C2CAB0: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==596== by 0x4B832D: ??? (in /usr/lib/xorg-server/Xorg) ==596== by 0x4B916A: ??? (in /usr/lib/xorg-server/Xorg) ==596== by 0x9527BBE: ??? (in /usr/lib/xorg/modules/extensions/libglx.xorg) ==596== by 0x4773B7: xf86VTEnter (in /usr/lib/xorg-server/Xorg) ==596== by 0x4A0C46: ??? (in /usr/lib/xorg-server/Xorg) ==596== by 0x4A0F4A: ??? (in /usr/lib/xorg-server/Xorg) ==596== by 0x4E4D084: dbus_connection_dispatch (in /usr/lib/libdbus-1.so.3.14.6) ==596== by 0x4E4D3EC: ??? (in /usr/lib/libdbus-1.so.3.14.6) ==596== by 0x49A0B0: ??? (in /usr/lib/xorg-server/Xorg) ==596== by 0x43AE0C: WakeupHandler (in /usr/lib/xorg-server/Xorg) ==596== Address 0xc6c5670 is 0 bytes inside a block of size 1,536 free'd ==596== at 0x4C2BCEA: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==596== by 0x4C2CAB0: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==596== by 0x4B832D: ??? (in /usr/lib/xorg-server/Xorg) ==596== by 0x4B916A: ??? (in /usr/lib/xorg-server/Xorg) ==596== by 0x9527BBE: ??? (in /usr/lib/xorg/modules/extensions/libglx.xorg) ==596== by 0x4773B7: xf86VTEnter (in /usr/lib/xorg-server/Xorg) ==596== by 0x4A0C46: ??? (in /usr/lib/xorg-server/Xorg) ==596== by 0x4A0F4A: ??? (in /usr/lib/xorg-server/Xorg) ==596== by 0x4E4D084: dbus_connection_dispatch (in /usr/lib/libdbus-1.so.3.14.6) ==596== by 0x4E4D3EC: ??? (in /usr/lib/libdbus-1.so.3.14.6) ==596== by 0x49A0B0: ??? (in /usr/lib/xorg-server/Xorg) ==596== by 0x43AE0C: WakeupHandler (in /usr/lib/xorg-server/Xorg) ==596== Block was alloc'd at ==596== at 0x4C2ABD0: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==596== by 0x4C2CA9E: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==596== by 0x4ADF6F: xf86CrtcCreate (in /usr/lib/xorg-server/Xorg) ==596== by 0xC0ADC18: add_fake_output (in /usr/lib/xorg/modules/drivers/intel_drv.so) ==596== by 0xC0AE010: sna_output_detect (in /usr/lib/xorg/modules/drivers/intel_drv.so) ==596== by 0x4AF444: xf86ProbeOutputModes (in /usr/lib/xorg-server/Xorg) ==596== by 0x4B8966: ??? (in /usr/lib/xorg-server/Xorg) ==596== by 0x4FA56A: RRGetInfo (in /usr/lib/xorg-server/Xorg) ==596== by 0x50329F: ??? (in /usr/lib/xorg-server/Xorg) ==596== by 0x43626E: ??? (in /usr/lib/xorg-server/Xorg) ==596== by 0x43A282: ??? (in /usr/lib/xorg-server/Xorg) ==596== by 0x69B770F: (below main) (in /usr/lib/libc-2.23.so) We just need a few more symbols. Can you install the debug symbols for the Xserver? (In reply to Chris Wilson from comment #14) > Yes! Almost there: > > We just need a few more symbols. Can you install the debug symbols for the > Xserver? (full log attached in next post) Here is the same portion with debug symbols: ==549== Invalid read of size 8 ==549== at 0x4C2F316: memcpy@@GLIBC_2.14 (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==549== by 0xC02B5CD: memcpy_blt (in /usr/lib/xorg/modules/drivers/intel_drv.so) ==549== by 0xC06F5D6: sna_composite_fb (in /usr/lib/xorg/modules/drivers/intel_drv.so) ==549== by 0xC06F91E: sna_composite (in /usr/lib/xorg/modules/drivers/intel_drv.so) ==549== by 0x5185E0: damageComposite (damage.c:503) ==549== by 0x50DFF6: ProcRenderComposite (render.c:708) ==549== by 0x4361BE: Dispatch (dispatch.c:430) ==549== by 0x43A1D2: dix_main (main.c:300) ==549== by 0x69B770F: (below main) (in /usr/lib/libc-2.23.so) ==549== Address 0x7fa6b36a4010 is not stack'd, malloc'd or (recently) free'd ==549== ==549== Invalid free() / delete / delete[] / realloc() ==549== at 0x4C2BCEA: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==549== by 0x4C2CAB0: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==549== by 0x4B413D: xf86RandR12CrtcSetGamma (xf86RandR12.c:1253) ==549== by 0x4B4F7A: xf86RandR12EnterVT (xf86RandR12.c:1814) ==549== by 0x9527BBE: glxDRIEnterVT (glxdri2.c:815) ==549== by 0x477377: xf86VTEnter (xf86Events.c:570) ==549== by 0x49CA06: systemd_logind_vtenter (systemd-logind.c:255) ==549== by 0x49CD0A: message_filter (systemd-logind.c:427) ==549== by 0x4E4D084: dbus_connection_dispatch (in /usr/lib/libdbus-1.so.3.14.6) ==549== by 0x4E4D3EC: ??? (in /usr/lib/libdbus-1.so.3.14.6) ==549== by 0x496400: wakeup_handler (dbus-core.c:57) ==549== by 0x43AD5C: WakeupHandler (dixutils.c:423) ==549== Address 0x116b82e0 is 0 bytes inside a block of size 1,536 free'd ==549== at 0x4C2BCEA: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==549== by 0x4C2CAB0: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==549== by 0x4B413D: xf86RandR12CrtcSetGamma (xf86RandR12.c:1253) ==549== by 0x4B4F7A: xf86RandR12EnterVT (xf86RandR12.c:1814) ==549== by 0x9527BBE: glxDRIEnterVT (glxdri2.c:815) ==549== by 0x477377: xf86VTEnter (xf86Events.c:570) ==549== by 0x49CA06: systemd_logind_vtenter (systemd-logind.c:255) ==549== by 0x49CD0A: message_filter (systemd-logind.c:427) ==549== by 0x4E4D084: dbus_connection_dispatch (in /usr/lib/libdbus-1.so.3.14.6) ==549== by 0x4E4D3EC: ??? (in /usr/lib/libdbus-1.so.3.14.6) ==549== by 0x496400: wakeup_handler (dbus-core.c:57) ==549== by 0x43AD5C: WakeupHandler (dixutils.c:423) ==549== Block was alloc'd at ==549== at 0x4C2ABD0: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==549== by 0x4C2CA9E: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==549== by 0x4A9D3F: xf86CrtcCreate (xf86Crtc.c:121) ==549== by 0xC0818A8: add_fake_output (in /usr/lib/xorg/modules/drivers/intel_drv.so) ==549== by 0xC081C50: sna_output_detect (in /usr/lib/xorg/modules/drivers/intel_drv.so) ==549== by 0x4AB214: xf86ProbeOutputModes (xf86Crtc.c:1637) ==549== by 0x4B4776: xf86RandR12GetInfo12 (xf86RandR12.c:1511) ==549== by 0x4F642A: RRGetInfo (rrinfo.c:196) ==549== by 0x4FF18F: rrGetScreenResources (rrscreen.c:500) ==549== by 0x4361BE: Dispatch (dispatch.c:430) ==549== by 0x43A1D2: dix_main (main.c:300) ==549== by 0x69B770F: (below main) (in /usr/lib/libc-2.23.so) ==549== Created attachment 122271 [details]
valgrind with Xorg and intel debug symbols
valgrind log with Xserver debug symbols as requested.
Thank you very much for reporting the bug and the all debugging work! commit ba85e22c14ed243826d3edf35dd3813d23708d89 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Mon Mar 14 08:26:54 2016 +0000 sna: When creating CRTC after initialisation, manually create the RR gamma RRCrtcCreate does not automatically inherit the gamma ramp, but we must call RRCrtcGammaGet ourselves instead. Otherwise the ramp is left as 0 and this will then overwrite our gamma on VT switch (as for whatever reason it is reapplied). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94465 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> |
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.