Created attachment 54157 [details] dmesg Hello, the latest libdrm-git with last commit e4b60f29609e9993dc7268993da509530862aa78 causes mplayer-vaapi to quit with: mplayer: /tmp/portage/x11-libs/libdrm-9999/work/libdrm-9999/intel/intel_bufmgr_gem.c:1232: drm_intel_gem_bo_unmap: Assertion `bo_gem->map_count > 0' failed. OpenGL Applications crash with: *** glibc detected *** /home/source/doom/Debug/doom: double free or corruption (out): 0x0000000000add890 *** ======= Backtrace: ========= /lib/libc.so.6(+0x76696)[0x7ffff650e696] /lib/libc.so.6(cfree+0x6c)[0x7ffff651351c] /usr/lib64/dri/i965_dri.so(+0x4ade0)[0x7ffff2cc7de0] /usr/lib64/dri/i965_dri.so(+0x134f72)[0x7ffff2db1f72] /usr/lib64/dri/i965_dri.so(+0x13520c)[0x7ffff2db220c] /usr/lib64/dri/i965_dri.so(+0x135c78)[0x7ffff2db2c78] /home/source/doom/Debug/doom[0x40ae94] .... /lib/libc.so.6(__libc_start_main+0xfd)[0x7ffff64ba22d] /home/source/doom/Debug/doom[0x404f79] ======= Memory map: ======== 00400000-0048d000 r-xp 00000000 08:06 916284 /home/source/doom/Debug/doom 0068c000-0068d000 r--p 0008c000 08:06 916284 /home/source/doom/Debug/doom 0068d000-0069c000 rw-p 0008d000 08:06 916284 /home/source/doom/Debug/doom 0069c000-012b7000 rw-p 00000000 00:00 0 [heap] 7fffe4000000-7fffe4021000 rw-p 00000000 00:00 0 7fffe4021000-7fffe8000000 ---p 00000000 00:00 0 7fffea603000-7fffea61b000 rw-s 1095b8000 00:0f 4245 /dev/dri/card0 7fffea61b000-7fffea633000 rw-s 1095a0000 00:0f 4245 /dev/dri/card0 All libva, mesa and xf86-video-intel are latest pulls from git (as of dec. 6th). Kernel is 3.2-next-20111206. Regards, Nic
Created attachment 54158 [details] xorg.log
What was the mplayer command line used? (Presuming the bug is generic and will be hit by any decoder.)
Can you try this patch to vaapi/intel_driver: diff --git a/src/i965_render.c b/src/i965_render.c index ad8de1e..29d7367 100644 --- a/src/i965_render.c +++ b/src/i965_render.c @@ -2069,7 +2069,6 @@ gen6_subpicture_render_blend_state(VADriverContextP ctx) struct i965_render_state *render_state = &i965->render_state; struct gen6_blend_state *blend_state; - dri_bo_unmap(render_state->cc.state); dri_bo_map(render_state->cc.blend, 1); assert(render_state->cc.blend->virtual); blend_state = render_state->cc.blend->virtual; @@ -2834,7 +2833,6 @@ gen7_subpicture_render_blend_state(VADriverContextP ctx) struct i965_render_state *render_state = &i965->render_state; struct gen6_blend_state *blend_state; - dri_bo_unmap(render_state->cc.state); dri_bo_map(render_state->cc.blend, 1); assert(render_state->cc.blend->virtual); blend_state = render_state->cc.blend->virtual;
The only other instance I could see for a potential unbalanced map/unmap in vaapi was for i965_MapBuffer/i965_UnmapBuffer which pass the user calls to libdrm. I'm not sure if multiple mapping are supported or handled in the higher layers.
There are pre-existing memory corruption with Doom, can you please check with libdrm HEAD^ (and HEAD^^) to check if that is libdrm related?
Hi Chris, it is most certainly libdrm related. After downgrading to libdrm 2.4.27 mplayer and the game are running fine. I wasn't able to test 2.4.28 since it is not in the gentoo portage tree yet and I can only choose between 2.4.27 and git-head via portage overlay. Your vaapi patch keeps mplayer from dying. mplayer (SVN-r34180) command looks like this: mplayer -va vaapi -vo vaapi -cache 8192 SomeMKVFile.mkv The issue with the OpenGL game is most certainly libdrm related too. I've checked the game code - there is no double free and it runs fine with libdrm 2.4.27. Funny thing is since your latest libdrm commit (2011-12-06 21:45:55 (GMT)) the OpenGL game seems to run smooth with libdrm-git. Without your libva intel-drvier patch however mplayer still craps out. Regards, Nic
(Related report according to Chris on IRC: http://bugs.debian.org/651316)
The asserts are no more, however if doom continues to plague you, can you added some information to bug 43037.
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.