autobisect does not seem to work with SpiderMonkey js binaries

[nth10sd]

$ python -u -m autobisect js -d testcase.js
[2023-12-19 11:04:56] Begin bisection...
[2023-12-19 11:04:56] > Start: 07ec95b9d14c0ab9d2ba6f5cdc5d6efa3e4e0270 (20221220093956)
[2023-12-19 11:04:56] > End: 3fd71c45d9fc05e5912ec6c9ba191a9a3a7f2038 (20231219152636)
[2023-12-19 11:04:56] Attempting to verify boundaries...
[2023-12-19 11:04:56] Testing build 07ec95b9d14c0ab9d2ba6f5cdc5d6efa3e4e0270 (20221220093956)
[2023-12-19 11:04:56] Unable to launch the start build!
[2023-12-19 11:04:56] Bisection failed!
[2023-12-19 11:04:56] Bisection completed in: 0:00:00

Tested on autobisect 7.4.3

[pyoor]

This is because the build you've requested doesn't actually exist. You'll need to specify -d --fuzzing. The error message here is certainly unclear though. I'll see if I can't make it more obvious what's actually going wrong.

Thanks for the report @nth10sd!

[pyoor]

Actually, I spoke too soon. The real issue here is that we now only store 3 months of JS builds. If you don't specify a start build. autobisect looks for the oldest available build which it thinks is a year old.

[pyoor]

This is actually a problem with Fuzzfetch. We have the ability to find the nearest available task but it doesn't check to see if the target we need actually exists in that task.

[nth10sd]

The real issue here is that we now only store 3 months of JS builds.

Can't we switch to Mozilla FTP builds for js shells? They go way back probably at least a decade...

[pyoor]

We cannot. Autobisect and bugmon are intended to support bugs found via fuzzing and must be a reflection of the builds we use. Those builds all come from Taskcluster and the Mozilla FTP server lack builds with the same configuration (ASan, limited debug and fuzzing enabled builds). If these builds work for you, you're better off using mozregression.

[nth10sd]

Sure! Right tool for the right job I guess...

[pyoor]

This was fixed in MozillaSecurity/fuzzfetch#133.