Experimentally one very long path of this size shouldn't blow the RAM
budget in the fuzzer environment, and it's not really exciting to
discover that building the dirs dict for one stupidly long path uses a
ton of RAM.
Details
- Reviewers
baymax - Group Reviewers
hg-reviewers
Diff Detail
- Repository
- rHG Mercurial
- Lint
Lint Skipped - Unit
Unit Tests Skipped
Event Timeline
If we blow stupid amounts of memory in the dirs internals, perhaps we should be enforcing a length limit in the implementation instead of burying our head in the sand by not triggering it via fuzzing.
If we need to teach the fuzzer to only send small input so we don't trigger exceptions, fine. But if this is an OOM vector, I'd like to fix it. What do you think?
The concern is basically that the fuzzer will figure out something dumb, like 'a/' * 40000 + 'b' which consumes around a gig of memory. I don't think this is a serious OOM vector, since any such manifest would also be inordinately large?
Maybe I'm being an optimist.
There seems to have been no activities on this Diff for the past 3 Months.
By policy, we are automatically moving it out of the need-review state.
Please, move it back to need-review without hesitation if this diff should still be discussed.
:baymax:need-review-idle: