Regular Expression causes LabVIEW crash

[VitSlaby]

This VI causes my LV 2021 32bit to crash, but not with 64bit LV. Is there something wrong with the regex itself? On regex101 it works flawlessly.

[PalanivelThiruvenkadam]

Even it crashes LV2023 (32bit).

Note: I don't have 64bit installed

[VitSlaby]

Some more investigation - if I shorten the string part between the "recipeAttributeList", it works and executes in no time. I did some benchmark with putting more and more text in the string input and for me it stops working at ~ 2780 characters, see the example. No memory raise detected.

[instrumento]

I have a regex example that crashes LabVIEW 2022Q3 64 bits by calling Search and Replace String.

Pretty sure some excessive greedy backtracking is causing the problem and we've replaced this with something that doesn't crash, though maybe LabVIEW could just error out somehow and not go puff.

[billko]

Is it a crash or does it just return an error? LV regex I think is based on PCRE so will return an error on encountering a null character.

[instrumento]

---

@billko wrote:

Is it a crash or does it just return an error? LV regex I think is based on PCRE so will return an error on encountering a null character.

---

Hard crash.  No nulls in the string.  Probably recursion / out of stack space when doing greedy backtracking.

[Martin_Henz]

---

@instrumento wrote:

I have a regex example that crashes LabVIEW 2022Q3 64 bits by calling Search and Replace String.

Pretty sure some excessive greedy backtracking is causing the problem and we've replaced this with something that doesn't crash, though maybe LabVIEW could just error out somehow and not go puff.

---

Please downconvert your VI to at least LabVIEW 2021 (better 2019, so others can also open the VI).

I think it is similar or idenbtical to the initial posting from VitSlaby. It is cause by recusion / stack overflow in PCRE. I have not checked PCRE2 in this regard, but that is probably not relevant here. The PCRE library has the nice option NO_RECURSE and this option is normally not enabled and PCRE uses recusion for backtracking.

Spoiler

/* PCRE uses recursive function calls to handle backtracking while matching.
This can sometimes be a problem on systems that have stacks of limited
size. Define NO_RECURSE to any value to get a version that doesn't use
recursion in the match() function; instead it creates its own stack by
steam using pcre_recurse_malloc() to obtain memory from the heap. For more
detail, see the comments and other stuff just above the match() function.
*/

If compiled with NO_RECUSE, the initial regex from VitSlaby works without crashing, so I think it is the same issue like yours.

[instrumento]

I'm pretty sure it is recursive backtracking that crashes it, I just followed up as original post was on 32 bits mostly to point out that 64 bits LV is no different.  And no, I'm not about to compile PCRE, and LV doesn't offer me that option. 

Attaching 2019 version here.

[Yamaeda]

I bet there's some option to limit or stop recursion. I don't know enough regexp.

[Martin_Henz]

Thanks for the downconverted VI.

It's an interessting situation, which forced me to look something deeper into it.

I just started to fix some minor bugs and move my very old PCRE library to 64 bit, so it's just a little step more to investigate this issue.

The problem is with the last regex: "(^([#;].*\n)*\[)", It works fine for several replacements until it comes to the line "# [XX xxxxxxx Xxxx]" of the input string. At that point the PCRE compiled with recursion enabled will crash. The version compiled without recursion works until the end of the input string.

Here is the complete source code in case anyone is interested in taking a closer look at the problem. My library does not implement search and replace, and I also find the implementation with $1, etc. in the replace string rather strange. That's why I have recreated it very quickly and dirty. Downconverted to LabVIEW 2018.