[llvm-bugs] [Bug 49992] New: Possible incorrect position hint for persistent auto dictionary entry

via llvm-bugs llvm-bugs at lists.llvm.org
Fri Apr 16 05:19:37 PDT 2021


https://bugs.llvm.org/show_bug.cgi?id=49992

            Bug ID: 49992
           Summary: Possible incorrect position hint for persistent auto
                    dictionary entry
           Product: compiler-rt
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: fuzzer
          Assignee: unassignedbugs at nondot.org
          Reporter: meumertzheim at code-intelligence.com
                CC: llvm-bugs at lists.llvm.org

In MutationDispatcher::RecordSuccessfulMutationSequence in FuzzerMutate.cpp,
the persistent auto dictionary entries are recorded with a fixed position hint
of 1 (see
https://github.com/llvm/llvm-project/blob/1ede08a290ac70b06df6887a39c1a22ccbfcc09f/compiler-rt/lib/fuzzer/FuzzerMutate.cpp#L482).
As a result, in 50% of the cases, Mutate_AddWordFromPersistentAutoDictionary
will attempt to apply the entry right after the first byte of the input.

Using a fixed position at this point is surprising and may have resulted from a
confusion with a no longer implemented, separate success count hinted at by a
commented out line of code above (see
https://github.com/llvm/llvm-project/blob/1ede08a290ac70b06df6887a39c1a22ccbfcc09f/compiler-rt/lib/fuzzer/FuzzerMutate.cpp#L477). 

The fixed position 1 could be replaced with either DE->GetPositionHint()
(position hint copied from the entry) or std::numeric_limits<size_t>::max() (no
position hint). It remains to be determined which of these would be more
appropriate. If needed, I could try to get some data on this via fuzzbench.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20210416/36f484ea/attachment-0001.html>


More information about the llvm-bugs mailing list