I'm using very large and complex regular expressions on very large and complex pieces of data. The regexes work great and are quite fast and efficient when they match. However, when they don't match, they eat up all the free cycles on my high end server until Apache kills them (this is a CGI application). This seems to be directly related to the size of the data and the complexity of the regular expression. It's quite plausable that there's something wrong with the regular expressions being used, but because in this particular circumstance I am allowing users to enter the regular expressionsl, I would like to limit the time and/or cycles of the regex processing, no matter the regex.
I've tried to use an alarm() call wrapped inside an eval{} to act as a timeout, but it seems that because of the problems with the regex itself, the alarm is never recieved and/or handled properly. To summarize, it's used like this:
So the questions here are obvious: what am I doing wrong that I am creating these conditions for a 'runaway regex'? How can I contain it and limit them to a maximum amount of time or processing? Why doesn't the alarm ever call die()?eval { local $SIG{ALRM} = sub { die('ALARM'); }; alarm($REGEX_TIMEOUT); @return = ($raw =~ /$regex/msgx); alarm(0); } if ($@ =~ /ALARM/) { ... }
TIA,
Scott
In reply to Losing control of large regular expressions by scottb
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |