Skip to content

automata: fix search_slots panic with zero-repetition capture#1329

Closed
keith-hall wants to merge 1 commit intorust-lang:masterfrom
forkeith:fix-search-slot-panic-zero-repetition-capture-group
Closed

automata: fix search_slots panic with zero-repetition capture#1329
keith-hall wants to merge 1 commit intorust-lang:masterfrom
forkeith:fix-search-slot-panic-zero-repetition-capture-group

Conversation

@keith-hall
Copy link
Contributor

Fixes #1327

update the onepass DFA to only copy slots that exist in the cache, which may contain fewer slots than what the caller provided

BurntSushi pushed a commit that referenced this pull request Jan 30, 2026
…ots are given

The API specifically documents that the caller may provide *any* number
of slots. But the onepass implementation was panicking when too many
were provided. (I had only considered the case when too few were
provided when I wrote one-pass implementation I think.)

This already works for the PikeVM and the bounded backtracker. This
commit adds tests covering those as well.

Note that the bug report specifically cites a zero-repetition capture
group as the instigator here. While that may have provided the
circumstances for the bug to appear, the actual bug is more general than
that. You don't need any capture groups at all to provoke it. You just
need to provide more slots than there are in the compiled regex.

Fixes #1327, Closes #1329
BurntSushi pushed a commit that referenced this pull request Jan 30, 2026
…ots are given

The API specifically documents that the caller may provide *any* number
of slots. But the onepass implementation was panicking when too many
were provided. (I had only considered the case when too few were
provided when I wrote one-pass implementation I think.)

This already works for the PikeVM and the bounded backtracker. This
commit adds tests covering those as well.

Note that the bug report specifically cites a zero-repetition capture
group as the instigator here. While that may have provided the
circumstances for the bug to appear, the actual bug is more general than
that. You don't need any capture groups at all to provoke it. You just
need to provide more slots than there are in the compiled regex.

Fixes #1327, Closes #1329
@BurntSushi
Copy link
Member

Thanks! I'm not sure why, but I can't push to this PR. So I opened #1330 which is based on this one. I tweaked the fix, added more general regression tests and massaged the wording here to not be so coupled to a zero-repetition capture group.

@keith-hall
Copy link
Contributor Author

Nice, thank you. I think the reason why you can't push to this PR's branch is because I forked this repo to an organization - I like to keep my forks separate from my own projects. And organization owned repositories don't allow pushes from other users, there is no option to "allow maintainers to push to this branch" unfortunately. It kinda makes sense but is a little annoying...

BurntSushi pushed a commit that referenced this pull request Feb 3, 2026
…ots are given

The API specifically documents that the caller may provide *any* number
of slots. But the onepass implementation was panicking when too many
were provided. (I had only considered the case when too few were
provided when I wrote one-pass implementation I think.)

This already works for the PikeVM and the bounded backtracker. This
commit adds tests covering those as well.

Note that the bug report specifically cites a zero-repetition capture
group as the instigator here. While that may have provided the
circumstances for the bug to appear, the actual bug is more general than
that. You don't need any capture groups at all to provoke it. You just
need to provide more slots than there are in the compiled regex.

Fixes #1327, Closes #1329
BurntSushi pushed a commit that referenced this pull request Feb 3, 2026
…ots are given

The API specifically documents that the caller may provide *any* number
of slots. But the onepass implementation was panicking when too many
were provided. (I had only considered the case when too few were
provided when I wrote one-pass implementation I think.)

This already works for the PikeVM and the bounded backtracker. This
commit adds tests covering those as well.

Note that the bug report specifically cites a zero-repetition capture
group as the instigator here. While that may have provided the
circumstances for the bug to appear, the actual bug is more general than
that. You don't need any capture groups at all to provoke it. You just
need to provide more slots than there are in the compiled regex.

Fixes #1327, Closes #1329
pull bot pushed a commit to SINHASantos/regex that referenced this pull request Feb 3, 2026
…ots are given

The API specifically documents that the caller may provide *any* number
of slots. But the onepass implementation was panicking when too many
were provided. (I had only considered the case when too few were
provided when I wrote one-pass implementation I think.)

This already works for the PikeVM and the bounded backtracker. This
commit adds tests covering those as well.

Note that the bug report specifically cites a zero-repetition capture
group as the instigator here. While that may have provided the
circumstances for the bug to appear, the actual bug is more general than
that. You don't need any capture groups at all to provoke it. You just
need to provide more slots than there are in the compiled regex.

Fixes rust-lang#1327, Closes rust-lang#1329
@keith-hall keith-hall deleted the fix-search-slot-panic-zero-repetition-capture-group branch February 5, 2026 21:05
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.

zero repetition capture groups and search slots panic

2 participants