From 440157cbbe796b6b9a44a3de46bbb93d0cb5a77c Mon Sep 17 00:00:00 2001 From: Sergei Golubchik Date: Thu, 5 Oct 2017 15:01:38 +0200 Subject: MDEV-13412 main.func_regexp_pcre fails in buildbot on ppc64le Caused by 2fcd8c12522. It used the documented pcre API -pcre_exec(NULL, NULL, NULL, -999, -999, 0, NULL, 0) to calculate the pcre stack frame size. Unfortunately, modern compilers broke it by cloning and inlining pcre match() function. 2fcd8c12522 tried to workaround it by setting the stack frame size to at least 500. It didn't work, 500 is not a universal constant. Now we fix our copy of pcre to not inline or clone match() - so that stack frame detection would work again - and detect at cmake time whether system pcre is broken or usable. Also use stack, not (much slower) malloc in bundled pcre, unless on Windows --- pcre/CMakeLists.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'pcre/CMakeLists.txt') diff --git a/pcre/CMakeLists.txt b/pcre/CMakeLists.txt index 30b06a46fef..31d4358f14d 100644 --- a/pcre/CMakeLists.txt +++ b/pcre/CMakeLists.txt @@ -128,9 +128,9 @@ SET(PCREGREP_BUFSIZE "20480" CACHE STRING SET(PCRE_NEWLINE "LF" CACHE STRING "What to recognize as a newline (one of CR, LF, CRLF, ANY, ANYCRLF).") -# MARIADB: Changed the default from OFF to ON as pcre_test.bat on Windows -# MARIADB: fails complaining about too small stack size on Windows. -SET(PCRE_NO_RECURSE ON CACHE BOOL +# Windows has much smaller stack (pcre recursion limit of 112, vs +# 250-500 on Linuxes) +SET(PCRE_NO_RECURSE "${WIN32}" CACHE BOOL "If ON, then don't use stack recursion when matching. See NO_RECURSE in config.h.in for details.") SET(PCRE_POSIX_MALLOC_THRESHOLD "10" CACHE STRING -- cgit v1.2.1