Closed Bug 1523564 Opened 5 years ago Closed 2 years ago

Disabling the baseline jit makes us crash almost immediately

Categories

(Core :: JavaScript Engine: JIT, defect, P2)

ARM64
Android
defect

Tracking

()

RESOLVED INACTIVE
Tracking Status
firefox67 --- fix-optional

People

(Reporter: lth, Unassigned)

Details

Local debug-opt build running in the android studio debugger. The second I disable the JS baseline JIT (without disabling Ion first) I hit an assertion inside as<JSFunction>() called from EnterJit, stack looks like this:

AnnotateMozCrashReason(char const*) Assertions.h:38
JSFunction& JSObject::as<JSFunction>() JSObject.h:511
EnterJit(JSContext*, js::RunState&, unsigned char*) Jit.cpp:65
js::jit::MaybeEnterJit(JSContext*, js::RunState&) Jit.cpp:168
Interpret(JSContext*, js::RunState&) Interpreter.cpp:3115
js::RunScript(JSContext*, js::RunState&) Interpreter.cpp:421
js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct) Interpreter.cpp:561
js::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>) Interpreter.cpp:604
JS::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, JS::HandleValueArray const&, JS::MutableHandle<JS::Value>) jsapi.cpp:2623
mozilla::dom::Function::Call(JSContext*, JS::Handle<JS::Value>, nsTArray<JS::Value> const&, JS::MutableHandle<JS::Value>, mozilla::ErrorResult&) FunctionBinding.cpp:41
void mozilla::dom::Function::Call<nsCOMPtr<nsISupports> >(nsCOMPtr<nsISupports> const&, nsTArray<JS::Value> const&, JS::MutableHandle<JS::Value>, mozilla::ErrorResult&, char const*, mozilla::dom::CallbackObject::ExceptionHandling, JS::Realm*) FunctionBinding.h:73
nsGlobalWindowInner::RunTimeoutHandler(mozilla::dom::Timeout*, nsIScriptContext*) nsGlobalWindowInner.cpp:6051
mozilla::dom::TimeoutManager::RunTimeout(mozilla::TimeStamp const&, mozilla::TimeStamp const&, bool) TimeoutManager.cpp:917
mozilla::dom::TimeoutExecutor::MaybeExecute() TimeoutExecutor.cpp:177
mozilla::dom::TimeoutExecutor::Notify(nsITimer*) TimeoutExecutor.cpp:241
non-virtual thunk to mozilla::dom::TimeoutExecutor::Notify(nsITimer*) TimeoutExecutor.cpp:0
nsTimerImpl::Fire(int) nsTimerImpl.cpp:562
nsTimerEvent::Run() TimerThread.cpp:260
nsThread::ProcessNextEvent(bool, bool*) nsThread.cpp:1161
NS_ProcessNextEvent(nsIThread*, bool) nsThreadUtils.cpp:474
mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) MessagePump.cpp:110
MessageLoop::RunInternal() message_loop.cc:315
MessageLoop::RunHandler() message_loop.cc:308
MessageLoop::Run() message_loop.cc:290
nsBaseAppShell::Run() nsBaseAppShell.cpp:137
nsAppStartup::Run() nsAppStartup.cpp:271
XREMain::XRE_mainRun() nsAppRunner.cpp:4392
XREMain::XRE_main(int, char**, mozilla::BootstrapConfig const&) nsAppRunner.cpp:4530
XRE_main(int, char**, mozilla::BootstrapConfig const&) nsAppRunner.cpp:4614
::GeckoStart(JNIEnv *, char **, int, const mozilla::StaticXREAppData &) nsAndroidStartup.cpp:47
Java_org_mozilla_gecko_mozglue_GeckoLoader_nativeRun 0x00000071f987ae58
nativeRun 0x00000071fa07c2c8
art_quick_invoke_static_stub 0x0000007210649e50
art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*) 0x00000072101db5d4
art::interpreter::ArtInterpreterToCompiledCodeBridge(art::Thread*, art::ArtMethod*, art::ShadowFrame*, unsigned short, art::JValue*) 0x000000721039a4a0
bool art::interpreter::DoCall<true, false>(art::ArtMethod*, art::Thread*, art::ShadowFrame&, art::Instruction const*, unsigned short, art::JValue*) 0x00000072103959dc
bool art::interpreter::DoInvoke<(art::InvokeType)0, true, false>(art::Thread*, art::ShadowFrame&, art::Instruction const*, unsigned short, art::JValue*) 0x00000072103c77d4
art::JValue art::interpreter::ExecuteSwitchImpl<false, false>(art::Thread*, art::DexFile::CodeItem const*, art::ShadowFrame&, art::JValue, bool) 0x00000072103c1a30
art::interpreter::Execute(art::Thread*, art::DexFile::CodeItem const*, art::ShadowFrame&, art::JValue, bool) 0x0000007210374c68
artQuickToInterpreterBridge 0x0000007210624454
art_quick_to_interpreter_bridge 0x0000007210652d10
art_quick_invoke_stub 0x0000007210649b8c
art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*) 0x00000072101db598
art::InvokeWithArgArray(art::ScopedObjectAccessAlreadyRunnable const&, art::ArtMethod*, art::ArgArray*, art::JValue*, char const*) 0x000000721056ddcc
art::InvokeVirtualOrInterfaceWithJValues(art::ScopedObjectAccessAlreadyRunnable const&, _jobject*, _jmethodID*, jvalue*) 0x000000721056f00c
art::Thread::CreateCallback(void*) 0x0000007210595ab8
__pthread_start(void*) 0x000000729307ad10
__start_thread 0x0000007293031ba8

Oh and BTW, after that we'll have a crash-on-startup every time.

In general, fiddling with the Ion pref tends to create crashes and crash-on-shutdown loops and crash-on-startup loops; if I manage to come up with STR I will post them.

Setting as P2 as this is not supposed to be a common user action. However we should get this fixed, as this is not supposed to trap our users from updating.

Priority: -- → P2

Last time I tried something similar through the about:config toggles, I did not had any such issues.
Also, since then we got WarpBuilder, which builds on top Baseline collected info, which probably revisited this issue.

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.