Created attachment 116022 [details] part of the trace webkitgtk browser crashes on certain pages in sse2_blt, I tested it without SSE2 support enabled in pixman (with rebuilding it), still crashes in MMX optimized function on same page, also tried to PIXMAN_DISABLE="mmx sse2 ssse3" and with that disabled, I wasn't able to crash it on the same page.
Created attachment 116023 [details] frame3_pixman_image_composite32_src_dest
Just to add, pixman version used here is 'pixman-0.32.6'
Created attachment 116027 [details] less_optimized_pixman_build Not sure if this is anything more helpful, I removed some optimizations ... from the build, I hope this gives better output also I have few of the frames disassembled if you need them I can attach those too (first few)
Based on the backtrace, it looks like pixman gets an incorrect source image. We can see that the source image pixel data is supposed to start at src_bits=0x7fff53dddd7c, it has height 19 pixels and stride 3600 bytes. Using this information, the pixel data is supposed to end at 0x7fff53dddd7c + 19 + 3600 = 0x7fff53dee8ac The crash happens when attempting to read 128-bit SSE data at 0x7fff53dedff4, which means that the page 0x7fff53dee000 is not mapped in the process address space. However it is supposed to be a part of the image (see the calculations above). So the pixman caller code is the most likely culprit. It could be the cairo library or something else futher down the call stack.
> the pixel data is supposed to end at 0x7fff53dddd7c + 19 + 3600 There was a typo here and it should read as "0x7fff53dddd7c + 19 * 3600", but this does not change anything. > also tried to PIXMAN_DISABLE="mmx sse2 ssse3" and with that disabled, > I wasn't able to crash it on the same page. Yes, pixman_blt function just returns FALSE and does nothing in this case. The caller is supposed to take a fallback path and implement this operation in some other way. Closing the issue as "not our bug" for now.
*** Bug 93964 has been marked as a duplicate of this bug. ***
Hello, I've hit a similar problem, the same backtrace but is extremely hard to reproduce. Are there any updates about this bug?
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/cairo/cairo/issues/111.
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.