Fuzz: added fuzz test for network filter "local_ratelimit"#11608
Fuzz: added fuzz test for network filter "local_ratelimit"#11608htuch merged 25 commits intoenvoyproxy:masterfrom
Conversation
…s branch merge up-to-date master branch Signed-off-by: jianwen <jianwendong@google.com> Signed-off-by: jianwen <jianwendong@google.com>
Signed-off-by: jianwen <jianwendong@google.com>
Signed-off-by: jianwen <jianwendong@google.com>
50 ms Signed-off-by: jianwen <jianwendong@google.com>
Signed-off-by: jianwen <jianwendong@google.com>
activeFilter. Signed-off-by: jianwen <jianwendong@google.com>
Signed-off-by: jianwen <jianwendong@google.com>
Signed-off-by: jianwen <jianwendong@google.com>
Signed-off-by: jianwen <jianwendong@google.com>
Signed-off-by: jianwen <jianwendong@google.com>
added protobuf file. Signed-off-by: jianwen <jianwendong@google.com>
Signed-off-by: jianwen <jianwendong@google.com>
Signed-off-by: jianwen <jianwendong@google.com>
test/extensions/filters/network/local_ratelimit/local_ratelimit_fuzz_test.cc
Outdated
Show resolved
Hide resolved
Signed-off-by: jianwen <jianwendong@google.com>
Signed-off-by: jianwen <jianwendong@google.com>
Signed-off-by: jianwen <jianwendong@google.com>
sqkerner
left a comment
There was a problem hiding this comment.
This change looks good to me.
htuch
left a comment
There was a problem hiding this comment.
Generally looks great, a couple comment. Thanks.
/wait
| } | ||
| } | ||
| } catch (const EnvoyException e) { | ||
| ENVOY_LOG_MISC(debug, "EnvoyException in fuzz test: {}", e.what()); |
There was a problem hiding this comment.
Why is an arbitrary EnvoyException OK behavior here?
There was a problem hiding this comment.
Why is an arbitrary EnvoyException OK behavior here?
I catch EnvoyException because in
source/extensions/filters/network/local_ratelimit/local_ratelimit.cc
There is an EnvoyException thrown:
if (fill_interval_ < std::chrono::milliseconds(50)) { throw EnvoyException("local rate limit token bucket fill timer must be >= 50ms"); }
Do you have any suggestion on how to deal with this case?
There was a problem hiding this comment.
Jianwen has some history about this --
I think it's OK to add this constraint in the token bucket proto (which is only used in this filter), but the question came up of having 100% line coverage in the filter.
But the middleground might be just to catch the exception when creating the config
There was a problem hiding this comment.
Jianwen has some history about this --
I think it's OK to add this constraint in the token bucket proto (which is only used in this filter), but the question came up of having 100% line coverage in the filter.But the middleground might be just to catch the exception when creating the config
That makes sense. Modified.
test/extensions/filters/network/local_ratelimit/local_ratelimit_fuzz_test.cc
Outdated
Show resolved
Hide resolved
test/extensions/filters/network/local_ratelimit/local_ratelimit_fuzz_test.cc
Show resolved
Hide resolved
asraa
left a comment
There was a problem hiding this comment.
Thanks! Would love to see some stats like exec/sec as well.
test/extensions/filters/network/local_ratelimit/local_ratelimit_fuzz_test.cc
Outdated
Show resolved
Hide resolved
test/extensions/filters/network/local_ratelimit/local_ratelimit_fuzz_test.cc
Outdated
Show resolved
Hide resolved
test/extensions/filters/network/local_ratelimit/local_ratelimit_fuzz_test.cc
Outdated
Show resolved
Hide resolved
added TODO removed unused deps and headers Signed-off-by: jianwen <jianwendong@google.com>
At the beginning, exec/s: 300-500 After #[3000] : exec/s: 170 After #[10000]: exec/s: 111 Update: I ran it for additional several times, each time I deleted the corpus but the exec/s is different. Sometimes when #[4000] it slows down to 100. I remember the first time when I ran it, the exec/s slowed down to 30 exec/s. Is this normal? |
Signed-off-by: jianwen <jianwendong@google.com>
test/extensions/filters/network/local_ratelimit/local_ratelimit_fuzz_test.cc
Show resolved
Hide resolved
It is common for a fuzzer to have a high exec rate at first, then slow down. The reason is that only "shallow" code paths are explored at first. If only a small set of specific inputs cause coverage of a code path that is slow, the fuzzer will not execute it until it runs long enough to find such an input. The simplest way to improve fuzzer speed is to write less text to logs. |
Signed-off-by: jianwen <jianwendong@google.com>
| } | ||
|
|
||
| } // NOLINT | ||
| // Silence clang-tidy here because it thinks there is a memory leak for "fill_timer_" |
There was a problem hiding this comment.
Why are you seeing this and we don't see this in other tests? Can we just destruct at the end?
There was a problem hiding this comment.
Why are you seeing this and we don't see this in other tests? Can we just destruct at the end?
Actually we can't. It will crash and tell you that you are trying to free it twice.
This is the comment of this class about whether to delete or not(it also confuses me why it is designed like this): https://github.com/envoyproxy/envoy/blob/master/test/mocks/event/mocks.cc#L41
I think the reason why I'm seeing this is because this is the only place to use this(Event::MockTimer*) outside of unit test(gTest).
It's possible that gTest will clear all the memory inside a test case after the test case is run, and thus the clang-tidy won't give a warning like this.
But libfuzzer doesn't do this. It's running all the time and may not clear the memory after each test case(after n runs it will check memory leak), so clang-tidy gives this warning.
Currently all the usages of Event::MockTimer* are inside gtest(unit test). All the test cases don't destruct it at the end.
If you have any idea on how to deal with it, please let me know, thanks!
There was a problem hiding this comment.
Hmm, it looks like the local ratelimit Config object has a unique_ptr to the fill timer. So, it should be destructed, along with ActiveFilter, and free the timer. Do you see the Config object going through its destructor?
There was a problem hiding this comment.
Hmm, it looks like the local ratelimit
Configobject has a unique_ptr to the fill timer. So, it should be destructed, along with ActiveFilter, and free the timer. Do you see theConfigobject going through its destructor?
In these classes there are no explicit destructors. I tried using a {} block to wrap all the code and observe through a weak_ptr<Config>, the use_count shows 0 after the code block(inside the block the count is 2).
So Config_ should have been destructed after each run. Since fill_timer_ is a unique_ptr inside Config_, it should also have been deleted. I think this explains why when I delete it manually it says I'm trying to free twice.
There was a problem hiding this comment.
I think clang-tidy is just having a false positive; there is no leak. Is there a way to narrow the NO_LINT to just this variable?
There was a problem hiding this comment.
I think clang-tidy is just having a false positive; there is no leak. Is there a way to narrow the NO_LINT to just this variable?
I tried to use NO_LINT on the variable but it doesn't have any effect. The error given by clang-tidy is in the last line of the block which has potential memory leak issues. NO_LINT could only have effect on one line instead of one variable. After reading the documentation about NO_LINT, I think the only param we can specify is the error type. We could use NOLINT(clang-analyzer-cplusplus.NewDeleteLeaks) instead.
There was a problem hiding this comment.
Yeah, the more specific one works, thanks.
htuch
left a comment
There was a problem hiding this comment.
Looks good, just want to figure out what is going on with NOLINT, this shouldn't be needed.
/wait
Signed-off-by: jianwen <jianwendong@google.com>
test/extensions/filters/network/local_ratelimit/local_ratelimit_fuzz_test.cc
Outdated
Show resolved
Hide resolved
Signed-off-by: jianwen <jianwendong@google.com>
Signed-off-by: jianwen <jianwendong@google.com>
Signed-off-by: jianwen <jianwendong@google.com>
…y#11608) Added fuzz test code for network filter "local_ratelimit" which is defined in extensions/filters/network/local_ratelimit/local_ratelimit.h Added protobuf as the fuzz test input. Added a basic test case to cover the code. Risk Level: low Testing: Increased the coverage from 1.2% to 100% on the filter's .cc and .h files. Signed-off-by: jianwen <jianwendong@google.com>
…y#11608) Added fuzz test code for network filter "local_ratelimit" which is defined in extensions/filters/network/local_ratelimit/local_ratelimit.h Added protobuf as the fuzz test input. Added a basic test case to cover the code. Risk Level: low Testing: Increased the coverage from 1.2% to 100% on the filter's .cc and .h files. Signed-off-by: jianwen <jianwendong@google.com> Signed-off-by: yashwant121 <yadavyashwant36@gmail.com>
Commit Message:
Additional Description:
Added fuzz test code for network filter "local_ratelimit" which is defined in
extensions/filters/network/local_ratelimit/local_ratelimit.hAdded protobuf as the fuzz test input.
Added a basic test case to cover the code.
Risk Level: low
Testing:
Increased the coverage from 1.2% to 100% on the filter's .cc and .h files.
/cc @asraa
/cc @samkerner