Open Bug 1707001 Opened 4 years ago Updated 3 years ago

Add builds for sm-fuzzing-opt-linux32 and sm-fuzzing-debug-linux32

Categories

(Core :: JavaScript Engine, task, P3)

task

Tracking

()

ASSIGNED

People

(Reporter: jkratzer, Assigned: sfink)

References

(Depends on 1 open bug)

Details

Attachments

(1 file)

We need these builds as part of an ongoing fuzzing effort. Currently, :decoder is generating these builds locally and we would like to move them into taskcluster so that we can unify our automation process.

I spoke with :sfink and he mentioned that the 32-bit spidermonkey builds were removed to save resources. :jmaher, is this something you could help us with? These builds should be fairly light in terms of resources as these only include spidermonkey and likely won't need to run all tests.

Flags: needinfo?(jmaher)

I am happy to help review taskcluster changes and/or weigh costs of doing builds+tests based on usage. I think it is a good idea to get some automation in place for these, especially if we are manually doing this work in place of CI due to saving costs (humans cost more than machines).

I am not sure I am the best person to add build configs in place- back in our days of a larger team we could have put forth a few days to figure this out- it isn't an area I am very familiar with, so it would take some reading up and trial/error. I think :glandium might be a good resource for issues with adding builds. In the case where you are stuck, this could get in our queue probably for June timeframe (could get picked up earlier if we are blocked on other work or have spare cycles).

Flags: needinfo?(jmaher)

:jmaher, thanks. :sfink offered to write the patches to get this build included - we just wanted to get your approval on adding them before any work was started on it.

For now, I think we can just add all the builds we need (without tests). We run tests on 32-bit in other builds already and I don't expect any major breakage for the builds mentioned here that wouldn't also affect other builds.

Resource/cost-wise, adding these builds is justified. What we should check is build retention. We might not need to bisect on these builds because we can usually transform the resulting tests to work on builds that work in the regular JS shells we already have.

which branches is another consideration- I assume trunk (m-c/try at the very least) and probably beta. Call out more branches if needed.

(In reply to Joel Maher ( :jmaher ) (UTC -0800) from comment #4)

which branches is another consideration- I assume trunk (m-c/try at the very least) and probably beta. Call out more branches if needed.

autoland with the "every 10th push" saving that we already use for other builds of this type and m-c/try should be enough. Beta or other branches shouldn't be required.

Edit: For the two builds here (32-bit fuzzing), we could also skip autoland, it is rather unlikely that these would break (famous last words). For Fuzzilli (bug 1689582), we need autoland.

Would this be 32-bit versions of the existing 64-bit fuzzing build? Specifically, it uses configure flags --enable-fuzzing --enable-gczeal --enable-debug-symbols='-gline-tables-only -gdwarf-2' --disable-jemalloc --disable-stdcxx-compat --enable-address-sanitizer --enable-ctypes --enable-nspr-build --enable-rust-simd.

Summary: Add builds for sm-fuzzing-opt-linux32 and xm-fuzzing-debug-linux32 → Add builds for sm-fuzzing-opt-linux32 and sm-fuzzing-debug-linux32

(In reply to Steve Fink [:sfink] [:s:] from comment #6)

Would this be 32-bit versions of the existing 64-bit fuzzing build? Specifically, it uses configure flags --enable-fuzzing --enable-gczeal --enable-debug-symbols='-gline-tables-only -gdwarf-2' --disable-jemalloc --disable-stdcxx-compat --enable-address-sanitizer --enable-ctypes --enable-nspr-build --enable-rust-simd.

For the opt-only build, --enable-address-sanitizer is fine, but for the debug+opt build, we probably should skip that due to performance.

Also, --enable-tests is required to build fuzz-tests (useful for some targets).

I can't really comment on the ctypes/nspr/rust flags.

Btw, do you mean 64-bit fuzzing standalone sm build? I believe we use the JS shell that comes with the 64-bit fuzzing browser build, Jason can you confirm this?

Flags: needinfo?(jkratzer)

Ok, great. I'll add those jobs in and give them a try.

(In reply to Christian Holler (:decoder) from comment #7)

Btw, do you mean 64-bit fuzzing standalone sm build? I believe we use the JS shell that comes with the 64-bit fuzzing browser build, Jason can you confirm this?

Yes, I was talking about the standalone shell fuzzing build, SM(f). It uploads its binaries and everything. If it's redundant with the fuzzing browser build, we should consider removing it (or make it not build by default, or whatever.)

(In reply to Christian Holler (:decoder) from comment #7)

Btw, do you mean 64-bit fuzzing standalone sm build? I believe we use the JS shell that comes with the 64-bit fuzzing browser build, Jason can you confirm this?

Fuzzfetch[1] is configured to retrieve the JS shell included in the browser build for linux64-fuzzing-debug and linux64-fuzzing-asan-opt. There is no existing build for linux64-fuzzing-opt. With that said, we can add paths for any build that exists on TC.

(In reply to Steve Fink [:sfink] [:s:] from comment #8)

Yes, I was talking about the standalone shell fuzzing build, SM(f). It uploads its binaries and everything. If it's redundant with the fuzzing browser build, we should consider removing it (or make it not build by default, or whatever.)

If this version of the JS Shell (sm-fuzzing-linux64) is the same that's included in linux64-fuzzing-asan-opt, then yes - it appears to be redundant.

[1] https://github.com/MozillaSecurity/fuzzfetch

Flags: needinfo?(jkratzer)

I'm out of my morning meetings and I have the builds running, but the opt one is hitting an asan error in ffi_closure_inner: https://treeherder.mozilla.org/logviewer?job_id=337472220&repo=try&lineNumber=3849

There's also a testGCAllocator failure (jsapi-tests) in there. I could easily believe that ASAN would mess up that test. It ought to be skipped or something if that's the case, though. Looking...

Severity: -- → S3
Priority: -- → P3
Depends on: 1709459
Depends on: 1709461

(In reply to Christian Holler (:decoder) from comment #5)

(In reply to Joel Maher ( :jmaher ) (UTC -0800) from comment #4)

which branches is another consideration- I assume trunk (m-c/try at the very least) and probably beta. Call out more branches if needed.

autoland with the "every 10th push" saving that we already use for other builds of this type and m-c/try should be enough. Beta or other branches shouldn't be required.

I don't know how to do "every 10th push", unless it happens automatically because of changed file matching or whatever.

Assignee: nobody → sphink
Status: NEW → ASSIGNED
Assignee: nobody → sphink
Status: NEW → ASSIGNED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: