Not sure if we should file bugs like this one: SkASSERT() from a debug build.

caryclark@, please let me know if we shouldn't file crashes caused by SkASSERT().

Your intuition is correct, there's no need to file bugs that trigger an assert.

The asserts exist to help find bugs when the data is well-behaved. The asserts can be ignored when the data is random without harm.

If you wish to ignore the assert to look for more serious bugs, you can edit:
- SkASSERT(
+ SkOPASSERT(
This will skip the assert unless the data is marked as well-behaved.

That makes sense, thanks for quick response!

ClusterFuzz has detected this issue as fixed in range 420262:420312.

Detailed report: https://cluster-fuzz.appspot.com/testcase?key=4883311921201152

Fuzzer: libfuzzer_skia_pathop_fuzzer
Job Type: libfuzzer_chrome_asan_debug
Platform Id: linux

Crash Type: UNKNOWN
Crash Address: 0x03e900001b6c
Crash State:
  FixWinding
  SkOpBuilder::resolve
  
Fixed: https://cluster-fuzz.appspot.com/revisions?job=libfuzzer_chrome_asan_debug&range=420262:420312

Unminimized Testcase: https://cluster-fuzz.appspot.com/download/AMIfv95EDqfz0ef02grSHOnlO-D--aJVt2Ra_woz-MKZ4Eaznpc2FmH9IIjFhmRJxLsHJ4Z0UbeU5hHRAMQ1ZaYEySIG6UFPI3xAe43-tyVMAxagjwX_rMnmZWpvFNh9HTulTX5JaM8QonXUhSlmklaGk2nOdOephQ?testcase_id=4883311921201152


See https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/reproducing.md for more information.

If you suspect that the result above is incorrect, try re-doing that job on the test case report page.

It's likely that this was fixed with the edit mentioned in #2 was made to help find a different fuzzer crash. However, this may fail again in the future by triggering a newly written assert.

Removing EditIssue view restrictions from ClusterFuzz filed bugs. If you believe that this issue should still be restricted, please reapply the label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot