Re: [pcre-dev] [PATCH] PCRE2 on Windows

Top Page

Reply to this message
Author: Daniel Richard G.
To: pcre-dev
Subject: Re: [pcre-dev] [PATCH] PCRE2 on Windows
Hi Philip,

On Fri, 2018 Apr 27 17:55+0100, ph10@??? wrote:
> On Thu, 19 Apr 2018, I wrote:
> > > * Test 6 still crashes due to running out of stack space, only in
> > > this case, it's a very deep call stack that is the issue. I had
> > > to add /STACK:3000000 to the linker invocation for this issue to
> > > go away.
> >
> > This is DFA matching again. On Linux it runs with a 2MB stack on my
> > box. The Linux default is 8MB and I continue to be amazed that in
> > these days of gigabyte memories, default stack sizes are so small.
> > Not sure what to do about this yet, either. As you might know,
> > pcre2_match() was recently refactored so as not to make much use of
> > the stack. Perhaps something drastic along the same lines is needed
> > for pcre2_dfa_match(). Added to the "think about" list.
> I thought about it. I have just committed a patch (r932) which re-
> factors pcre2_dfa_match() such that it uses the heap for internal
> workspace vectors if more than an initial 30K vector on the stack is
> needed. This reduces the stack requirements and on my Linux box test 6
> runs with a 1Mb stack now.
> If you get a chance, please can you try this code to see if it fixes
> your problems on Windows. I think it will, because you had it working
> with reduced stack vector sizes and I have completely removed those
> vectors from the stack. There is a performance hit, but only if the
> pattern contains recursions, lookarounds, or atomic groups.

I tried out r932. This does address the _chkstk() failure mode; that
one is gone.

However, I am still seeing the deep call stack that requires the
/STACK:3000000 linker flag :(

Specifically, the error is "Unhandled exception at 0xDEADBEEF in
pcre2test.exe: 0xDEADBEEF: Stack overflow."

The call stack at the first failure is as follows:

    [repeat the last two many many times]

Visual Studio won't even show the bottom of the call stack for
some reason.

It appears to be test 8 which is failing in this way.

> That leaves only the Ctrl/Z issue. Since I can't remember why it's
> there, I think I will just change it to some other character.

If changing the input read to binary mode is deemed unacceptable, then
this should address the problem as well.


Daniel Richard G. || skunk@???
My ASCII-art .sig got a bad case of Times New Roman.