This is an archive of the discontinued LLVM Phabricator instance.

[llvm-demangle-fuzzer] Also fuzz microsoftDemangle().
ClosedPublic

Authored by morehouse on Nov 20 2018, 6:54 PM.

Details

Summary

Use first byte of input to determine whether to call itaniumDemangle()
or microsoftDemangle().

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

Diff Detail

Repository
rL LLVM

Event Timeline

morehouse created this revision.Nov 20 2018, 6:54 PM
morehouse updated this revision to Diff 174863.Nov 20 2018, 6:57 PM
  • Formatting.

microsoftDemangle crashes in 1 second with buffer overflows or ASSERT failures when I run locally.

Hi, thanks for working on this! Fuzzing in the itanium demangler has caught *a lot* of bugs, so this seems pretty useful. Whats the argument for testing the two demanglers in the same path? There isn't really any shared code, so I think it makes more sense to separate these out.

@kcc: is there any oss-fuzz testing for llvm-demangle-fuzzer.cpp? I thought it was just for libcxxabi. Also, will reinterpreting the first char in Data break the existing itanium corpuses?

thakis accepted this revision.Dec 14 2018, 10:47 AM
thakis added a subscriber: thakis.

I believe this runs on oss-fuzz already: https://github.com/google/oss-fuzz/blob/master/projects/llvm/build.sh#L37

Having one or two fuzzer binaries seems like a toss-up (true it's a mostly independent branch, but we don't create a new fuzzer binary for each independent branch), and having just binary saves the work of hooking a new binary up on oss-fuzz.

Re corpus: I'd be very surprised if oss-fuzzer assumed that fuzzers never change. So I don't think (but don't know for sure) that this is a concern.

This revision is now accepted and ready to land.Dec 14 2018, 10:47 AM

Oh, okay nice. Thanks for checking.

Having one or two fuzzer binaries seems like a toss-up (true it's a mostly independent branch, but we don't create a new fuzzer binary for each independent branch), and having just binary saves the work of hooking a new binary up on oss-fuzz.

I would probably prefer always calling microsoftDemangle() in llvm-demangler-fuzzer. The Itanium demanglers are identical, so we're just wasting cycles fuzzing them both independently.

Re corpus: I'd be very surprised if oss-fuzzer assumed that fuzzers never change. So I don't think (but don't know for sure) that this is a concern.

I would probably prefer always calling microsoftDemangle() in llvm-demangler-fuzzer. The Itanium demanglers are identical, so we're just wasting cycles fuzzing them both independently.

That makes sense to me (with a comment explaining this).

kcc added a comment.Dec 17 2018, 5:13 PM

I would prefer to have two separate targets.

morehouse updated this revision to Diff 180340.Jan 4 2019, 4:42 PM
  • Separate fuzz targets.
kcc accepted this revision.Jan 4 2019, 4:52 PM

LGTM
Don't forget to add the new fuzz target to oss-fuzz

This revision was automatically updated to reflect the committed changes.
llvm/trunk/tools/llvm-demangle-fuzzer/CMakeLists.txt