Created attachment 67464 [details] screenshot When moving table in Shareaza with wine I get a screen-corruption on my gen6 based notebook with SNA enabled using 2.20.8. Steps to reproduce: - Download Shareaza for windows - Install wine - Install Shareaza using wine - Start Shareaza - Open a tab, click on a table header and start moving the table header A debug=full log is available at: http://93.83.133.214/Xorg.1.log.7za Backtrace of assertion hit (corruption however, happend way before the assertion was triggered): #0 0x00000034f2635925 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x00000034f26370d8 in __GI_abort () at abort.c:91 #2 0x00000034f262e6a2 in __assert_fail_base (fmt=0x34f2778188 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x7f1a744fc3f5 "0", file=file@entry=0x7f1a744fc58e "sna_accel.c", line=line@entry=232, function=function@entry=0x7f1a74502930 "_assert_pixmap_contains_box") at assert.c:94 #3 0x00000034f262e752 in __GI___assert_fail (assertion=0x7f1a744fc3f5 "0", file=0x7f1a744fc58e "sna_accel.c", line=232, function=0x7f1a74502930 "_assert_pixmap_contains_box") at assert.c:103 #4 0x00007f1a743e7213 in _assert_pixmap_contains_box (pixmap=0x2216810, box=0x7fff2681d620, function=0x7f1a745024b0 "sna_pixmap_move_area_to_gpu") at sna_accel.c:232 #5 0x00007f1a743ed288 in sna_pixmap_move_area_to_gpu (pixmap=0x2216810, box=0x7fff2681d620, flags=3) at sna_accel.c:2364 #6 0x00007f1a743ee6d3 in sna_drawable_use_bo (drawable=0x23824c0, flags=7, box=0x7fff2681d6d0, damage=0x7fff2681d880) at sna_accel.c:2766 #7 0x00007f1a744a1d9d in gen6_composite_set_target (sna=0x7f1a74326010, op=0x7fff2681d860, dst=0x2391ae0, x=0, y=0, w=0, h=0) at gen6_render.c:2341 #8 0x00007f1a744a2c24 in gen6_render_composite (sna=0x7f1a74326010, op=3 '\003', src=0x23bc240, mask=0x1f32440, dst=0x2391ae0, src_x=0, src_y=0, msk_x=0, msk_y=0, dst_x=0, dst_y=0, width=0, height=0, tmp=0x7fff2681d860) at gen6_render.c:2691 #9 0x00007f1a74435f10 in glyphs_to_dst (sna=0x7f1a74326010, op=3 '\003', src=0x23bc240, dst=0x2391ae0, src_x=152, src_y=-435, nlist=48, list=0x7fff2681dc50, glyphs=0x7fff2681e058) at sna_glyphs.c:552 #10 0x00007f1a74438fd4 in sna_glyphs (op=3 '\003', src=0x23bc240, dst=0x2391ae0, mask=0x1f051b8, src_x=0, src_y=0, nlist=49, list=0x7fff2681dc50, glyphs=0x7fff2681e050) at sna_glyphs.c:1673 #11 0x000000000050239d in ?? () #12 0x00000000004fb586 in ?? () #13 0x000000000043444a in ?? () #14 0x0000000000423485 in ?? () #15 0x00000034f2621735 in __libc_start_main (main=0x423110, argc=8, ubp_av=0x7fff2681ea48, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fff2681ea38) at libc-start.c:226 #16 0x000000000042375d in _start ()
Created attachment 67465 [details] screenshot (with mimetype set correctly)
The assertion is relatively easy, and valid: commit d853064e7eebc5719645c12605782f995131a6fe Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu Sep 20 22:43:26 2012 +0100 sna/gen3+: Trim the target extents to the CompositeClip When computing the active region with of a composite operation with unknown extents we try to simply use the whole Drawable. However, this needs to be clipped otherwise it may trigger assertion failure with an offscreen pixmap. References: https://bugs.freedesktop.org/show_bug.cgi?id=55164 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Is Shareaza the easiest reproducer?... I guess I have nothing to do but read the full log. :|
Thanks for the fix, unfourtunatly the corruption issue does still exist. So far I've only seen this behaviour with Shareaza, however it can be easily reproduced on my system (wine-1.5.11): http://youtu.be/009UN1EU2ks
Hmm, what about if you ran Shareaza under a bare X? (Or a wm like fvwm?) Just having a little difficultly getting Shareaza to install under wine atm (keeps suggesting the installation is broken, how rude!).
I've zipped the folder I had it installed, at least on my system it starts even after I'd deleted ~/.wine: http://93.83.133.214/Shareaza.7za I'll try with another WM soon.
Reproduceable also with icewm, composition manager on/off doesn't make a difference. Forgot to mention that I can also reproduce it on my other gen5 based laptop.
I can reproduce the issue using that bundle, but only on a snb so far. It's a starting point, so many thanks.
Unbelievably, this is actually a bug in Wine. It is abusing a PICT_x8r8g8b8 format by trying to copy a PICT_a8r8g8b8 picture through an alphaless temporary and expecting the alpha-channel to be preserved. The second bug is that the coordinates/size of that temporary drawable are wrong - far greater than the apparently intended area of the columns to be redrawn. If I disable the shortcut to use the blit path for xrgb->argb copy, then I can reproduce the same errors in UXA. Vice versa, if I prefer the blit path, then the problem is masked in SNA.
Thanks for your investigation - I'll file a bug at the wine bugtracker. Because it worked with UXA I concluded there's something wrong with SNA, not that UXA accidentially hides wine bugs ;)
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.