Use first byte of input to determine whether to call itaniumDemangle()
or microsoftDemangle().
Addresses https://bugs.llvm.org/show_bug.cgi?id=39582.
Differential D54780
[llvm-demangle-fuzzer] Also fuzz microsoftDemangle(). morehouse on Nov 20 2018, 6:54 PM. Authored by
Details Use first byte of input to determine whether to call itaniumDemangle() Addresses https://bugs.llvm.org/show_bug.cgi?id=39582.
Diff Detail
Event TimelineComment Actions microsoftDemangle crashes in 1 second with buffer overflows or ASSERT failures when I run locally. Comment Actions 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? Comment Actions 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. Comment Actions Oh, okay nice. Thanks for checking.
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.
Comment Actions
That makes sense to me (with a comment explaining this). |