Closed Bug 1063416 Opened 6 years ago Closed 6 years ago

irregexp can cause hang on some sites/some computer

Categories

(Core :: JavaScript Engine, defect)

x86_64
Windows 8
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: xunxun1982, Unassigned)

References

()

Details

When I update to 32.0 or using 20140904 nightly, firefox will hang when browsing some sites ( for example, http://www.iqiyi.com/v_19rrhjgusg.html )

After some seconds, it will show unrespond slow script, but 31.0 has not the problem.
I can reproduce the issue on my 1/5 computers (all are Win8).

The call stack is similar:

>	mozjs.dll!js::RegExpShared::execute(JSContext * cx, const wchar_t * chars, unsigned int length, unsigned int * lastIndex, js::MatchPairs & matches) 行 760	C++
 	mozjs.dll!ExecuteRegExpImpl(JSContext * cx, js::RegExpStatics * res, js::RegExpShared & re, JS::Handle<JSLinearString *> input, const wchar_t * chars, unsigned int length, unsigned int * lastIndex, js::MatchConduit & matches) 行 112	C++
 	mozjs.dll!js::ExecuteRegExp(JSContext * cx, JS::Handle<JSObject *> regexp, JS::Handle<JSString *> string, js::MatchConduit & matches, js::RegExpStaticsUpdate staticsUpdate) 行 602	C++
 	mozjs.dll!regexp_exec_impl(JSContext * cx, JS::Handle<JSObject *> regexp, JS::Handle<JSString *> string, js::RegExpStaticsUpdate staticsUpdate, JS::MutableHandle<JS::Value> rval) 行 640	C++
 	mozjs.dll!regexp_exec_impl(JSContext * cx, JS::CallArgs args) 行 661	C++
 	mozjs.dll!js::Invoke(JSContext * cx, JS::CallArgs args, js::MaybeConstruct construct) 行 455	C++
 	mozjs.dll!Interpret(JSContext * cx, js::RunState & state) 行 2566	C++
 	mozjs.dll!js::Invoke(JSContext * cx, JS::CallArgs args, js::MaybeConstruct construct) 行 474	C++
 	mozjs.dll!js::jit::DoCallFallback(JSContext * cx, js::jit::BaselineFrame * frame, js::jit::ICCall_Fallback * stub_, unsigned int argc, JS::Value * vp, JS::MutableHandle<JS::Value> res) 行 8140	C++
 	mozjs.dll!EnterBaseline(JSContext * cx, js::jit::EnterJitData & data) 行 126	C++
 	mozjs.dll!js::jit::EnterBaselineMethod(JSContext * cx, js::RunState & state) 行 155	C++
 	mozjs.dll!Interpret(JSContext * cx, js::RunState & state) 行 2605	C++
 	mozjs.dll!js::Invoke(JSContext * cx, JS::CallArgs args, js::MaybeConstruct construct) 行 474	C++
 	mozjs.dll!js_fun_call(JSContext * cx, unsigned int argc, JS::Value * vp) 行 1067	C++
 	mozjs.dll!js::Invoke(JSContext * cx, JS::CallArgs args, js::MaybeConstruct construct) 行 474	C++
 	mozjs.dll!Interpret(JSContext * cx, js::RunState & state) 行 2566	C++
 	mozjs.dll!js::Invoke(JSContext * cx, JS::CallArgs args, js::MaybeConstruct construct) 行 474	C++
 	mozjs.dll!js_fun_apply(JSContext * cx, unsigned int argc, JS::Value * vp) 行 1139	C++
 	mozjs.dll!js::Invoke(JSContext * cx, JS::CallArgs args, js::MaybeConstruct construct) 行 455	C++
 	mozjs.dll!Interpret(JSContext * cx, js::RunState & state) 行 2566	C++
 	mozjs.dll!js::Invoke(JSContext * cx, JS::CallArgs args, js::MaybeConstruct construct) 行 474	C++
 	mozjs.dll!js::jit::DoCallFallback(JSContext * cx, js::jit::BaselineFrame * frame, js::jit::ICCall_Fallback * stub_, unsigned int argc, JS::Value * vp, JS::MutableHandle<JS::Value> res) 行 8140	C++
 	mozjs.dll!EnterBaseline(JSContext * cx, js::jit::EnterJitData & data) 行 126	C++
 	mozjs.dll!js::jit::EnterBaselineMethod(JSContext * cx, js::RunState & state) 行 155	C++
 	mozjs.dll!Interpret(JSContext * cx, js::RunState & state) 行 2605	C++
 	mozjs.dll!js::Invoke(JSContext * cx, JS::CallArgs args, js::MaybeConstruct construct) 行 474	C++
 	mozjs.dll!js::Invoke(JSContext * cx, const JS::Value & thisv, const JS::Value & fval, unsigned int argc, const JS::Value * argv, JS::MutableHandle<JS::Value> rval) 行 511	C++
 	mozjs.dll!JS::Call(JSContext * cx, JS::Handle<JS::Value> thisv, JS::Handle<JS::Value> fval, const JS::HandleValueArray & args, JS::MutableHandle<JS::Value> rval) 行 5215	C++
 	xul.dll!nsGenericHTMLElement::QueryInterface(const nsID & aIID, void * * aInstancePtr) 行 213	C++

It hangs in result = irregexp::ExecuteCode(cx, jitCode, chars, start, length, &matches);

so I think it's caused by bug 976446.
The problem doesn't reproduce for me, but that's probably because the video that's supposed to be displayed isn't available in my region due to copyright issues.

In any case, I'm going to close this bug because it can be caused by one of two things:

Either, our previous regexp engine invalidly bailed on the used expression and just reported a non-match (bug 953013), where irregexp tries to actually run the whole test. In that case, we'd simply be in a situation where our behavior is more correct now than before, and we're not going to change things.

The other possible explanation is that we have yet to re-implement a few optimizations. That is tracked in bug 1055402.

(For future reference: the term "hang" is commonly used to describe situations where the browser really doesn't respond anymore. The slow script dialog is the expected behavior for cases where a website's script execution takes too long [or possible doesn't terminate at all].)
Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Resolution: --- → INVALID
(In reply to xunxun from comment #0)
> When I update to 32.0 or using 20140904 nightly, firefox will hang when
> browsing some sites ( for example, http://www.iqiyi.com/v_19rrhjgusg.html )

You can try to toggle javascript.options.native_regexp pref to true on the about:config page. I can reproduce this problem if I set that pref to false.
> I can reproduce this problem if I set that pref to false.

If you set that pref to false, that disables JIT compilation of regexps, forcing them into a slow interpreted mode, no?  Why would you set it to false?
(In reply to Boris Zbarsky [:bz] from comment #3)
> > I can reproduce this problem if I set that pref to false.
> 
> If you set that pref to false, that disables JIT compilation of regexps,
> forcing them into a slow interpreted mode, no?  Why would you set it to
> false?

Yes, you are right. I'm just guessing, maybe xunxun's pref.js has been changed by accident.
(In reply to ziyunfei from comment #4)
> (In reply to Boris Zbarsky [:bz] from comment #3)
> > > I can reproduce this problem if I set that pref to false.
> > 
> > If you set that pref to false, that disables JIT compilation of regexps,
> > forcing them into a slow interpreted mode, no?  Why would you set it to
> > false?
> 
> Yes, you are right. I'm just guessing, maybe xunxun's pref.js has been
> changed by accident.

No, I created the new profile to test it.
You need to log in before you can comment on or make changes to this bug.