Use real backend for RasterDecoder fuzzing |
||
Issue descriptionWe'll likely find different bugs. Specifically, we currently have issues with memory access on texture upload with GL_PIXEL_UNPACK_BUFFER because of how we restore state in RasterDecoder. A mock GL backend like we are currently using will not pick up these issues. A real backend (angle or swiftshader) would. We already fuzz GLES2Decoder with a variety of backends (angle, swiftshader https://cs.chromium.org/chromium/src/gpu/BUILD.gn?rcl=6141b62823099c694931a7a572b977e7ccee1488&l=625), so it should be straightforward to do the same for RasterDecoder.
,
Jul 4
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/1874b89ff28b7042cff4064956f0145aac723738 commit 1874b89ff28b7042cff4064956f0145aac723738 Author: Jonathan Backer <backer@chromium.org> Date: Wed Jul 04 16:19:20 2018 Use SwiftShader and ANGLE for RasterDecoder fuzzing This will hopefully catch issues where RasterDecoder instructs the driver to make bad memory accesses (e.g. glTexImage2D with data = nullptr and GL_PIXEL_UNPACK_BUFFER set inappropriately). The current gpu_raster_fuzzer target uses a stub GL implementation and won't catch these errors. Bug: 856208 Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;luci.chromium.try:win_optional_gpu_tests_rel Change-Id: Iea7dac66ef051a82af38ca2dde3e8374187f21ba Reviewed-on: https://chromium-review.googlesource.com/1125141 Commit-Queue: Jonathan Backer <backer@chromium.org> Reviewed-by: Zhenyao Mo <zmo@chromium.org> Cr-Commit-Position: refs/heads/master@{#572600} [modify] https://crrev.com/1874b89ff28b7042cff4064956f0145aac723738/gpu/BUILD.gn
,
Jul 4
I primed the ANGLE and Swiftshader RasterDecoder fuzzers with the test cases from the existing fuzzer. Hopefully we get some interesting results. |
||
►
Sign in to add a comment |
||
Comment 1 by backer@chromium.org
, Jul 3