Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update fuzzer.cpp Improve Memory Safety and Optimize String Handling in Fuzzer #12816

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

Shivam7-1
Copy link
Contributor

PR Description: Enhanced memory safety by adding checks for empty input and optimized string handling using std::string_view to reduce redundant conversions. These improvements increase performance and robustness during fuzzing by minimizing unnecessary memory allocations and ensuring efficient processing of input data.

Key Changes in the Code:

  1. Memory Safety and Bounds Checking:
    Added a check for empty input at the start of LLVMFuzzerTestOneInput.
    Ensured operations on non-empty strings with checks like if (!result.empty()).
  2. Reduce Redundant Conversions:
    Replaced std::string with std::string_view for more efficient handling of the input data and the resulting string from the buffer.
    Avoided copying the data unnecessarily by directly working with std::string_view.

Why These Changes Matter:

  1. Performance: Reducing string copying with std::string_view improves the performance of the fuzzer.
  2. Safety: Early checks prevent unnecessary parsing and memory operations on invalid or empty data, making the code more robust.

Copy link

github-actions bot commented Dec 7, 2024

Shivam7-1 is a new contributor to projects/rapidjson. The PR must be approved by known contributors before it can be merged. The past contributors are: tyler92, DonggeLiu, inferno-chromium, devtty1er, Dor1s, guidovranken

@Shivam7-1
Copy link
Contributor Author

Hii @tyler92 @DonggeLiu Could Team Please Review This PR
Thanks

@tyler92
Copy link
Contributor

tyler92 commented Dec 8, 2024

LGTM, but I was going to move this target to the rapidjson repository when all issues are fixed (currently, there is one issue with the coverage build). By default, C++11 is used in the rapidjson project, so we can't use std::string_view there.

So, right now we can merge it but later I will have to revert this change.

UPD: I wrote one comment

@Shivam7-1
Copy link
Contributor Author

Shivam7-1 commented Dec 8, 2024

Hii @tyler92 Thanks For Reviewing I’ve updated the code accordingly to address the null-termination issue. The std::string is now used to ensure the input passed to rapidjson::Parse is null-terminated, while std::string_view is retained for output handling where null-termination is not required, preserving efficiency and correctness.

@Shivam7-1 Shivam7-1 requested a review from tyler92 December 8, 2024 14:45
@Shivam7-1
Copy link
Contributor Author

Hii @tyler92 Could you please Review This PR again
Thanks

@tyler92
Copy link
Contributor

tyler92 commented Dec 9, 2024

LGTM, but still - comment. So, up to oss-fuzz's maintainers

Copy link
Collaborator

@DavidKorczynski DavidKorczynski left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not really against this, however, i'm not really sure what the gain is tbh. I'm not a fan of introducing a check on size == 0 and I'm not really familiar with string view. There may be some technical gains, but I'm not sure this harness is in need of this as such.

I'd probably prefer to simply go for upstreaming this and then take improvements on the harness from there.

@Shivam7-1
Copy link
Contributor Author

Hii @DavidKorczynski This PR is Approved Could Please merge it
Thanks

@Shivam7-1
Copy link
Contributor Author

Shivam7-1 commented Dec 10, 2024

Hii @DavidKorczynski Thanks For Reply Could You le me know But what Exactly should I do it ?

For explanation about changes here it is
Using std::string_view provides better efficiency for handling input data, as it avoids unnecessary copying while ensuring safety and correctness when paired with a null-terminated std::string. While this harness might not currently demand these optimizations, incorporating them could make the codebase more robust and performant in the long run.
Thanks

@tyler92
Copy link
Contributor

tyler92 commented Dec 10, 2024

@DavidKorczynski I will move it upstream, but I wanted to have coverage build to be fixed before. Right now I don't understand if this issue related to the infrastructure or something wrong with the fuzzer.

It's about #12660 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants