md4c: Discrepancy between issues and crash stats.

[mity]

Project MD4C has one open problematic issue, namely https://oss-fuzz.com/testcase-detail/5609076764573696. It's not a crash but timeout, and it's marked as flaky. Even though I believe this bug is fixed for a long time, whenever any new (and unrelated) timeout issue gets detected, this issue behaves as a bucket of sorts and gets re-opened, even for fully reproducible testcases.

I understand this may be due technical limitations in classification of timeout issues (even though I'd wish that reproducible timeouts would not be bucketed with an issue marked as flaky) and at least in the past oss-fuzz interface allowed me to see the other/newer testcases grouped into this one by clicking on an icon in the list of all opened testcases and access the fresher ones that way.

However at this time the issue truly puzzles me: The group icon for accessing other test-cases bucketed into the same issue is not there and the report itself still declares it was last reproduced with the MD4C commit c058e82c6a939f591059672dab08ddd0d4ce416e which is roughly 2 years old.

Yet at the same time statistics of the issue indicates that some reproduction rate is still there.

This metadata inconsistency makes me wondering whether the testcase 5609076764573696 itself reproduces (and the info about commit is wrong and stale); or whether there are some new testcases which were added into the group but are not somehow accessible in the interface for some reason.

Can you please check what's going on?

[mity]

Update: Seems I was able to dig the test cases at last. However it's not intuitive at all:

1. Had to iterate manually over the individual fuzzer engines links "FUZZER STAT/COVERAGE" at https://oss-fuzz.com main page

2. until I eventually ended at the page: https://oss-fuzz.com/fuzzer-stats?project=md4c&fuzzer=libFuzzer_md4c_fuzz-mdhtml&job=libfuzzer_ubsan_md4c&group_by=by-day

3. Then had to go via link "logs" which landed me at https://console.cloud.google.com/storage/browser/md4c-logs.clusterfuzz-external.appspot.com/libFuzzer_md4c_fuzz-mdhtml/libfuzzer_ubsan_md4c/2024-01-31;tab=objects?prefix=&forceOnObjectsSortingFiltering=false&authuser=1

4. where among the log files are also some hidden test cases.

Nevertheless I keep this issue open because:

• I think oss-fuzz should open new issue for such finding rather than an old issue with a test case which cannot be reproduced with anything newer than 2 years old version of the project.

• Especially given the old issue is marked as flaky while the new well-hidden test cases seem to be 100 % reproducible (timeouts caused by O(n^2) time behavior of one sub-algorithm the new test cases hit).

• And even if oss-fuzz decides to merge the test cases into one issue, the new test cases reproducible on fresh project version should be at least as accessible as the 2 years old stale test case report which cannot.