Summary: | SIGSEGV in fast_composite_src_memcpy | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | xorg | Reporter: | Vinson Lee <vlee> | ||||||||||
Component: | Driver/VMWare | Assignee: | Jakob Bornecrantz <jakob> | ||||||||||
Status: | RESOLVED FIXED | QA Contact: | Xorg Project Team <xorg-team> | ||||||||||
Severity: | critical | ||||||||||||
Priority: | medium | CC: | andyrtr, brianp, jfonseca, jskier, mail, paul, soren.sandmann, sroland, thellstrom, wallbraker, zackr | ||||||||||
Version: | unspecified | Keywords: | have-backtrace, regression | ||||||||||
Hardware: | x86-64 (AMD64) | ||||||||||||
OS: | Linux (All) | ||||||||||||
Whiteboard: | |||||||||||||
i915 platform: | i915 features: | ||||||||||||
Attachments: |
|
Description
Vinson Lee
2013-03-04 08:01:45 UTC
Thanks for the bug report. Can you attach the X log file from a crashing run, please? Also, since you have gdb attached to the X server, if you can print the contents of the "image" parameter to pixman_glyph_cache_insert(). That is, something like (gdb) up <four times> (gdb) print *image that would be helpful. The source pointer given to memcpy() is __src=0xffefffff, looks very suspicious, and the instruction that crashes is one that tries to read from it, so I'm guessing that the server is passing a bogus image to pixman_glyph_cache_insert(). (gdb) frame 4 #4 0x000000306b64cc50 in pixman_glyph_cache_insert (cache=0x11e7430, font_key=font_key@entry=0x117edc0, glyph_key=glyph_key@entry=0x0, origin_x=-1, origin_y=10, image=image@entry=0x11e7200) at pixman-glyph.c:286 286 pixman_image_composite32 (PIXMAN_OP_SRC, (gdb) print *image $2 = {type = BITS, common = {type = BITS, ref_count = 1, clip_region = { extents = {x1 = 0, y1 = 0, x2 = 0, y2 = 0}, data = 0x306b681810 <pixman_region32_empty_data_>}, alpha_count = 0, have_clip_region = 0, client_clip = 0, clip_sources = 1, dirty = 0, transform = 0x0, repeat = PIXMAN_REPEAT_NONE, filter = PIXMAN_FILTER_NEAREST, filter_params = 0x0, n_filter_params = 0, alpha_map = 0x0, alpha_origin_x = -526345, alpha_origin_y = -526345, component_alpha = 0, property_changed = 0x306b6168b0 <bits_image_property_changed>, destroy_func = 0x0, destroy_data = 0x0, flags = 34032255, extended_format_code = PIXMAN_a8}, bits = {common = {type = BITS, ref_count = 1, clip_region = {extents = {x1 = 0, y1 = 0, x2 = 0, y2 = 0}, data = 0x306b681810 <pixman_region32_empty_data_>}, alpha_count = 0, have_clip_region = 0, client_clip = 0, clip_sources = 1, dirty = 0, transform = 0x0, repeat = PIXMAN_REPEAT_NONE, filter = PIXMAN_FILTER_NEAREST, filter_params = 0x0, n_filter_params = 0, alpha_map = 0x0, alpha_origin_x = -526345, alpha_origin_y = -526345, component_alpha = 0, property_changed = 0x306b6168b0 <bits_image_property_changed>, destroy_func = 0x0, destroy_data = 0x0, flags = 34032255, extended_format_code = PIXMAN_a8}, format = PIXMAN_a8, indexed = 0x0, width = 6, height = 10, bits = 0xffefffff, free_me = 0x0, rowstride = 2, fetch_scanline_32 = 0x306b60d400 <fetch_scanline_a8>, ---Type <return> to continue, or q <return> to quit--- fetch_pixel_32 = 0x306b60d480 <fetch_pixel_a8>, store_scanline_32 = 0x306b60d440 <store_scanline_a8>, fetch_scanline_float = 0x306b610130 <fetch_scanline_generic_float>, fetch_pixel_float = 0x306b6100e0 <fetch_pixel_generic_float>, store_scanline_float = 0x306b610160 <store_scanline_generic_float>, read_func = 0x0, write_func = 0x0}, gradient = {common = {type = BITS, ref_count = 1, clip_region = {extents = {x1 = 0, y1 = 0, x2 = 0, y2 = 0}, data = 0x306b681810 <pixman_region32_empty_data_>}, alpha_count = 0, have_clip_region = 0, client_clip = 0, clip_sources = 1, dirty = 0, transform = 0x0, repeat = PIXMAN_REPEAT_NONE, filter = PIXMAN_FILTER_NEAREST, filter_params = 0x0, n_filter_params = 0, alpha_map = 0x0, alpha_origin_x = -526345, alpha_origin_y = -526345, component_alpha = 0, property_changed = 0x306b6168b0 <bits_image_property_changed>, destroy_func = 0x0, destroy_data = 0x0, flags = 34032255, extended_format_code = PIXMAN_a8}, n_stops = 134316032, stops = 0x0}, linear = {common = {common = {type = BITS, ref_count = 1, clip_region = { extents = {x1 = 0, y1 = 0, x2 = 0, y2 = 0}, data = 0x306b681810 <pixman_region32_empty_data_>}, alpha_count = 0, have_clip_region = 0, client_clip = 0, clip_sources = 1, dirty = 0, transform = 0x0, repeat = PIXMAN_REPEAT_NONE, filter = PIXMAN_FILTER_NEAREST, filter_params = 0x0, n_filter_params = 0, alpha_map = 0x0, alpha_origin_x = -526345, ---Type <return> to continue, or q <return> to quit--- alpha_origin_y = -526345, component_alpha = 0, property_changed = 0x306b6168b0 <bits_image_property_changed>, destroy_func = 0x0, destroy_data = 0x0, flags = 34032255, extended_format_code = PIXMAN_a8}, n_stops = 134316032, stops = 0x0}, p1 = {x = 6, y = 10}, p2 = {x = -1048577, y = 0}}, conical = {common = { common = {type = BITS, ref_count = 1, clip_region = {extents = {x1 = 0, y1 = 0, x2 = 0, y2 = 0}, data = 0x306b681810 <pixman_region32_empty_data_>}, alpha_count = 0, have_clip_region = 0, client_clip = 0, clip_sources = 1, dirty = 0, transform = 0x0, repeat = PIXMAN_REPEAT_NONE, filter = PIXMAN_FILTER_NEAREST, filter_params = 0x0, n_filter_params = 0, alpha_map = 0x0, alpha_origin_x = -526345, alpha_origin_y = -526345, component_alpha = 0, property_changed = 0x306b6168b0 <bits_image_property_changed>, destroy_func = 0x0, destroy_data = 0x0, flags = 34032255, extended_format_code = PIXMAN_a8}, n_stops = 134316032, stops = 0x0}, center = {x = 6, y = 10}, angle = 2.121477725092553e-314}, radial = { common = {common = {type = BITS, ref_count = 1, clip_region = {extents = { x1 = 0, y1 = 0, x2 = 0, y2 = 0}, data = 0x306b681810 <pixman_region32_empty_data_>}, alpha_count = 0, have_clip_region = 0, client_clip = 0, clip_sources = 1, dirty = 0, transform = 0x0, repeat = PIXMAN_REPEAT_NONE, filter = PIXMAN_FILTER_NEAREST, filter_params = 0x0, ---Type <return> to continue, or q <return> to quit--- n_filter_params = 0, alpha_map = 0x0, alpha_origin_x = -526345, alpha_origin_y = -526345, component_alpha = 0, property_changed = 0x306b6168b0 <bits_image_property_changed>, destroy_func = 0x0, destroy_data = 0x0, flags = 34032255, extended_format_code = PIXMAN_a8}, n_stops = 134316032, stops = 0x0}, c1 = {x = 6, y = 10, radius = -1048577}, c2 = {x = 0, y = 0, radius = 0}, delta = {x = 2, y = 0, radius = 1801507840}, a = 1.0274586116403114e-312, inva = 1.0274586113241094e-312, mindr = 1.0274586681614213e-312}, solid = { common = {type = BITS, ref_count = 1, clip_region = {extents = {x1 = 0, y1 = 0, x2 = 0, y2 = 0}, data = 0x306b681810 <pixman_region32_empty_data_>}, alpha_count = 0, have_clip_region = 0, client_clip = 0, clip_sources = 1, dirty = 0, transform = 0x0, repeat = PIXMAN_REPEAT_NONE, filter = PIXMAN_FILTER_NEAREST, filter_params = 0x0, n_filter_params = 0, alpha_map = 0x0, alpha_origin_x = -526345, alpha_origin_y = -526345, component_alpha = 0, property_changed = 0x306b6168b0 <bits_image_property_changed>, destroy_func = 0x0, destroy_data = 0x0, flags = 34032255, extended_format_code = PIXMAN_a8}, color = {red = 32768, green = 2049, blue = 48, alpha = 0}, color_32 = 0, color_float = {a = 0, r = 8.40779079e-45, g = 1.40129846e-44, b = -nan(0x6fffff)}}} Created attachment 75933 [details]
Xorg.0.log
As far as I can tell, the vmware driver has created a glyph pixmap with a data pointer of 0xffefffff, which the fb layer then wrapped in a pixman image, and tried to upload to a glyph cache. The image struct: bits = {common = {type = BITS, ref_count = 1, clip_region = {extents = {x1 = 0, y1 = 0, x2 = 0, y2 = 0}, data = 0x306b681810 <pixman_region32_empty_data_>}, alpha_count = 0, have_clip_region = 0, client_clip = 0, clip_sources = 1, dirty = 0, transform = 0x0, repeat = PIXMAN_REPEAT_NONE, filter = PIXMAN_FILTER_NEAREST, filter_params = 0x0, n_filter_params = 0, alpha_map = 0x0, alpha_origin_x = -526345, alpha_origin_y = -526345, component_alpha = 0, property_changed = 0x306b6168b0 <bits_image_property_changed>, destroy_func = 0x0, destroy_data = 0x0, flags = 34032255, extended_format_code = PIXMAN_a8}, format = PIXMAN_a8, indexed = 0x0, width = 6, height = 10, bits = 0xffefffff, free_me = 0x0, rowstride = 2, ^^^^^^^^^^ looks sane apart from the 0xffefffff, so it does not appear that the image memory has been corrupted. Reassigning to the vmware driver. There was no progress here for more than a month. Is there any more information we can provide to get a fix for this? reproduced in Fedora 19 Alpha RC1 (anaconda 19.16-1) X.Org X Server 1.14.0 Linux 3.9.0-0.rc4.git0.1.fc19.x86_64 VMWare Fusion Professional Version 5.0.3 (1040386) attaching X.logs with VMWare 3D Acceleration On (3Don.txt) and Off (3Doff.txt) Created attachment 77644 [details]
X.log w/ acceleration "on"
Created attachment 77645 [details]
X.log w/ acceleration "off"
Created attachment 77785 [details] [review] proposed patch 0xffefffff is SAA_INVALID_ADDRESS saa_prepare_access_pixmap has not been called to map the pixmap before using it. Commit 9cbcb5bd6a5360a128d15b77a02d8d3351f74366 added fbGlyphs method accessing source, destination and glyphs in software. I see two ways to fix it : - wrap Glyph method like already done for some others in saa_unaccel.c saa_prepare_access_pixmap would need to be called on source, destination, and all glyphs (even if some won't be accessed since they are in pixmap cache) - call miGlyphs to restore xorg 1.13 behavior I'm not sure it's the proper way to fix the problem, but it works. I can confirm that the patch by Loïc Yhuel fixes the problem for me on ESXi and Fusion. Thanks a lot! Thanks Loïc, the patch looks good. Loïc is it okay if I push that patch to the repository with your author and signed-off-by (with the email- address listed here)? Christian Hesse, mind if add a tested-by from you (with the email-address listed here)? Cheers, Jakob. I am fine with that. Thanks a lot! Just tested this on Arch Linux, applying the patch over the latest version of xf86-video-vmware (13.0.0 + a couple of patches) and this backport works. I was getting immediate crashes, now xorg is usable. For other Arch users, PKGBUILD with the backport is avaialble at https://bitbucket.org/betafive/arch/src/dde9634b26bd/extra/xf86-video-vmware?at=master *** Bug 61630 has been marked as a duplicate of this bug. *** *** Bug 63170 has been marked as a duplicate of this bug. *** (In reply to comment #12) > Loïc is it okay if I push that patch to the repository > with your author and signed-off-by (with the email- > address listed here)? > Yes ! Thanks! Pushed the fix to the repository, going to do a release in a week or so. |
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.