No issue reported for crash that was found

[alexcrichton]

It was recently discovered that the Wasmtime project's fuzzers have a fuzzer which is crashing pretty quickly locally and this has been the case for at least a few days, possibly more. The crash itself is benign and not something we're too worried about, but it's a crash that should have been found by oss-fuzz we thought.

I looked through the recent logs for this fuzzer, though, and found that the fuzzer has indeed crashed on oss-fuzz too. The public url and authenticated url at the end show:

...
	NEW_FUNC[1/1]: 0x5a05fa6cda30  (/mnt/scratch0/clusterfuzz/bot/builds/clusterfuzz-builds_wasmtime_9d7f296cb3c934976ab46f0ee760a3a07ef3344a/revisions/wasm-tools-run+0x440ea30)
#8842	NEW    cov: 118375 ft: 517427 corp: 2956/4298Kb lim: 5904 exec/s: 5 rss: 549Mb L: 3849/5904 MS: 1 CrossOver-
#8848	NEW    cov: 118377 ft: 517431 corp: 2957/4303Kb lim: 5904 exec/s: 5 rss: 549Mb L: 4430/5904 MS: 1 PersAutoDict- DE: "i64.and-associates"-
#8855	REDUCE cov: 118377 ft: 517431 corp: 2957/4303Kb lim: 5904 exec/s: 5 rss: 549Mb L: 207/5904 MS: 2 ChangeBit-EraseBytes-
thread '<unnamed>' panicked at /src/wasm-tools/fuzz/src/wit64.rs:14:47:
called `Result::unwrap()` on an `Err` value: multiple returns on a function is now a gated feature -- https://github.com/WebAssembly/component-model/pull/368 (at offset 0xc)
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
AddressSanitizer:DEADLYSIGNAL
=================================================================
==6233==ERROR: AddressSanitizer: ABRT on unknown address 0x053900001859 (pc 0x7db947d0300b bp 0x7ffc186e17f0 sp 0x7ffc186e1560 T0)
SCARINESS: 10 (signal)
    #0 0x7db947d0300b in raise /build/glibc-LcI20x/glibc-2.31/sysdeps/unix/sysv/linux/raise.c:51:1
...

which is the same crash as the issue we were seeing locally.

We were wondering if this is perhaps a transient issue which slipped through the cracks? Or is there something else going on which is preventing an issue from being filed?

[evverx]

Looks like build failures aren't reported either. While I was trying to figure out where #12465 came from and why it had never been reported I first thought that OSS-Fuzz notifications bounced (https://sourceware.org/bugzilla/show_bug.cgi?id=32155#c4) but then it turned out that the only place where the status is shown is https://oss-fuzz-build-logs.storage.googleapis.com/index.html#elfutils.

(The build failure is recent and It should have been reported on Aug 22)

[evverx]

I'm not sure if it's related but to judge from #12450 (comment) something affecting those parts of OSS-Fuzz happened on Aug 21 so that date looks suspisious.

[alexcrichton]

We got a few fuzz bugs filed on Wasmtime last night which may mean that this is resolved now

[jonathanmetzman]

@vitorguidi Could this have been caused by the buganizer migration.

[vitorguidi]

@alexcrichton 's report that crashes are happening quick locally might explain why we see a drop in that fuzzing hours number over in the oss-fuzz frontend

Crashing quicker might also lead to more testcase generation, which might be related why we are seeing a lot of datastore errors regarding contention while uploading fuzzer results.

This in turn leads to this codepath not getting reached, which is where stuff gets written to bigquery and also where our new crash count gets incremented.

[alexcrichton]

This looks like it's since been fixed, so I'm going to close this.