Bug 16698 – std.regex.matchFirst corrupts stack

Code: ----------- import std.datetime; import std.regex; import std.stdio; Date[2] parseDateRange() { auto rangeRe = regex(`^\s*(\d+-\d+-\d+)(?:\s+to\s+(\d+-\d+-\d+))?`); auto m = matchFirst("2016-01-01", rangeRe); return [Date(2016,1,1), Date(2016,1,1)]; } int main(string[] args) { auto range = parseDateRange(); writefln("PPPPPParsed range=%s", range); writefln("AAAAAAAA"); return 0; } ----------- This is reduced from a larger program. The symptom is that std.datetime dies with an array range assertion. But the real problem is that somewhere between parseDateRange() and main(), the Date[2] return value gets corrupted to garbage values, so std.datetime gets confused by a Date object that is in an invalid state. Scarily enough, this bug is only detected when I attempt to print the Date object; in the original code, it was causing silent failures of date checks because the corrupted Date objects return nonsensical results when used in Date comparisons. Commenting out the call to matchFirst() makes the problem go away. Note that this reduced code actually doesn't do anything with the match results; the very fact that matchFirst() was called triggers the corruption bug. In the original code the return value is, of course, built from the regex match results, but the bug seems to happen even if we don't touch the match results.

Digger says: commit 74a3133b9a6f501938e1b808282dfcbaa24691be Author: Ilya Yaroshenko <[email protected]> Date: Tue Apr 26 14:31:35 2016 +0300 phobos: Merge pull request #4142 from DmitryOlshansky/regex-ref-counting https://github.com/D-Programming-Language/phobos/pull/4142 [std.regex] Use ref-counting for Captures struct

Reduced to a compiler bug: issue 16699. Filed separately because the regex issue can possibly be fixed by working around the compiler bug.

Issue 16699 has been fixed and the code here works as expected now. I don't think we need to add the regex code to the test suite (feel free to do that, though). Closing as duplicate of 16699. *** This issue has been marked as a duplicate of issue 16699 ***