Random proptest failure in prop_check_regex_eq_parse #392

New issue

Open

opened 2024-06-12 00:32:18 +00:00 by jade · 3 comments

jade commented

2024-06-12 00:32:18 +00:00

Owner

Offending code: https://git.lix.systems/lix-project/lix/src/b7ce11c97dfd0e73ddefbd15ef2cb59fee7d23f2/tests/unit/libstore/path.cc#L143-L152

lix> [ RUN      ] StorePathTest_RapidCheck.prop_check_regex_eq_parse
lix> /nix/store/P2F1QIJI70D4RXAK0HG73SJL6WBJHMJ4-rapidcheck-0-unstable-2023-12-14-dev/include/rapidcheck/gtest.h:29: Failure
lix> Failed
lix> Falsifiable after 29 tests
lix> std::string:
lix> "0/"
lix> ../tests/unit/libstore/path.cc:152:
lix> RC_ASSERT(parsed == std::regex_match(std::string { name }, nameRegex))
lix> Expands to:
lix> true == false
lix> [  FAILED  ] StorePathTest_RapidCheck.prop_check_regex_eq_parse (1 ms)

I don't know if the bug is in the test or the parser, but this happened to be caught by rapidcheck on CI of completely unrelated changes: https://buildbot.lix.systems/#/builders/37/builds/2275/steps/1/logs/stdio. The rapidcheck reproduction seed thing did not work, but manually substituting the thing as auto name = "0/"; does cause the failure.

Offending code: https://git.lix.systems/lix-project/lix/src/b7ce11c97dfd0e73ddefbd15ef2cb59fee7d23f2/tests/unit/libstore/path.cc#L143-L152 ``` lix> [ RUN ] StorePathTest_RapidCheck.prop_check_regex_eq_parse lix> /nix/store/P2F1QIJI70D4RXAK0HG73SJL6WBJHMJ4-rapidcheck-0-unstable-2023-12-14-dev/include/rapidcheck/gtest.h:29: Failure lix> Failed lix> Falsifiable after 29 tests lix> std::string: lix> "0/" lix> ../tests/unit/libstore/path.cc:152: lix> RC_ASSERT(parsed == std::regex_match(std::string { name }, nameRegex)) lix> Expands to: lix> true == false lix> [ FAILED ] StorePathTest_RapidCheck.prop_check_regex_eq_parse (1 ms) ``` I don't know if the bug is in the test or the parser, but this happened to be caught by rapidcheck on CI of completely unrelated changes: https://buildbot.lix.systems/#/builders/37/builds/2275/steps/1/logs/stdio. The rapidcheck reproduction seed thing did not work, but manually substituting the thing as `auto name = "0/";` does cause the failure.

jade added the

testing

bug

labels

2024-06-12 00:32:18 +00:00

lix-bot commented

2024-06-12 00:34:02 +00:00

Member

This issue was mentioned on Gerrit on the following CLs:

comment in cl/1429 ("[resubmit] flake: update nixpkgs pin 23.11->24.05 (+ boehmgc compat changes)")
comment in cl/1452 ("libutil: tidy Sync and fix its move constructor")

This issue was mentioned on Gerrit on the following CLs: * comment in [cl/1429](https://gerrit.lix.systems/c/lix/+/1429) ("[resubmit] flake: update nixpkgs pin 23.11->24.05 (+ boehmgc compat changes)") * comment in [cl/1452](https://gerrit.lix.systems/c/lix/+/1452) ("libutil: tidy Sync and fix its move constructor")

jade commented

2024-06-14 21:30:40 +00:00

Author

Owner

puck states:

that's a test bug; / is not allowed in store path names
and i think parseStorePath strips the suffix if you pass one in?
ah, it canonicalises it. that's worse

puck states: > that's a test bug; / is not allowed in store path names > and i think parseStorePath strips the suffix if you pass one in? > ah, it canonicalises it. that's worse

jade added the

E/help wanted

label

2024-06-19 06:34:56 +00:00

jade added the

E/reproducible

label

2024-06-24 22:41:37 +00:00

jade referenced this issue

2024-07-04 07:36:10 +00:00

possible bug in `Store::parseStorePath #430

jade added the