Now, when I call the function with %something = $feedtextconvert(%x) in a socket (where %x contains the <title> line of a feed), mIRC crashes (reproducible). When I comment out the line replacing the < or I replace the particular line by:
First, the line has to be extremely long. While mIRC processes lines of more than 1k characters without any problem, the crash occurs in a line with 3,400+ characters. The whole crashing line we want to process (excerpt from a German weblog) can be found here:
test.txt (Too long for pasting here directly, sorry.)
One more thing we noticed: If we just //echo the replaced line without using a %var, it works. The crash only happens if we try to assign it to a variable. This thing is getting stranger every day. :-) (Using /tokenize instead of a var works, too, so obviously the variable assignment is broken here.)
To make it easier to test, I changed and added the code from above to a new script file: test.mrc
... echoes "test" correctly, so, at least, the "fixed" expression matches. Using it in the particular %feedconverted line still makes it crash mIRC, so (obviously) it does not even matter if the expression matches or not.
(I wonder why the stack overflow only applies to some of the rules and does not happen when commenting out some.)
Gamers.IRC team - gamersirc.net #Gamers.IRC on QuakeNet (sometimes we're there).
The PCRE library supports recursion using two different methods: one uses normal stack allocation and the other allocates memory on the fly as needed.
The reason your script is crashing the PCRE library is due to heavy recursion resulting in a stack allocation error. This is most likely due to an inefficient regular expression. I tested your script using memory-based recursion in PCRE and it completed without crashing, however the result from $feedtextconvert() was not correct.
In a previous version of mIRC, I changed PCRE to use memory based recursion since users were reporting the same issue as you. The change solved the heavy recursion crash issue, however it also resulted in far slower expression parsing, which some users reported. So I changed it back to stack allocation in a subsequent version of mIRC.
Update: I have made a change to PCRE that limits the recursion depth and causes the parsing to stop at that point. Since it is stack-based, a recursion depth of about 2000 seems to be a safe maximum and prevents mIRC from crashing.
The first "img" expression results in an endless recursion loop, so something is wrong with the expression, and it will be halted once it reaches the 2000 recurse limit.
The second "img" expression also requires recursion that goes much deeper than the 2000 recurse limit. So this expression will be halted before it finishes as well.
The second expression does not work correctly, even when I allow it to go as deep as it wants. It finishes fairly quickly but the result is not correct, so something is still wrong with it.
Since I rarely receive reports about regular expressions crashing mIRC, it seems that very few users create regular expressions that require heavy recursion (at least not intentionally), so the 2000 recurse limit seems to be sufficient.
Have you tried testing your expression in another regular expression parser to see what happens?