Skip to content

[BUG] Glushkov regex fast path treats a lazy quantifier as greedy in split_re #23287

Description

@thirtiseven

Describe the bug

The Glushkov regex fast path added by #21936 can be selected for a pattern containing a lazy quantifier, even though lazy quantifiers are documented as unsupported and should fall back to the Thompson engine.

For split_record_re, this changes the matched delimiter length.

Java pattern: \S\r+?\n*
cuDF pattern: [^ \u000b\n\t\r\f]\r+?\n*
Input: \rbaab\r\ra

Expected: [\rbaa, \ra]
Actual:   [\rbaa, a]

Java and the Thompson engine honor the reluctant \r+? and consume one \r. The Glushkov path consumes both consecutive \r characters, behaving as if the quantifier were greedy.

Steps/Code to reproduce bug

Create a strings column containing:

\rbaab\r\ra

Run split_record_re with:

pattern: [^ \u000b\n\t\r\f]\r+?\n*
flags: EXT_NEWLINE
capture groups: NON_CAPTURE
limit: -1

The same failure can be reproduced by running the NVIDIA/cudf-spark RegularExpressionTranspilerSuite test named string split fuzz - anchor focused.

Expected behavior

The Glushkov eligibility check should reject this pattern and fall back to the Thompson engine, producing:

[\rbaa, \ra]

One possible conservative fix is to treat a priority frontier as unsupported whenever an ACCEPT entry is followed by another character-consuming entry. For this pattern, the relevant frontier is:

[LF, ACCEPT, CR-repeat]

This would preserve common greedy frontiers such as [CHAR, ACCEPT] while rejecting priority layouts that Glushkov cannot represent correctly.

A regression test should use split_re or replace_re, where the match length is observable. A contains_re assertion alone cannot distinguish lazy from greedy behavior.

Environment overview (please complete the following information)

  • Environment location: NVIDIA Blossom/pre-merge CI on a containerized GPU runner
  • Method of cuDF install: bundled in the spark-rapids-jni snapshot
    • Passing snapshot: 26.08.0-20260714.071523-47-cuda12
    • Failing snapshot: 26.08.0-20260716.034120-48-cuda12

Environment details

The failure occurred in NVIDIA/cudf-spark pre-merge CI. The same deterministic test passed with JNI snapshot build 47 and failed after the same CI job updated to build 48.

Full environment output from print_env.sh is not available because the failure was observed on the remote CI runner.

Additional context

This regression currently blocks NVIDIA/cudf-spark pre-merge CI:

https://github.com/NVIDIA/cudf-spark/actions/runs/29471812110

The fuzz test uses fixed seeds and the same failure occurs in unrelated cudf-spark pull requests, so this is not a flaky test or a change introduced by the affected cudf-spark PR.

Metadata

Metadata

Assignees

Labels

Needs TriageNeed team to review and classifySparkFunctionality that helps Spark RAPIDSbugSomething isn't workinglibcudfAffects libcudf (C++/CUDA) code.stringsstrings issues (C++ and Python)

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions