[llvm] r271139 - [llvm-readobj] Validate the string table offset before using it

David Blaikie via llvm-commits llvm-commits at lists.llvm.org
Tue May 31 12:49:44 PDT 2016


On Tue, May 31, 2016 at 11:50 AM, Kostya Serebryany <kcc at google.com> wrote:

>
>
> On Sun, May 29, 2016 at 2:25 PM, David Blaikie via llvm-commits <
> llvm-commits at lists.llvm.org> wrote:
>
>>
>>
>> On Sun, May 29, 2016 at 10:09 AM, David Majnemer <
>> david.majnemer at gmail.com> wrote:
>>
>>> Not really, I have no way to reduce the test down to something
>>> reasonable.  I'd rather not see the LLVM repo become a collection of large,
>>> malformed PDB files.
>>>
>>
>> Other ideas for how we ensure we don't regress the functionality you're
>> adding? Sounds like this sort of idea is what Kostya has in mind for
>> libFuzzer use - a corpus of interesting inputs that grows when bugs are
>> fixed so the corpus can be run directly for regression testing, and used as
>> input to the fuzzer for bug finding. Perhaps we need to formalize something
>> like that for this sort of work?
>>
>
> If someone creates a fuzz target code (similar to e.g.
> tools/clang/tools/clang-fuzzer/ClangFuzzer.cpp) it will be straightforward
> to add such a fuzzer to the fuzzing bot
> <http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fuzzer/builds/9533>
> .
>

Is there any way we could also be able to run the existing corpus as part
of the more common build 'check' workflow? Without that it's likely to be a
bit niche.


> The only question is whether someone will care to fix the bugs -- clang
> and clang-format fuzzers are red for many months.
>

Well, it seems like Dave's interested in fixing the fuzz failures in
pdbdump, so perhaps he'll actually get such a thing green?

(in any case, making the thing green is the tricky part - once you're
there, keeping it that way is relatively low cost (I spent 3 months making
the GDB bot green, for example - and that was just triage/blacklisting the
failures - to fix them all? We never did). Perhaps there's some way to
grandfather in known/existing failures identified by stack trace or the
like, then try to just avoid getting more failures? (once it's green, then
green->red transitions will be noticed by developers and if they're
actionable, good chance we can get them fixed))

- Dave


>
> --kcc
>
>
>
>>
>>
>>>
>>> On Sun, May 29, 2016 at 9:25 AM, David Blaikie <dblaikie at gmail.com>
>>> wrote:
>>>
>>>> any chance of test cases for all this error handling being added?
>>>>
>>>> On Sat, May 28, 2016 at 12:45 PM, David Majnemer via llvm-commits <
>>>> llvm-commits at lists.llvm.org> wrote:
>>>>
>>>>> Author: majnemer
>>>>> Date: Sat May 28 14:45:49 2016
>>>>> New Revision: 271139
>>>>>
>>>>> URL: http://llvm.org/viewvc/llvm-project?rev=271139&view=rev
>>>>> Log:
>>>>> [llvm-readobj] Validate the string table offset before using it
>>>>>
>>>>> Modified:
>>>>>     llvm/trunk/tools/llvm-readobj/COFFDumper.cpp
>>>>>
>>>>> Modified: llvm/trunk/tools/llvm-readobj/COFFDumper.cpp
>>>>> URL:
>>>>> http://llvm.org/viewvc/llvm-project/llvm/trunk/tools/llvm-readobj/COFFDumper.cpp?rev=271139&r1=271138&r2=271139&view=diff
>>>>>
>>>>> ==============================================================================
>>>>> --- llvm/trunk/tools/llvm-readobj/COFFDumper.cpp (original)
>>>>> +++ llvm/trunk/tools/llvm-readobj/COFFDumper.cpp Sat May 28 14:45:49
>>>>> 2016
>>>>> @@ -794,14 +794,20 @@ void COFFDumper::printCodeViewSymbolSect
>>>>>        while (!Contents.empty()) {
>>>>>          const FrameData *FD;
>>>>>          error(consumeObject(Contents, FD));
>>>>> +
>>>>> +        if (FD->FrameFunc >= CVStringTable.size())
>>>>> +          error(object_error::parse_failed);
>>>>> +
>>>>> +        StringRef FrameFunc =
>>>>> +            CVStringTable.drop_front(FD->FrameFunc).split('\0').first;
>>>>> +
>>>>>          DictScope S(W, "FrameData");
>>>>>          W.printHex("RvaStart", FD->RvaStart);
>>>>>          W.printHex("CodeSize", FD->CodeSize);
>>>>>          W.printHex("LocalSize", FD->LocalSize);
>>>>>          W.printHex("ParamsSize", FD->ParamsSize);
>>>>>          W.printHex("MaxStackSize", FD->MaxStackSize);
>>>>> -        W.printString("FrameFunc",
>>>>> -
>>>>> CVStringTable.drop_front(FD->FrameFunc).split('\0').first);
>>>>> +        W.printString("FrameFunc", FrameFunc);
>>>>>          W.printHex("PrologSize", FD->PrologSize);
>>>>>          W.printHex("SavedRegsSize", FD->SavedRegsSize);
>>>>>          W.printFlags("Flags", FD->Flags,
>>>>> makeArrayRef(FrameDataFlags));
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> llvm-commits mailing list
>>>>> llvm-commits at lists.llvm.org
>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>>>>>
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160531/abde9fb1/attachment.html>


More information about the llvm-commits mailing list