Author: Graycode Date: To: pcre-dev Subject: Re: [pcre-dev] Calculated match recursion stack size
Late last night I was able to get though a build and do a bit of
testing with the code from yesterday's trunk.
It seemed to worked fine. Using a Microsoft compiler and building
for (non-debug) release mode optimized for speed (/O2) it showed:
Compiled with
8-bit support only
UTF-8 support
No Unicode properties support
No just-in-time compiler support
Newline sequence is LF
\R matches all Unicode newlines
Internal link size = 2
POSIX malloc threshold = 30
Default match limit = 50000
Default recursion depth limit = 2500
Match recursion uses stack: frame size = 340 bytes
(The POSIX threshold, match limit, and recursion depth shown above are
non-standard values that I overrode in my config.h)
The "340 bytes" result matches what I was getting with the patch, minus
accounting for those 2 extra ints.
======
Compiling the PCRE library instead for debug mode (/Od) shows:
Match recursion uses stack: frame size = 940 bytes
940 is the correct value and "normal" behavior in that situation. A
compiler's debug mode will not optimize the sequence of storage for
better alignment, and it often puts variables at a gross alignment.
Obviously this causes code built for debug to get a stack fault much
sooner in a recursive process than a compiler's optimized code.
I touched on this briefly in a pre-dev reply about Bug# 1180 on
Nov 28:
> Also be careful of the stack when using a version built for debug.
> Disabling optimization with /Od may have a profound impact on stack
> requirements. I've seen the recursive PCRE match() function use much
> more than twice its normal stack with /Od vs. having /O1 or /O2. It's
> not unique to PCRE, it may be the way MSVC initially assigns default
> alignment.
To me this adds weight to trying to have this method to calculate the
stack requirement as it truly exists at run-time.
I'm guessing you're compiling gcc with debug and not for release mode,
and that's why the values you're seeing are unexpected. Hopefully
you will see a more sane and consistent result with an optimized
compile vs. debug.
======
(PS) I had some difficulty building pcretest. Paragraph (10) of
NON-UNIX-USE now mentions it needs to be linked with pcre_printint,
(different from 8.21) but even doing that yielded unresolved externals.
pcre_printint.obj : error LNK2001: unresolved external symbol __pcre_OP_lengths
pcre_printint.obj : error LNK2001: unresolved external symbol __pcre_utf8_table3
pcre_printint.obj : error LNK2001: unresolved external symbol __pcre_utf8_table4
It turns out that pcretest also needed to be linked with pcre_tables.
Unless I did something wrong in my hand-crafted build, mention of that
may be needed in the NON-UNIX-USE document.
======
Today I'm going to try the current version in the latest trunk
having your new set of modifications.
