When  you call pcre_exec(), it makes use of an internal function called
       match(). This calls itself recursively at branch points in the pattern,
       in  order to remember the state of the match so that it can back up and
       try a different alternative if the first one fails.  As  matching  pro-
       ceeds  deeper  and deeper into the tree of possibilities, the recursion
       depth increases.

       Not all calls of match() increase the recursion depth; for an item such
       as  a* it may be called several times at the same level, after matching
       different numbers of a's. Furthermore, in a number of cases  where  the
       result  of  the  recursive call would immediately be passed back as the
       result of the current call (a "tail recursion"), the function  is  just
       restarted instead.

       The pcre_dfa_exec() function operates in an entirely different way, and
       uses recursion only when there is a  regular  expression  recursion  or
       subroutine  call in the pattern. This includes the processing of asser-
       tion and "once-only" subpatterns, which  are  handled  like  subroutine
       calls.  Normally,  these are never very deep, and the limit on the com-
       plexity of pcre_dfa_exec() is controlled by the amount of workspace  it
       is  given. However, it is possible to write patterns with runaway infi-
       nite recursions; such patterns will cause pcre_dfa_exec() to run out of
       stack. At present, there is no protection against this.

       The comments that follow do NOT apply to pcre_dfa_exec(); they are rel-
       evant only for pcre_exec().

   Reducing pcre_exec()'s stack usage

       Each time that match() is actually called recursively, it  uses  memory
       from  the  process  stack.  For certain kinds of pattern and data, very
       large amounts of stack may be needed, despite the recognition of  "tail
       recursion".   You  can often reduce the amount of recursion, and there-
       fore the amount of stack used, by modifying the pattern that  is  being
       matched. Consider, for example, this pattern:


       It  matches  from wherever it starts until it encounters "<inet" or the
       end of the data, and is the kind of pattern that  might  be  used  when
       processing an XML file. Each iteration of the outer parentheses matches
       either one character that is not "<" or a "<" that is not  followed  by
       "inet".  However,  each  time  a  parenthesis is processed, a recursion
       occurs, so this formulation uses a stack frame for each matched charac-
       ter.  For  a long string, a lot of stack is required. Consider now this
       rewritten pattern, which matches exactly the same strings:


       This uses very much less stack, because runs of characters that do  not
       contain  "<" are "swallowed" in one item inside the parentheses. Recur-
       compile PCRE to use heap memory instead of stack for remembering  back-
       up  points  when  pcre_exec()  is running. This makes it run a lot more
       slowly, however.  Details of how to do this are given in the  pcrebuild
       documentation. When built in this way, instead of using the stack, PCRE
       obtains and frees memory by calling the functions that are  pointed  to
       by  the  pcre_stack_malloc  and  pcre_stack_free variables. By default,
       these point to malloc() and free(), but you can replace the pointers to
       cause  PCRE to use your own functions. Since the block sizes are always
       the same, and are always freed in reverse order, it may be possible  to
       implement  customized  memory handlers that are more efficient than the
       standard functions.

   Limiting pcre_exec()'s stack usage

       You can set limits on the number of times that match() is called,  both
       in  total  and recursively. If a limit is exceeded, pcre_exec() returns
       an error code. Setting suitable limits should prevent it  from  running
       out  of  stack.  The  default  values of the limits are very large, and
       unlikely ever to operate. They can be changed when PCRE is  built,  and
       they  can  also be set when pcre_exec() is called. For details of these
       interfaces, see the pcrebuild documentation and the  section  on  extra
       data for pcre_exec() in the pcreapi documentation.

       As a very rough rule of thumb, you should reckon on about 500 bytes per
       recursion. Thus, if you want to limit your  stack  usage  to  8Mb,  you
       should  set  the  limit at 16000 recursions. A 64Mb stack, on the other
       hand, can support around 128000 recursions.

       In Unix-like environments, the pcretest test program has a command line
       option (-S) that can be used to increase the size of its stack. As long
       as the stack is large enough, another option (-M) can be used  to  find
       the  smallest  limits  that allow a particular pattern to match a given
       subject string. This is done by  calling  pcre_exec()  repeatedly  with
       different limits.

   Changing stack size in Unix-like systems

       In  Unix-like environments, there is not often a problem with the stack
       unless very long strings are involved,  though  the  default  limit  on
       stack  size  varies  from system to system. Values from 8Mb to 64Mb are
       common. You can find your default limit by running the command:

         ulimit -s

       Unfortunately, the effect of running out of  stack  is  often  SIGSEGV,
       though  sometimes  a more explicit error message is given. You can nor-
       mally increase the limit on stack size by code such as this:

         struct rlimit rlim;
         getrlimit(RLIMIT_STACK, &rlim);
         rlim.rlim_cur = 100*1024*1024;
         setrlimit(RLIMIT_STACK, &rlim);

       This reads the current limits (soft and hard) using  getrlimit(),  then
       Philip Hazel
       University Computing Service
       Cambridge CB2 3QH, England.


       Last updated: 03 January 2010
       Copyright (c) 1997-2010 University of Cambridge.

Man Pages Copyright Respective Owners. Site Copyright (C) 1994 - 2017 Hurricane Electric. All Rights Reserved.