Summary: | [IVB/HSW/BYT/BDW Bisected]Show backtrace when running Synmark2 v6.0 OglTexMem512 | ||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | xorg | Reporter: | zhoujian <jianx.zhou> | ||||||||||||||||||||||
Component: | Server/Ext/DRI | Assignee: | Xorg Project Team <xorg-team> | ||||||||||||||||||||||
Status: | VERIFIED FIXED | QA Contact: | Xorg Project Team <xorg-team> | ||||||||||||||||||||||
Severity: | major | ||||||||||||||||||||||||
Priority: | high | CC: | eero.t.tamminen, lilix.cheng, wendy.wang, zhipengx.zheng | ||||||||||||||||||||||
Version: | git | ||||||||||||||||||||||||
Hardware: | All | ||||||||||||||||||||||||
OS: | Linux (All) | ||||||||||||||||||||||||
URL: | http://patchwork.freedesktop.org/patch/26722/ | ||||||||||||||||||||||||
Whiteboard: | |||||||||||||||||||||||||
i915 platform: | i915 features: | ||||||||||||||||||||||||
Attachments: |
|
Description
zhoujian
2014-07-11 08:41:13 UTC
Created attachment 102602 [details]
Xorg.0.log
Created attachment 102603 [details]
dmesg.log
Use gdb and grab the symbolic bt for the crash. (In reply to comment #3) > Use gdb and grab the symbolic bt for the crash. Zhoujian, if you haven't done this before, this requires: - preferably not stripping debug symbols from X server when installing it (don't use "strip" command or "-s" argument for "install" command) - after starting X, attaching to it with Gdb from ssh console (display server issues need to be debugged from another machine): gdb <your X binary> $(pidof X) - typing "cont" in Gdb to continue X running - running the test case under X until X crashes - in the Gdb prompt after X crash: - typing "bt" command to get backtrace, - following with few "up" and "info locals" commands (type "info locals" after every "up" command) (In reply to comment #4) It's very clear, thanks. The gdb debug info is attached. Created attachment 102647 [details]
gdb debug log
Drawing to a corrupt pixmap, probably a use-after-free. You could try compiling -intel with --enable-debug or --enable-debug=full to see if that makes the root cause of the bug more obvious. Created attachment 102733 [details]
gdb_log.txt
Have compiling Xserver with --enable-debug,the gdb log info you may see gdb_log.txt By Xserver, did you mean xf86-video-intel? That bt just indicates a corrupt pixmap (probably use-after-free). Sorry,maybe i mistake, now i have try compiling xf86-video-intel with --enable-debug,debug log you may see "gdb_log_1.txt" Created attachment 102743 [details]
gdb_log_1.txt
And now you really do have to grab the debug log, i.e. compile xf86-video-intel with --enable-debug=full Created attachment 102807 [details]
gdb_log_2.txt
compile xf86-video-intel with --enable-debug=full have finished,debug log you may see gdb_log_2.txt. Can you compress the Xorg.0.log and attach it? Created attachment 102818 [details]
latest_Xorg.0.zip
Ok,you may see latest_Xorg.0.zip Created attachment 102820 [details]
latest_Xorg.0.zip
There doesn't look like there is anything wrong in that logfile. The driver basically sees the same sequence of events over and over again. Only it spontaneously explodes. The danger point would seem to be the pixmap cycling in the higher layers. When I run OglTexMem512 in a bare X session, I don't see the same sequence of flip/unflip/copy. In particular, you have a pair of terminal abort_vblank. I wonder if you have a compositing wm using Present as well. When I try to run synmark2 under gnome-shell, it just complains of inaccurate rendering. Have you tried bare X? (I don't think your xinit is bare enough.) As I still haven't seen this locally, another little task I can ask if you could perform: run X under valgrind, reproduce the issue and attach the output from valgrind. Okay,finished the collect output log from valgrind,you may see valgrind_log.log used command: valgrind --tool=memcheck --leak-check=yes --show-reachable=yes ./synmark2 OglTexMem512 Created attachment 103166 [details]
valgrind_log.log
Close! But I needed to have X run under valgrind to try and catch details of the crash. Please can you repeat that experiment, but using $ valgrind --log-file=x.txt Xorg -ac -noreset & $ ./synmark2 OglTexMem512 Created attachment 103265 [details]
valgrind-hsw.txt
Okay,follow above the way,detail log info you may see valgrind-hsw.txt. ==8677== Invalid read of size 8 ==8677== at 0x5204E3: present_destroy_window (present_screen.c:93) ==8677== by 0x4D9C70: compDestroyWindow (compwindow.c:608) ==8677== by 0x4FBE11: DbeDestroyWindow (dbe.c:1318) ==8677== by 0x4623D6: FreeWindowResources (window.c:910) ==8677== by 0x464F97: DeleteWindow (window.c:978) ==8677== by 0x45B2D1: doFreeResource (resource.c:873) ==8677== by 0x45BD92: FreeResource (resource.c:903) ==8677== by 0x433FE6: ProcDestroyWindow (dispatch.c:719) ==8677== by 0x439186: Dispatch (dispatch.c:432) ==8677== by 0x43CF49: dix_main (main.c:296) ==8677== by 0x7197DE4: (below main) (libc-start.c:260) ==8677== Address 0xea82eb8 is 40 bytes inside a block of size 168 free'd ==8677== at 0x4C2B60C: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==8677== by 0x5204A2: present_destroy_window (present_screen.c:79) ==8677== by 0x4D9C70: compDestroyWindow (compwindow.c:608) ==8677== by 0x4FBE11: DbeDestroyWindow (dbe.c:1318) ==8677== by 0x4623D6: FreeWindowResources (window.c:910) ==8677== by 0x464F97: DeleteWindow (window.c:978) ==8677== by 0x45B2D1: doFreeResource (resource.c:873) ==8677== by 0x45BD92: FreeResource (resource.c:903) ==8677== by 0x433FE6: ProcDestroyWindow (dispatch.c:719) ==8677== by 0x439186: Dispatch (dispatch.c:432) ==8677== by 0x43CF49: dix_main (main.c:296) ==8677== by 0x7197DE4: (below main) (libc-start.c:260) which is one of the bugs I reported to Keith earlier. I believe the fix is http://patchwork.freedesktop.org/patch/26722/ (In reply to Chris Wilson from comment #29) > I believe the fix is http://patchwork.freedesktop.org/patch/26722/ Is this fix merged already? Zhoujian, is this issue still reproducible? (In reply to Eero Tamminen from comment #30) > (In reply to Chris Wilson from comment #29) > > I believe the fix is http://patchwork.freedesktop.org/patch/26722/ > > Is this fix merged already? > > > Zhoujian, is this issue still reproducible? Will reproduce and update after vacation, back on Jan. 4 2015 Cannot reproduce this issue on HSW/BYT using 2014-12-29 whole GFX SW stack, so close this bug as fixed. Libdrm: (master)libdrm-2.4.58-19-gf99522e678dbbaffeca9462a8edcbe900574dc12 Mesa: (master)0c7f8959957e5b6eec2dcb5816c0c0a58e66ef77 Xserver: (master)xorg-server-1.16.99.901-118-gdc777c346d5d452a53b13b917c45f6a1bad2f20b Xf86_video_intel: (master)2.99.917-1-g0d42b0ed25d4112e0b3e3218e5c42947bbeb9e27 Cairo: (master)8e11a42e3e9b679dce97ac45cd8b47322536a253 Libva: (master)e97ac9e78cd475a13e722c455e34d5d39d0f059d Libva_intel_driver: (master)94cff41032e7e1e6719d9bc51719c2b7783314ae Kernel: (drm-intel-nightly)4fa23142a15526f4a4b5df61f26eacdd558a849a |
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.