[Libreoffice-commits] core.git: Branch 'libreoffice-4-1' - i18npool/source

[Eike Rathke]

 i18npool/source/search/textsearch.cxx |   26 ++++++++++++++++++++++++--
 1 file changed, 24 insertions(+), 2 deletions(-)

New commits:
commit b103d14aaac3d96f7b60ce1baa9c581a102a1e63
Author: Eike Rathke <erack at redhat.com>
Date:   Tue Nov 26 00:18:46 2013 +0100

    set a 23 enigma timeout at RegexMatcher, fdo#70627
    
    Change-Id: I390bfec0d36dcc9529785e97994dad2b0704dc80
    (cherry picked from commit d838ea200e7d6060d4a759616f9e1fcbf3c36c8e)
    Reviewed-on: https://gerrit.libreoffice.org/6808
    Reviewed-by: Miklos Vajna <vmiklos at collabora.co.uk>
    Tested-by: Miklos Vajna <vmiklos at collabora.co.uk>

diff --git a/i18npool/source/search/textsearch.cxx b/i18npool/source/search/textsearch.cxx
index 7762832..91a770b 100644
--- a/i18npool/source/search/textsearch.cxx
+++ b/i18npool/source/search/textsearch.cxx
@@ -764,8 +764,30 @@ void TextSearch::RESrchPrepare( const ::com::sun::star::util::SearchOptions& rOp
     aChevronMatcherE.reset();
 #endif
     pRegexMatcher = new RegexMatcher( aIcuSearchPatStr, nIcuSearchFlags, nIcuErr);
-    if( nIcuErr)
-        { delete pRegexMatcher; pRegexMatcher = NULL;}
+    if (nIcuErr)
+    {
+        delete pRegexMatcher;
+        pRegexMatcher = NULL;
+    }
+    else
+    {
+        // Pathological patterns may result in exponential run time making the
+        // application appear to be frozen. Limit that. Documentation for this
+        // call says
+        // https://ssl.icu-project.org/apiref/icu4c/classicu_1_1RegexMatcher.html#a6ebcfcab4fe6a38678c0291643a03a00
+        // "The units of the limit are steps of the match engine.
+        // Correspondence with actual processor time will depend on the speed
+        // of the processor and the details of the specific pattern, but will
+        // typically be on the order of milliseconds."
+        // Just what is a good value? 42 is always an answer ... the 23 enigma
+        // as well.. which on the dev's machine is roughly 50 seconds with the
+        // pattern of fdo#70627.
+        /* TODO: make this a configuration settable value and possibly take
+         * complexity of expression into account and maybe even length of text
+         * to be matched; currently (2013-11-25) that is at most one 64k
+         * paragraph per RESrchFrwrd()/RESrchBkwrd() call. */
+        pRegexMatcher->setTimeLimit( 23*1000, nIcuErr);
+    }
 }
 
 //---------------------------------------------------------------------------