在Windows腳本組件中使用VBScript中的RegExp對象時線程安全

Question

我試圖跟蹤我們使用的傳統Windows腳本組件的問題。看看WinDbg中的幾個內存轉儲我發現很多線程，實際上看起來應用程序線程的50％都在等待另一個線程完成。這個線程有一個很長的堆棧，在下面。這個線程正在做一些RegExp對象的工作，所以我的問題是現在RegExp線程安全嗎？

看起來它並不是來自所有等待它的其他線程，但我希望在我得出結論並努力在網上找到任何真實信息之前確定它。

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 

Answer 1

我不知道你的情況下的線程安全性。但是，看看你的情況，我認爲它更可能是正則表達式本身的一個問題。那將是我首先想到的。由於量詞和重新開始，可以創建一個本身導致堆棧溢出的正則表達式，或者運行時間非常長的正則表達式。

從the pcre man page：

When a pattern contains an unlimited repeat inside a subpattern that 
    can itself be repeated an unlimited number of times, the use of an 
    atomic group is the only way to avoid some failing matches taking a 
    very long time indeed. The pattern 

    (\D+|<\d+>)*[!?] 

    matches an unlimited number of substrings that either consist of non- 
    digits, or digits enclosed in <>, followed by either ! or ?. When it 
    matches, it runs quickly. However, if it is applied to 

    aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 

    it takes a long time before reporting failure. This is because the 
    string can be divided between the internal \D+ repeat and the external 
    * repeat in a large number of ways, and all have to be tried. (The 
    example uses [!?] rather than a single character at the end, because 
    both PCRE and Perl have an optimization that allows for fast failure 
    when a single character is used. They remember the last single charac- 
    ter that is required for a match, and fail early if it is not present 
    in the string.) 

現在，在Windows腳本宿主提供的RegExp對象不PCRE，但我相信同樣的行爲，就必須適用於它。

因此，檢查你的正則表達式的嵌套無限量詞。