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:
add_to_class_internal()
add_to_class()
compile_branch()
compile_regex()
compile_branch()
compile_regex()
[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
--
Daniel Richard G. || skunk@???
My ASCII-art .sig got a bad case of Times New Roman.
