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

Tue May 31 12:54:38 PDT 2016

On Tue, May 31, 2016 at 12:49 PM, David Blaikie <dblaikie at gmail.com> wrote:

>
>
> 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.
>

There is no such way in llvm today, but it should be very easy to build
one.
We do it in other installations of libFuzzer and it is a very good thing to
have.

>
>
>> 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/da5f48d7/attachment.html>