[pcre-dev] [Bug 1642] Tests fail due to stack space being limited to 16 M

[admin]

https://bugs.exim.org/show_bug.cgi?id=1642

--- Comment #5 from Zoltan Herczeg hzmes...@freemail.hu ---
I am sorry that was the public function. The static private recursive function
is the match:

(gdb) disassemble match
Dump of assembler code for function match:
   0x005399d2 +0: push   %rbp
   0x005399d3 +1: mov%rsp,%rbp
   0x005399d6 +4: push   %r15
   0x005399d8 +6: push   %r14
   0x005399da +8: push   %r13
   0x005399dc +10:push   %r12
   0x005399de +12:push   %rbx
   0x005399df +13:sub$0x358,%rsp

That is 912 (856+7*8) bytes / frame here.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/pcre-dev 

[pcre-dev] [Bug 1642] Tests fail due to stack space being limited to 16 M

[admin]

https://bugs.exim.org/show_bug.cgi?id=1642

--- Comment #7 from Zoltan Herczeg hzmes...@freemail.hu ---
 That is 3432 (3424 + 1*8) bytes per frame.  A wee bit more, I'd say.

Actually +2*8 because the return address is also stored on the stack. Anyway,
that is huge. Too huge. I just realized that my pcre2 is compiled with -O0.
With -O3, the stack is only 416 bytes (only half of the previous value). I
don't think clang is that worse compared to GCC. Perhaps the binary contains
some debug stuff? Address sanitizer or some aggressive inlining? Could you try
to compile it with different compiler optimizations? Adding __attribute__
((noinline)) before match() in pcre2_match.c?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/pcre-dev 

[pcre-dev] [Bug 1642] Tests fail due to stack space being limited to 16 M

[admin]

https://bugs.exim.org/show_bug.cgi?id=1642

--- Comment #8 from Elliot Saba staticfl...@gmail.com ---
Putting __attribute__((noinline)) on line 579 between the static int and
match(REGISTER... doesn't change anything.

My ./configure invocation looks like this (stripping out the --prefix and
--libdir stuff):

$ ./configure --build=x86_64-apple-darwin14.3.0 F77=gfortran
-mmacosx-version-min=10.7 -m64 CC=clang -stdlib=libc++
-mmacosx-version-min=10.7 -m64  CXX=clang++ -stdlib=libc++
-mmacosx-version-min=10.7 -m64  --enable-jit


The compile line coming out of my setup when running `make V=1` is such:

./libtool  --tag=CC   --mode=compile clang -stdlib=libc++
-mmacosx-version-min=10.7 -m64  -DHAVE_CONFIG_H -I. -I./src  -I./src -I./src 
-DPCRE2_CODE_UNIT_WIDTH=8 -fvisibility=hidden -D_THREAD_SAFE -pthread
-I/Users/sabae/local/include -I/usr/local/include -MT
src/libpcre2_8_la-pcre2_compile.lo -MD -MP -MF
src/.deps/libpcre2_8_la-pcre2_compile.Tpo -c -o
src/libpcre2_8_la-pcre2_compile.lo `test -f 'src/pcre2_compile.c'


If I add -O3 to the compile flags, I get something much more reasonable and
the tests pass!

(lldb) disassemble -n match -c 10
libpcre2-8.0.dylib`match:
0x100065610:  pushq  %rbp
0x100065611:  movq   %rsp, %rbp
0x100065614:  pushq  %r15
0x100065616:  pushq  %r14
0x100065618:  pushq  %r13
0x10006561a:  pushq  %r12
0x10006561c:  pushq  %rbx
0x10006561d:  subq   $0x1d8, %rsp


So that's only 528 bytes.  With these settings, the tests pass just fine. 
Should that be the official solution, or is my patch still valuable?  I will
admit, it is slightly annoying that there is a seemingly innocuous set of
compiler options (no optimization flags present) that will cause the test suite
to fail.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/pcre-dev