wsc - Is the RegExp object in VBScript Thread Safe when used inside a Windows Scripting Component -


i've trying track down issue legacy windows scripting component use. looking @ several memory dumps in windbg have found alot of threads, in fact looks 50% of apps threads waiting thread complete. thread has long stack below. thread doing work regexp object, question regexp thread safe?

it looks isn't other threads waiting on want before jump conclusions , have struggled find real information online.

vbscript!regexpexec::popgreedystar+3a     vbscript!regexpexec::fexecaux+639     vbscript!regexpexec::fexec+1f     vbscript!regexpexec::exec+5a0     vbscript!regexpexec::replaceusingstring+2d     vbscript!cregexp::origreplace+14e     vbscript!cregexp::replace+80     oleaut32!dispcallfunc+16a     oleaut32!ctypeinfo2::invoke+234     vbscript!cregexp::invoke+24     vbscript!idispatchinvoke2+b2     vbscript!idispatchinvoke+59     vbscript!invokedispatch+13a     vbscript!invokebyname+42     vbscript!cscriptruntime::runnoeh+22b2     vbscript!cscriptruntime::run+62     vbscript!cscriptentrypoint::call+51     vbscript!cscriptruntime::runnoeh+1e02     vbscript!cscriptruntime::run+62     vbscript!cscriptentrypoint::call+51     vbscript!csession::execute+c8     vbscript!nametbl::invokeex+516     scrobj!doinvoke+2c     scrobj!nametable::invokeex+e6     scrobj!comdispatchex::invokeex+25     scrobj!doinvoke+2c     scrobj!invokemember+a3     scrobj!nametable::invokeex+aa     scrobj!comdexhandler::inner::invokeex+25     vbscript!idispatchexinvokeex2+a9     vbscript!idispatchexinvokeex+56     vbscript!invokedispatch+101     vbscript!invokebyname+42     vbscript!cscriptruntime::runnoeh+234c     vbscript!cscriptruntime::run+62     vbscript!cscriptentrypoint::call+51     vbscript!cscriptruntime::runnoeh+1bbd     vbscript!cscriptruntime::run+62     vbscript!cscriptentrypoint::call+51     vbscript!csession::execute+c8     vbscript!nametbl::invokeex+516     vbscript!idispatchexinvokeex2+a9     vbscript!idispatchexinvokeex+56     vbscript!invokedispatch+101     vbscript!invokebyname+42     vbscript!cscriptruntime::runnoeh+234c     vbscript!cscriptruntime::run+62     vbscript!cscriptentrypoint::call+51     vbscript!cscriptruntime::runnoeh+1bbd     vbscript!cscriptruntime::run+62     vbscript!cscriptentrypoint::call+51     vbscript!cscriptruntime::runnoeh+1bbd     vbscript!cscriptruntime::run+62     vbscript!cscriptentrypoint::call+51     vbscript!cscriptruntime::runnoeh+1bbd     vbscript!cscriptruntime::run+62     vbscript!cscriptentrypoint::call+51     vbscript!csession::execute+c8     vbscript!nametbl::invokeex+516     vbscript!idispatchexinvokeex2+a9     vbscript!idispatchexinvokeex+56     vbscript!invokedispatch+101     vbscript!invokebyname+42     vbscript!cscriptruntime::runnoeh+234c     vbscript!cscriptruntime::run+62     vbscript!cscriptentrypoint::call+51     vbscript!cscriptruntime::runnoeh+1beb     vbscript!cscriptruntime::run+62     vbscript!cscriptentrypoint::call+51     vbscript!csession::execute+c8     vbscript!colescript::executependingscripts+144     vbscript!colescript::setscriptstate+14d  

i don't know thread safety in case. but, looking @ situation, i'd it's more problem in regex itself. first thing at. it's possible create regex causes stack overflow, or very long runtime, because of quantifiers , re-starts.

from the pcre man page:

   when pattern contains unlimited repeat inside   subpattern     can    repeated   unlimited number of times, use of    atomic group way avoid  failing  matches  taking     long time indeed. pattern       (\d+|<\d+>)*[!?]     matches   unlimited number of substrings either consist of non-    digits, or digits enclosed in <>, followed either ! or  ?.  when     matches, runs quickly. however, if applied       aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa      takes   long  time  before reporting failure. because    string can divided between internal \d+ repeat ,  external    *  repeat  in   large  number of ways, , have tried. (the    example uses [!?] rather single character @   end,  because    both  pcre  ,  perl have optimization allows fast failure    when single character used. remember last single  charac-    ter   required match, , fail if not present    in string.)  

now, regexp object available in windows script host not pcre, believe same behavior have apply it.

so, check regex nested unlimited quantifiers.


Comments

Popular posts from this blog

python - Scipy curvefit RuntimeError:Optimal parameters not found: Number of calls to function has reached maxfev = 1000 -

c# - How to add a new treeview at the selected node? -

java - netbeans "Please wait - classpath scanning in progress..." -