658211 - TI: Crash [@ JSC::Yarr::RegexCodeBlock::execute]

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

Attachment: shell testcase, unpack, chdir and run main.js with options "-j -n -m -a"

The attached testcase crashes on TI revision 4dff743ec04d (unpack, chdir and run with -j -m -n -a), tested on 64 bit.

Backtrace:

==17739== Invalid read of size 4
==17739==    at 0x41BE010: ???
==17739==    by 0x43D11A: JSC::Yarr::RegexCodeBlock::execute(unsigned short const*, unsigned int, unsigned int, int*) (RegexJIT.h:78)
==17739==    by 0x43D1D8: JSC::Yarr::executeRegex(JSContext*, JSC::Yarr::RegexCodeBlock&, unsigned short const*, unsigned int, unsigned int, int*, int) (RegexJIT.h:105)
==17739==    by 0x43DB39: js::RegExp::executeInternal(JSContext*, js::RegExpStatics*, JSString*, unsigned long*, bool, js::Value*) (jsregexpinlines.h:365)
==17739==    by 0x43D2CB: js::RegExp::execute(JSContext*, js::RegExpStatics*, JSString*, unsigned long*, bool, js::Value*) (jsregexpinlines.h:162)
==17739==    by 0x5A875F: DoMatch(JSContext*, js::RegExpStatics*, js::Value*, JSString*, RegExpPair const&, bool (*)(JSContext*, js::RegExpStatics*, unsigned long, void*), void*, MatchControlFlags) (jsstr.cpp:1833)
==17739==    by 0x5AA8D9: str_replace_regexp(JSContext*, unsigned int, js::Value*, ReplaceData&) (jsstr.cpp:2405)
==17739==    by 0x5AB19F: js::str_replace(JSContext*, unsigned int, js::Value*) (jsstr.cpp:2562)
==17739==    by 0x4F3DFF: js::CallJSNative(JSContext*, int (*)(JSContext*, unsigned int, js::Value*), unsigned int, js::Value*) (jscntxtinlines.h:293)
==17739==    by 0x7173D2: CallCompiler::generateNativeStub() (MonoIC.cpp:839)
==17739==    by 0x711FB6: js::mjit::ic::NativeCall(js::VMFrame&, js::mjit::ic::CallICInfo*) (MonoIC.cpp:1108)
==17739==    by 0x41BC9C7: ???
==17739==  Address 0xb54ffe is not stack'd, malloc'd or (recently) free'd

Comment 6

[Brian Hackett [Laid off!]]

Lots of corruption potential here, problem introduced by the type barriers where if we added a barrier at a bytecode which did not previously have one, we only triggered recompilation on that script and not any others which the script was inlined into.  This scenario already comes up in a couple other situations, patch below cleans things up so that it is easy to trigger recompilation on all scripts which a given script was inlined into.

http://hg.mozilla.org/projects/jaegermonkey/rev/b6cf7f39177f

Comment 7

[Christian Holler (:decoder)]

A testcase for this bug was automatically identified at js/src/jit-test/tests/jaeger/recompile/bug658211.js.