As Tanktalus says, this is almost certainly caused by recursion going past the end of the available stack space. I expect that it is caused specifically by the very first fragment of your regexp:

  (?:.*\n)*?
[download]

Since that fragment has no effect other than to ensure the rest of the pattern is anchored to the start of the line, I would suggest replacing:

  m/(?:.*\n)*?rest of pattern/
[download]

  m/^rest of pattern/m
[download]

Hugo

Let's see if understand the situation here... You have a multi-line string stored as a scalar, and you are trying to capture 11 substrings. Each substring to be captured represents one whole line of text, and except for just a couple minor variations, all these lines to be captured are identical except for the value of a two-digit number, which follows an otherwise identical initial string.

I don't know what you need to do with all those captures once you get the match, but I expect it would not be hard to tweak the subsequent code just a little so that the overall process is a lot more compact and sensible (and doesn't crash).

But then again, since you say you are "getting the regex from a database" and "doing more regexes against more files", the overall system must be a lot more complicated than I would expect, and maybe a simpler strategy would involve a rather large amount of refactoring. (But maybe that wouldn't be such a bad thing?)

Still, I wonder if something like this might be a step in the right direction:

my @captures =
    grep { /^\t\Q.1.3.6.1.4.1.9.2.2.1.1.\E(\d{2}).*?\([A-Z]+\)$/
          and $1 =~ /1[0-7]|2[158]/ } split /\n/;
[download]

Or is it long and cumbersome because you just happen to be including all the details that you know about, even when they are redundant and/or unnecessary in terms of assuring correct matches?

(update: removed spurious close paren from code snippet)

well the regex is supposed to get, as you figured, a number value which represent a specific interface and a digit or a string as the second value depends on what that series of digits represent in the beginning. hv's suggestion still does not help I applied it to previous regexes to following the same reasoning and it still crashed . Debugging in gdb shows it crashes in regexec.c (using bt) I am starting to wonder if this is caused by something else entirely but you all seem to agree it has to do with the regex ( If you have suggestion that will completely prove thats the case it would helpful). I am trying to apply the suggested patch I do not want to use the development version and changing the regexec.c file to look like the patched version of regexec.c that i did gives lots of errors. Removing those errors will be a pain if even possible with my limited experience.

the regex is supposed to get... a number value which represent a specific interface and a digit or a string as the second value depends on what that series of digits represent in the beginning

I'm not sure I get all that, but it sounds like you should just focus on simplifying the process. Split the scalar up into lines, and look for matches one line at a time. I would expect that to simplify a lot of things for you. If you have trouble with that, tell us more about what you're actually trying to accomplish, show us a little bit of input data, what you want to extract from it, etc.

I'd be willing to bet you just found one of those cases that would be solved by the iterative regexp matcher announced earlier today. If you're feeling adventurous, you could try getting dave_the_m's patch and backporting it to 5.8, and rebuilding your perl... ;-)

I will try that and see what happens. Thank you.

Simplify the RE perhaps? I think you're running afoul of the pathology mentioned in this article.

I tried every version of regex (possible) that will match and tweaked it even thought it didnt make any sense to see what happens. It began to look like it has cursed numbers or something. I am currently applying that code mentioned in the article to see if it fixes it.