Hi Philip, On Fri, 2018 Apr 27 17:55+0100, p...@hermes.cam.ac.uk 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. || sk...@iskunk.org My ASCII-art .sig got a bad case of Times New Roman. -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev