Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Add test for file variations#31

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Open
RunDevelopment wants to merge1 commit intoimage-rs:main
base:main
Choose a base branch
Loading
fromRunDevelopment:test-variations

Conversation

@RunDevelopment
Copy link
Contributor

I added a test that mutates the image files we already have and checks that decoders do not panic for them. Current mutations include:

  1. Truncations likeimage tests for too.
  2. An extension where is just appends garbage.
  3. Header mutations where certain header bytes are changed.

This would have found a panic in OBT that was fixed by#28.


Unfortunately, this test is currently a lot slower than it has to be becauseimage only supports using plugins when reading files. This forces the test to write the modified files to disk for every mutation that we want to test. Writing to disk makes the test a lot slower than it has to be, but it's not too bad. It only takes 2 sec on my machine.

I madeimage-rs/image#2662 to address this API oversight. But even if a solution gets added, we probably won't be able to use the solution right away due to version compatibility.

@fintelia
Copy link
Contributor

This sounds like it is implementing fuzzing. To quote the readme:

Fuzzing is not a priority for this crate and decoders may panic or worse on malformed input. Please do not open issues for crashes found by fuzzing, unless they are memory safety violations, though PRs fixing them are welcome.

@RunDevelopment
Copy link
ContributorAuthor

Kinda? It qualifies as fuzzing in the sense that it uses (mostly) invalid inputs.

My understanding was that fuzzing isn't a priority to minimize maintenance burden. Random fuzzing can find crashes whenever, making the workload unpredictable. Worse, it's likely on the maintainer to triage and fix those crashes once discovered.

But those downsides don't really apply here. The mutations done here are deterministic. So if we start in a valid state (as we are now), they'll only find crashes when something changes. E.g. the implementation changes, new test files get added, dependencies get updated. And since changes are introduced via PRs, it should be on the PR author to fix the crashes they introduced or uncovered.

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@RunDevelopment@fintelia

[8]ページ先頭

©2009-2025 Movatter.jp