128 lines
5.3 KiB
HTML
128 lines
5.3 KiB
HTML
<html>
|
|
<head>
|
|
<title>pcrestack specification</title>
|
|
</head>
|
|
<body bgcolor="#FFFFFF" text="#00005A" link="#0066FF" alink="#3399FF" vlink="#2222BB">
|
|
<h1>pcrestack man page</h1>
|
|
<p>
|
|
Return to the <a href="index.html">PCRE index page</a>.
|
|
</p>
|
|
<p>
|
|
This page is part of the PCRE HTML documentation. It was generated automatically
|
|
from the original man page. If there is any nonsense in it, please consult the
|
|
man page, in case the conversion went wrong.
|
|
<br>
|
|
<br><b>
|
|
PCRE DISCUSSION OF STACK USAGE
|
|
</b><br>
|
|
<P>
|
|
When you call <b>pcre_exec()</b>, it makes use of an internal function called
|
|
<b>match()</b>. 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 proceeds deeper and
|
|
deeper into the tree of possibilities, the recursion depth increases.
|
|
</P>
|
|
<P>
|
|
Not all calls of <b>match()</b> 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.
|
|
</P>
|
|
<P>
|
|
The <b>pcre_dfa_exec()</b> function operates in an entirely different way, and
|
|
hardly uses recursion at all. The limit on its complexity is the amount of
|
|
workspace it is given. The comments that follow do NOT apply to
|
|
<b>pcre_dfa_exec()</b>; they are relevant only for <b>pcre_exec()</b>.
|
|
</P>
|
|
<P>
|
|
You can set limits on the number of times that <b>match()</b> is called, both in
|
|
total and recursively. If the limit is exceeded, an error occurs. For details,
|
|
see the
|
|
<a href="pcreapi.html#extradata">section on extra data for <b>pcre_exec()</b></a>
|
|
in the
|
|
<a href="pcreapi.html"><b>pcreapi</b></a>
|
|
documentation.
|
|
</P>
|
|
<P>
|
|
Each time that <b>match()</b> 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 therefore the amount of stack
|
|
used, by modifying the pattern that is being matched. Consider, for example,
|
|
this pattern:
|
|
<pre>
|
|
([^<]|<(?!inet))+
|
|
</pre>
|
|
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 character. For a long string, a lot of stack is
|
|
required. Consider now this rewritten pattern, which matches exactly the same
|
|
strings:
|
|
<pre>
|
|
([^<]++|<(?!inet))
|
|
</pre>
|
|
This uses very much less stack, because runs of characters that do not contain
|
|
"<" are "swallowed" in one item inside the parentheses. Recursion happens only
|
|
when a "<" character that is not followed by "inet" is encountered (and we
|
|
assume this is relatively rare). A possessive quantifier is used to stop any
|
|
backtracking into the runs of non-"<" characters, but that is not related to
|
|
stack usage.
|
|
</P>
|
|
<P>
|
|
In environments where stack memory is constrained, you might want to compile
|
|
PCRE to use heap memory instead of stack for remembering back-up points. This
|
|
makes it run a lot more slowly, however. Details of how to do this are given in
|
|
the
|
|
<a href="pcrebuild.html"><b>pcrebuild</b></a>
|
|
documentation.
|
|
</P>
|
|
<P>
|
|
In Unix-like environments, there is not often a problem with the stack, 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:
|
|
<pre>
|
|
ulimit -s
|
|
</pre>
|
|
The effect of running out of stack is often SIGSEGV, though sometimes an error
|
|
message is given. You can normally increase the limit on stack size by code
|
|
such as this:
|
|
<pre>
|
|
struct rlimit rlim;
|
|
getrlimit(RLIMIT_STACK, &rlim);
|
|
rlim.rlim_cur = 100*1024*1024;
|
|
setrlimit(RLIMIT_STACK, &rlim);
|
|
</pre>
|
|
This reads the current limits (soft and hard) using <b>getrlimit()</b>, then
|
|
attempts to increase the soft limit to 100Mb using <b>setrlimit()</b>. You must
|
|
do this before calling <b>pcre_exec()</b>.
|
|
</P>
|
|
<P>
|
|
PCRE has an internal counter that can be used to limit the depth of recursion,
|
|
and thus cause <b>pcre_exec()</b> to give an error code before it runs out of
|
|
stack. By default, the limit is very large, and unlikely ever to operate. It
|
|
can be changed when PCRE is built, and it can also be set when
|
|
<b>pcre_exec()</b> is called. For details of these interfaces, see the
|
|
<a href="pcrebuild.html"><b>pcrebuild</b></a>
|
|
and
|
|
<a href="pcreapi.html"><b>pcreapi</b></a>
|
|
documentation.
|
|
</P>
|
|
<P>
|
|
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. The <b>pcretest</b> test program has a command
|
|
line option (<b>-S</b>) that can be used to increase its stack.
|
|
</P>
|
|
<P>
|
|
Last updated: 29 June 2006
|
|
<br>
|
|
Copyright © 1997-2006 University of Cambridge.
|
|
<p>
|
|
Return to the <a href="index.html">PCRE index page</a>.
|
|
</p>
|