Add builds for sm-fuzzing-opt-linux32 and sm-fuzzing-debug-linux32
Categories
(Core :: JavaScript Engine, task, P3)
Tracking
()
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.
Reporter | ||
Updated•4 years ago
|
Comment 1•4 years ago
|
||
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).
Reporter | ||
Comment 2•4 years ago
|
||
: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.
Comment 3•4 years ago
|
||
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.
Comment 4•4 years ago
|
||
which branches is another consideration- I assume trunk (m-c/try at the very least) and probably beta. Call out more branches if needed.
Comment 5•4 years ago
•
|
||
(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.
Assignee | ||
Comment 6•4 years ago
|
||
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
.
Assignee | ||
Updated•4 years ago
|
Comment 7•4 years ago
|
||
(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?
Assignee | ||
Comment 8•4 years ago
|
||
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.)
Reporter | ||
Comment 9•4 years ago
•
|
||
(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.
Assignee | ||
Comment 10•4 years ago
|
||
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
Assignee | ||
Comment 11•4 years ago
|
||
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...
Updated•4 years ago
|
Assignee | ||
Comment 12•3 years ago
|
||
(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 | ||
Comment 13•3 years ago
|
||
Updated•3 years ago
|
Assignee | ||
Updated•3 years ago
|
Description
•