Umbrella issue: Projects failing #30
Comments
|
@Navidem I just tried nss and it killed my machine - most likely due to some resource exhaustion but am yet to isolate whether it's due to LTO or fuzz-introspector, or something third |
|
@DavidKorczynski thanks for checking. I can say without LTO it finishes successfully within ~7 min on my side. |
I too compile it fine with |
|
I can now build NSS with fuzz-introspector: The issue is that NSS uses a lot of processes during compilation and each of these also uses a lot of memory. This can be solved by changing this line https://hg.mozilla.org/projects/nss/file/tip/build.sh#l276 from I will explore if we can use some constraints on the Docker environment, e.g. https://docs.docker.com/config/containers/resource_constraints/#cpu This should work in a general way. |
|
@Navidem Let's create sub bugs and track them here for the ones you notice too! |
|
|
|
Division by zero in
Sample output for Sample output for |
|
The following projects fail to parse/merge profile because of encoding issues:
Sample output for |
|
|
Kamailio should be fixed with 554ae74 have run locally where I verified the issue and also verified post-fix that it works now |
This issue seem to have happened because these lines in the OSS-Fuzz integration: The problem is those I fixed this by adding a UUID to the fuzzer log files now: 4231c27 and I have verified that both croaring and nettle works now. As such, it shouldn't really happen now, but, the two lines I link to in the OSS-Fuzz integration should probably change considering fuzz introspector does not guarantee uniqueness (it almost does not) in output files. Fuzz introspector output files does guarantee {path, filename} to be unique though. |
|
The following projects are failing with configure error
A quick search shows people recommending use of |
|
I added a small script to automate testing projects of oss-fuzz projects here https://github.com/ossf/fuzz-introspector/blob/main/oss_fuzz_integration/test_projects.sh |
|
I did an investigation and extracted projects that are failing to link/build fuzzers and excluded those that are also failing with coverage build. Furthermore, I filtered those that fail when we only enable lto. These were projects that fail once These are the project that we may give lower priority to debug. |
Do you mean here it's specifically to compiler pass or do some of these projects fail in the post-processing? |
|
|
|
Ref #4 |
|
Are we sure that all of these projects are related to fuzz-introspector? I am asking this because I debugged an issue over here #48 (comment) where it seems that the issue only happens when compiling with One of the potential issues is that We should check if projects fail with these set, or, more specifically, if projects fail with I recon it would be nice to have some infrastructure to make it easy to isolate whether a given issue happens because of the fuzz-introspector llvm pass or e.g. the fact that we force use of I am currently looking at |
|
cleared v1 milestone, as the debugging remaining failures has to continue afterwards. |
Umbrella issue for projects failing.
Compilation problemproblem identified and fix is coming up. The problem was resource exhaustion, we simply need to limit resources in the Docker container.The text was updated successfully, but these errors were encountered: