Closed Bug 1565930 Opened 6 years ago Closed 6 years ago

Hit MOZ_CRASH(*** Compartment mismatch 0x7f1020604060 vs. 0x7f1024e03380 at argument 1) on startup

Categories

(Core :: DOM: Core & HTML, defect, P2)

defect

Tracking

()

RESOLVED FIXED
mozilla70
Tracking Status
firefox-esr60 --- unaffected
firefox-esr68 --- fixed
firefox68 --- wontfix
firefox69 --- fixed
firefox70 --- fixed

People

(Reporter: emilio, Assigned: smaug)

References

(Regression)

Details

(Keywords: regression)

Crash Data

Attachments

(4 files, 1 obsolete file)

I wanted to debug something else, but when I ran my debug build I got an assertion failure like this on a content process on startup and, shortly after, a crash in the parent because of bug 1565927.

DumpJSStack() says the JS stack is empty. Native stack is:

#0  0x0000000070000002 in  ()
#1  0x00007f1041ecfe94 in _raw_syscall () at /usr/local/bin/../lib64/rr/librrpreload.so
#2  0x00007f1041ece5bb in syscall_hook_internal (call=<optimized out>) at /home/emilio/src/moz/rr/src/preload/syscallbuf.c:1879
#3  0x00007f1041eca9a6 in syscall_hook (call=0x681fffa0) at /home/emilio/src/moz/rr/src/preload/syscallbuf.c:2927
#4  0x00007f1041eca09a in _syscall_hook_trampoline () at /usr/local/bin/../lib64/rr/librrpreload.so
#5  0x00007f1041eca0ca in __morestack () at /usr/local/bin/../lib64/rr/librrpreload.so
#6  0x00007f1041eca0e5 in _syscall_hook_trampoline_48_3d_00_f0_ff_ff () at /usr/local/bin/../lib64/rr/librrpreload.so
#7  0x00007f1041a4913d in write () at /lib64/libc.so.6
#8  0x00007f10419d9d4d in _IO_file_write@@GLIBC_2.2.5 () at /lib64/libc.so.6
#9  0x00007f10419d90a6 in new_do_write () at /lib64/libc.so.6
#10 0x00007f10419da47e in __GI__IO_file_xsputn () at /lib64/libc.so.6
#11 0x00007f10419c65d9 in buffered_vfprintf () at /lib64/libc.so.6
#12 0x00007f10419c3694 in __vfprintf_internal () at /lib64/libc.so.6
#13 0x00007f10419b01fa in fprintf () at /lib64/libc.so.6
#14 0x00007f103c4d0912 in MOZ_ReportCrash(char const*, char const*, int) (aStr=0x95 <error: Cannot access memory at address 0x95>, aFilename=0xffffffffffffffff <error: Cannot access memory at address 0xffffffffffffffff>, aLine=0)
    at /home/emilio/src/moz/gecko-2/obj-debug/dist/include/mozilla/Assertions.h:180
#15 0x00007f103c4e3387 in MOZ_Crash(char const*, int, char const*) (aLine=45, aReason=0x55dd36623660 <sPrintfCrashReason> "*** Compartment mismatch 0x7f1020604060 vs. 0x7f1024e03380 at argument 1", aFilename=<optimized out>)
    at /home/emilio/src/moz/gecko-2/obj-debug/dist/include/mozilla/Assertions.h:310
#16 0x00007f103c4e3387 in js::ContextChecks::fail(JS::Compartment*, JS::Compartment*, int) (c1=<optimized out>, c2=<optimized out>, argIndex=<optimized out>) at /home/emilio/src/moz/gecko-2/js/src/vm/JSContext-inl.h:44
#17 0x00007f103c4e3387 in js::ContextChecks::check(JS::Compartment*, int) (this=<optimized out>, c=<optimized out>, argIndex=1) at /home/emilio/src/moz/gecko-2/js/src/vm/JSContext-inl.h:60
#18 0x00007f103c4e3387 in js::ContextChecks::check(JSObject*, int) (this=<optimized out>, obj=(JSObject *) 0x1c2a2a24f680 [object Error], argIndex=1) at /home/emilio/src/moz/gecko-2/js/src/vm/JSContext-inl.h:74
#19 0x00007f103cb2d0d0 in JSContext::checkImpl<JS::Handle<JS::Value>>(int, JS::Handle<JS::Value> const&) (this=0x7f1024e2d000, argIndex=1, head=...) at /home/emilio/src/moz/gecko-2/js/src/vm/JSContext-inl.h:185
#20 0x00007f103cb2d0d0 in JSContext::checkImpl<JS::Handle<JSObject*>, JS::Handle<JS::Value> >(int, JS::Handle<JSObject*> const&, JS::Handle<JS::Value> const&) (this=0x7f1024e2d000, argIndex=0, head=..., tail=...)
    at /home/emilio/src/moz/gecko-2/js/src/vm/JSContext-inl.h:186
#21 0x00007f103cb2d0d0 in JSContext::check<JS::Handle<JSObject*>, JS::Handle<JS::Value> >(JS::Handle<JSObject*> const&, JS::Handle<JS::Value> const&) (this=0x7f1024e2d000, args=..., args=...)
    at /home/emilio/src/moz/gecko-2/js/src/vm/JSContext-inl.h:193
#22 0x00007f103cb2d0d0 in ResolveOrRejectPromise(JSContext*, JS::Handle<JSObject*>, JS::Handle<JS::Value>, bool) (cx=0x7f1024e2d000, promiseObj=..., resultOrReason_=..., reject=<optimized out>)
    at /home/emilio/src/moz/gecko-2/js/src/jsapi.cpp:3918
#23 0x00007f103ae7f21e in mozilla::dom::Promise::MaybeReject(JSContext*, JS::Handle<JS::Value>) (this=<optimized out>, aCx=0x2, aValue=$JS::Value((JSObject *) 0x1c2a2a24f680 [object Error]))
    at /home/emilio/src/moz/gecko-2/dom/promise/Promise.cpp:309
#24 0x00007f103ae802e6 in mozilla::dom::Promise::MaybeRejectWithClone(JSContext*, JS::Handle<JS::Value>) (this=0x7f1023050340, aCx=0x7ffcf0f63530, aValue=$JS::Value((JSObject *) 0x1c2a2a24f680 [object Error]))
    at /home/emilio/src/moz/gecko-2/dom/promise/Promise.cpp:573
#25 0x00007f103ae8235f in mozilla::dom::(anonymous namespace)::PromiseNativeHandlerShim::RejectedCallback(JSContext*, JS::Handle<JS::Value>)
    (this=0x7f1024f5cca0, aCx=0x7ffcf0f63530, aValue=<error reading variable: Cannot access memory at address 0x95>) at /home/emilio/src/moz/gecko-2/dom/promise/Promise.cpp:394
#26 0x00007f103ae82700 in mozilla::dom::NativeHandlerCallback(JSContext*, unsigned int, JS::Value*) (aCx=0x7ffcf0f63530, aArgc=<optimized out>, aVp=<optimized out>) at /home/emilio/src/moz/gecko-2/dom/promise/Promise.cpp:344
#27 0x00007f103c4dd9c5 in CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), JS::CallArgs const&)
    (cx=0x7f1024e2d000, native=0x7f103ae825a8 <mozilla::dom::NativeHandlerCallback(JSContext*, unsigned int, JS::Value*)>, args=...) at /home/emilio/src/moz/gecko-2/js/src/vm/Interpreter.cpp:448
#28 0x00007f103c4cd70f in js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct) (cx=0x7f1024e2d000, args=..., construct=js::NO_CONSTRUCT) at /home/emilio/src/moz/gecko-2/js/src/vm/Interpreter.cpp:540
#29 0x00007f103c4ce33d in js::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>) (cx=0x2, fval=..., thisv=..., args=..., rval=...)
    at /home/emilio/src/moz/gecko-2/js/src/vm/Interpreter.cpp:611
#30 0x00007f103c5b371c in js::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, JS::Handle<JS::Value>, JS::MutableHandle<JS::Value>)
    (cx=0x7f1024e2d000, fval=$JS::Value((JSObject *) 0x36573b8a96f0 [object Function <unnamed>]), thisv=$JS::UndefinedValue(), arg0=..., rval=$JS::UndefinedValue()) at /home/emilio/src/moz/gecko-2/js/src/vm/Interpreter.h:98
#31 0x00007f103c5a7f2f in PromiseReactionJob(JSContext*, unsigned int, JS::Value*) (cx=0x7f1024e2d000, argc=<optimized out>, vp=<optimized out>) at /home/emilio/src/moz/gecko-2/js/src/builtin/Promise.cpp:1704
#32 0x00007f103c4dd9c5 in CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), JS::CallArgs const&) (cx=0x7f1024e2d000, native=0x7f103c5a6f20 <PromiseReactionJob(JSContext*, unsigned int, JS::Value*)>, args=...)
    at /home/emilio/src/moz/gecko-2/js/src/vm/Interpreter.cpp:448
#33 0x00007f103c4cd70f in js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct) (cx=0x7f1024e2d000, args=..., construct=js::NO_CONSTRUCT) at /home/emilio/src/moz/gecko-2/js/src/vm/Interpreter.cpp:540
#34 0x00007f103c4ce33d in js::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>) (cx=0x2, fval=..., thisv=..., args=..., rval=...)
    at /home/emilio/src/moz/gecko-2/js/src/vm/Interpreter.cpp:611
#35 0x00007f103cb21cf0 in JS::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, JS::HandleValueArray const&, JS::MutableHandle<JS::Value>) (cx=0x7f1024e2d000, thisv=..., fval=..., args=..., rval=$JS::UndefinedValue())
    at /home/emilio/src/moz/gecko-2/js/src/jsapi.cpp:2658
#36 0x00007f1039b8fd1e in mozilla::dom::PromiseJobCallback::Call(JSContext*, JS::Handle<JS::Value>, mozilla::ErrorResult&) (this=<optimized out>, cx=0x2, aThisVal=$JS::DoubleValue(2.153053900365964e+151), aRv=...)
    at PromiseBinding.cpp:26
#37 0x00007f1038468618 in mozilla::dom::PromiseJobCallback::Call(mozilla::ErrorResult&, char const*, mozilla::dom::CallbackObject::ExceptionHandling, JS::Realm*)
    (this=0x7f1022277d80, aRv=..., aExecutionReason=<optimized out>, aExceptionHandling=mozilla::dom::CallbackObject::eReportExceptions, aRealm=0x0) at /home/emilio/src/moz/gecko-2/obj-debug/dist/include/mozilla/dom/PromiseBinding.h:91
#38 0x00007f1038468618 in mozilla::dom::PromiseJobCallback::Call(char const*) (this=0x7f1022277d80, aExecutionReason=<optimized out>) at /home/emilio/src/moz/gecko-2/obj-debug/dist/include/mozilla/dom/PromiseBinding.h:104
#39 0x00007f1038468618 in mozilla::PromiseJobRunnable::Run(mozilla::AutoSlowOperation&) (this=<optimized out>, aAso=...) at /home/emilio/src/moz/gecko-2/xpcom/base/CycleCollectedJSContext.cpp:239
#40 0x00007f1038455656 in mozilla::CycleCollectedJSContext::PerformMicroTaskCheckPoint(bool) (this=0x7f1024f2e000, aForce=<optimized out>) at /home/emilio/src/moz/gecko-2/xpcom/base/CycleCollectedJSContext.cpp:661
#41 0x00007f1038455b88 in mozilla::CycleCollectedJSContext::AfterProcessTask(unsigned int) (this=0x7f1024f2e000, aRecursionDepth=<optimized out>) at /home/emilio/src/moz/gecko-2/xpcom/base/CycleCollectedJSContext.cpp:490
#42 0x00007f1038fa1824 in XPCJSContext::AfterProcessTask(unsigned int) (this=0x7f1024f2e000, aNewRecursionDepth=1) at /home/emilio/src/moz/gecko-2/js/xpconnect/src/XPCJSContext.cpp:1315
#43 0x00007f10385243ea in nsThread::ProcessNextEvent(bool, bool*) (this=0x7f1026078c40, aMayWait=<optimized out>, aResult=0x7ffcf0f66e47) at /home/emilio/src/moz/gecko-2/xpcom/threads/nsThread.cpp:1283
#44 0x00007f1038525edf in NS_ProcessNextEvent(nsIThread*, bool) (aThread=0x2, aMayWait=<optimized out>) at /home/emilio/src/moz/gecko-2/xpcom/threads/nsThreadUtils.cpp:486
#45 0x00007f1038b48c22 in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) (this=0x7f104179f420, aDelegate=0x7ffcf0f670a0) at /home/emilio/src/moz/gecko-2/ipc/glue/MessagePump.cpp:88
#46 0x00007f1038ad72a5 in MessageLoop::RunInternal() (this=0x7ffcf0f670a0) at /home/emilio/src/moz/gecko-2/ipc/chromium/src/base/message_loop.cc:315
#47 0x00007f1038ad71fe in MessageLoop::RunHandler() (this=0x7ffcf0f670a0) at /home/emilio/src/moz/gecko-2/ipc/chromium/src/base/message_loop.cc:308
#48 0x00007f1038ad71fe in MessageLoop::Run() (this=0x7ffcf0f670a0) at /home/emilio/src/moz/gecko-2/ipc/chromium/src/base/message_loop.cc:290
#49 0x00007f103b10f8a7 in nsBaseAppShell::Run() (this=0x7f10417e8270) at /home/emilio/src/moz/gecko-2/widget/nsBaseAppShell.cpp:137
#50 0x00007f103c3b4b50 in XRE_RunAppShell() () at /home/emilio/src/moz/gecko-2/toolkit/xre/nsEmbedFunctions.cpp:919
#51 0x00007f1038b49201 in mozilla::ipc::MessagePumpForChildProcess::Run(base::MessagePump::Delegate*) (this=0x7f104179f420, aDelegate=0x7ffcf0f670a0) at /home/emilio/src/moz/gecko-2/ipc/glue/MessagePump.cpp:238
#52 0x00007f1038ad72a5 in MessageLoop::RunInternal() (this=0x7ffcf0f670a0) at /home/emilio/src/moz/gecko-2/ipc/chromium/src/base/message_loop.cc:315
#53 0x00007f1038ad71fe in MessageLoop::RunHandler() (this=0x7ffcf0f670a0) at /home/emilio/src/moz/gecko-2/ipc/chromium/src/base/message_loop.cc:308
#54 0x00007f1038ad71fe in MessageLoop::Run() (this=0x7ffcf0f670a0) at /home/emilio/src/moz/gecko-2/ipc/chromium/src/base/message_loop.cc:290
#55 0x00007f103c3b4494 in XRE_InitChildProcess(int, char**, XREChildData const*) (aArgc=<optimized out>, aArgv=<optimized out>, aChildData=<optimized out>) at /home/emilio/src/moz/gecko-2/toolkit/xre/nsEmbedFunctions.cpp:754
#56 0x000055dd365ae134 in content_process_main(mozilla::Bootstrap*, int, char**) (bootstrap=0x7f104172e6c0, argc=15, argv=0x7ffcf0f684d8) at /home/emilio/src/moz/gecko-2/browser/app/../../ipc/contentproc/plugin-container.cpp:56
#57 0x000055dd365ae3ef in main(int, char**, char**) (argc=16, argv=0x7ffcf0f684d8, envp=<optimized out>) at /home/emilio/src/moz/gecko-2/browser/app/nsBrowserApp.cpp:267

I have an rr recording of this, so I should be able to provide more information as needed. But I don't know what to look for :)

It has something to do with my current profile... I saved it and I'll try to get it to crash in an unoptimized build.

Hmm, so it happens consistently when I run it under rr, but not without... May be an rr bug or maybe not... I'll try to update rr too.

Attached file crashy-profile.tar.gz

Str that works for me:

  • tar -vxf crashy-profile.tar.gz
  • ./mach run --debugger=rr --profile /path/to/.../profile-default

I was doing devtools stuff involving promises with the page before closing that session, so it seems plausible off-hand, I guess.

For my own reference the trace was recorded with rr at commit bb7ae39c (a couple weeks old). I tried to submit it to pernosco.

I could repro on a clobber, unoptimized build, and confirmed that the next build behaved just fine (which didn't load my page because of the crash, and instead spawned about:sessionrestore).

Type: task → defect

FWIW I couldn't repro the same str on today's central, but it repros on https://hg.mozilla.org/mozilla-central/rev/30b8d57cb72a2f955532a0e670c599881a110f17.

https://pernos.co/debug/B08Q3uLxsRfn2IlhRCkHMQ/index.html has a local rr recording of this.

We seem to be in about:home, and reject the DOM l10n promise. It seems something throws and we can't serialize it because cls is ESClass::Error:

#0  JSStructuredCloneWriter::startWrite (this=0x7ffc2be8e7e8, v=...) at /home/emilio/src/moz/gecko-3/js/src/vm/StructuredClone.cpp:1711
#1  0x00007f055aaabd85 in JSStructuredCloneWriter::write (this=0x7ffc2be8e7e8, v=...) at /home/emilio/src/moz/gecko-3/js/src/vm/StructuredClone.cpp:1928
#2  0x00007f055aaabcb5 in WriteStructuredClone (cx=0x7f053ca2d000, v=..., bufp=0x7f0539e6b248, scope=JS::StructuredCloneScope::SameProcessSameThread, cloneDataPolicy=..., cb=0x7f055ea3ed90 <mozilla::dom::StructuredCloneHolder::sCallbacks>, cbClosure=0x7ffc2be8ee60, transferable=...) at /home/emilio/src/moz/gecko-3/js/src/vm/StructuredClone.cpp:631
#3  0x00007f055aab7d6e in JS_WriteStructuredClone (cx=0x7f053ca2d000, value=..., bufp=0x7f0539e6b248, scope=JS::StructuredCloneScope::SameProcessSameThread, cloneDataPolicy=..., optionalCallbacks=0x7f055ea3ed90 <mozilla::dom::StructuredCloneHolder::sCallbacks>, closure=0x7ffc2be8ee60, transferable=...) at /home/emilio/src/moz/gecko-3/js/src/vm/StructuredClone.cpp:3040
#4  0x00007f055aab89d9 in JSAutoStructuredCloneBuffer::write (this=0x7f0539e6b240, cx=0x7f053ca2d000, value=..., transferable=..., cloneDataPolicy=..., optionalCallbacks=0x7f055ea3ed90 <mozilla::dom::StructuredCloneHolder::sCallbacks>, closure=0x7ffc2be8ee60) at /home/emilio/src/moz/gecko-3/js/src/vm/StructuredClone.cpp:3169
#5  0x00007f0554807984 in mozilla::dom::StructuredCloneHolderBase::Write (this=0x7ffc2be8ee60, aCx=0x7f053ca2d000, aValue=..., aTransfer=..., cloneDataPolicy=...) at /home/emilio/src/moz/gecko-3/dom/base/StructuredCloneHolder.cpp:183
#6  0x00007f055480779c in mozilla::dom::StructuredCloneHolderBase::Write (this=0x7ffc2be8ee60, aCx=0x7f053ca2d000, aValue=...) at /home/emilio/src/moz/gecko-3/dom/base/StructuredCloneHolder.cpp:169
#7  0x00007f055366a8a5 in xpc::StackScopedClone (cx=0x7f053ca2d000, options=..., sourceScope=..., val=...) at /home/emilio/src/moz/gecko-3/js/xpconnect/src/ExportHelpers.cpp:209
#8  0x00007f0557292a98 in mozilla::dom::Promise::MaybeRejectWithClone (this=0x7f053cd6f1f0, aCx=0x7f053ca2d000, aValue=...) at /home/emilio/src/moz/gecko-3/dom/promise/Promise.cpp:572
#9  0x00007f055233fec9 in PromiseResolver::RejectedCallback (this=0x7f053c9a4ca0, aCx=0x7f053ca2d000, aValue=...) at /home/emilio/src/moz/gecko-3/intl/l10n/Localization.cpp:282
#10 0x00007f0557295fcc in mozilla::dom::(anonymous namespace)::PromiseNativeHandlerShim::RejectedCallback (this=0x7f053c9a4cc0, aCx=0x7f053ca2d000, aValue=...) at /home/emilio/src/moz/gecko-3/dom/promise/Promise.cpp:394
#11 0x00007f05572966b0 in mozilla::dom::NativeHandlerCallback (aCx=0x7f053ca2d000, aArgc=1, aVp=0x7ffc2be8f678) at /home/emilio/src/moz/gecko-3/dom/promise/Promise.cpp:344
#12 0x00007f055a4f068f in CallJSNative (cx=0x7f053ca2d000, native=0x7f0557296450 <mozilla::dom::NativeHandlerCallback(JSContext*, unsigned int, JS::Value*)>, args=...) at /home/emilio/src/moz/gecko-3/js/src/vm/Interpreter.cpp:448
#13 0x00007f055a4dafaa in js::InternalCallOrConstruct (cx=0x7f053ca2d000, args=..., construct=js::NO_CONSTRUCT) at /home/emilio/src/moz/gecko-3/js/src/vm/Interpreter.cpp:540
#14 0x00007f055a4db685 in InternalCall (cx=0x7f053ca2d000, args=...) at /home/emilio/src/moz/gecko-3/js/src/vm/Interpreter.cpp:595
#15 0x00007f055a4db730 in js::Call (cx=0x7f053ca2d000, fval=..., thisv=..., args=..., rval=...) at /home/emilio/src/moz/gecko-3/js/src/vm/Interpreter.cpp:611
#16 0x00007f055a611d39 in js::Call (cx=0x7f053ca2d000, fval=..., thisv=..., arg0=..., rval=...) at /home/emilio/src/moz/gecko-3/js/src/vm/Interpreter.h:98
#17 0x00007f055a5fd029 in PromiseReactionJob (cx=0x7f053ca2d000, argc=0, vp=0x7ffc2be8fc90) at /home/emilio/src/moz/gecko-3/js/src/builtin/Promise.cpp:1704
#18 0x00007f055a4f068f in CallJSNative (cx=0x7f053ca2d000, native=0x7f055a5fc8f0 <PromiseReactionJob(JSContext*, unsigned int, JS::Value*)>, args=...) at /home/emilio/src/moz/gecko-3/js/src/vm/Interpreter.cpp:448
#19 0x00007f055a4dafaa in js::InternalCallOrConstruct (cx=0x7f053ca2d000, args=..., construct=js::NO_CONSTRUCT) at /home/emilio/src/moz/gecko-3/js/src/vm/Interpreter.cpp:540
#20 0x00007f055a4db685 in InternalCall (cx=0x7f053ca2d000, args=...) at /home/emilio/src/moz/gecko-3/js/src/vm/Interpreter.cpp:595
#21 0x00007f055a4db730 in js::Call (cx=0x7f053ca2d000, fval=..., thisv=..., args=..., rval=...) at /home/emilio/src/moz/gecko-3/js/src/vm/Interpreter.cpp:611
#22 0x00007f055ad524d5 in JS::Call (cx=0x7f053ca2d000, thisv=..., fval=..., args=..., rval=...) at /home/emilio/src/moz/gecko-3/js/src/jsapi.cpp:2658
#23 0x00007f0554ed59be in mozilla::dom::PromiseJobCallback::Call (this=0x7f053ad2a2c0, cx=0x7f053ca2d000, aThisVal=..., aRv=...) at PromiseBinding.cpp:26
#24 0x00007f05520284e7 in mozilla::dom::PromiseJobCallback::Call (this=0x7f053ad2a2c0, aRv=..., aExecutionReason=0x7f054e16ddde "promise callback", aExceptionHandling=mozilla::dom::CallbackObject::eReportExceptions, aRealm=0x0) at /home/emilio/src/moz/gecko-3/obj-debug-noopt/dist/include/mozilla/dom/PromiseBinding.h:91
#25 0x00007f0552027e7e in mozilla::dom::PromiseJobCallback::Call (this=0x7f053ad2a2c0, aExecutionReason=0x7f054e16ddde "promise callback") at /home/emilio/src/moz/gecko-3/obj-debug-noopt/dist/include/mozilla/dom/PromiseBinding.h:104
#26 0x00007f05520262a4 in mozilla::PromiseJobRunnable::Run (this=0x7f0539e70760, aAso=...) at /home/emilio/src/moz/gecko-3/xpcom/base/CycleCollectedJSContext.cpp:239
#27 0x00007f0551ff3c55 in mozilla::CycleCollectedJSContext::PerformMicroTaskCheckPoint (this=0x7f053cc64000, aForce=false) at /home/emilio/src/moz/gecko-3/xpcom/base/CycleCollectedJSContext.cpp:661
#28 0x00007f0551ff41e6 in mozilla::CycleCollectedJSContext::AfterProcessTask (this=0x7f053cc64000, aRecursionDepth=1) at /home/emilio/src/moz/gecko-3/xpcom/base/CycleCollectedJSContext.cpp:490
#29 0x00007f0553694b18 in XPCJSContext::AfterProcessTask (this=0x7f053cc64000, aNewRecursionDepth=1) at /home/emilio/src/moz/gecko-3/js/xpconnect/src/XPCJSContext.cpp:1315
#30 0x00007f05521dd826 in nsThread::ProcessNextEvent (this=0x7f053dd7ab50, aMayWait=false, aResult=0x7ffc2be909a7) at /home/emilio/src/moz/gecko-3/xpcom/threads/nsThread.cpp:1283
[...]

And we end on xpc::StackScopedCloneData::CustomWriteHandler not being able to serialize it.

We end up in MaybeReject and eventually crash due to a compartment mismatch. I guess this is a bug in the l10n code somehow? I don't know.

Boris, any idea of where things go wrong? I'm a bit out of my depth here :)

I told Jandem that I'd ni? him but at this point given the above I suspect it's more likely to be a dom/l10n bug. So only cc'ing :)

Flags: needinfo?(bzbarsky)

Hmm. MaybeRejectWithClone is a new thing added for l10n. See bug 1483036.

It's not really implemented right, as far as I can tell, or we need changes to how MaybeResolve/MaybeReject work. Right now, the versions of MaybeResolve/MaybeReject that take a JSContext MUST be called while in the compartment of the promise object. Otherwise you will get the observed compartment-mismatch assertions.

MaybeSomething does the right thing there. Other callers need careful examination. Looking at MaybeResolve:

  • BodyConsumer::ContinueConsumeBody (both callsites): This works out because localPromise comes from mConsumePromise which ultimately comes from BodyConsumer::Create creating a promise in the global of aGlobal. That global also becomes the global of the BodyConsumer, which is what we use to init the AutoJSAPI that cx comes from in this method.

  • UnblockParsingPromiseHandler::ResolvedCallback: I think this ends up working out because we're coming from another promise that was in the same global as the promise we are now resolving, but I am not 100% sure.

  • PromiseWorkerProxy::ResolvedCallback OK if it only runs on the worker side, where there is basically only one compartment.

  • JSWindowActor::ReceiveMessageOrQuery: Pretty sure this is broken if it can get called with aCx not in the compartment of GetWrapper(). The promise is created in the global of GetWrapper().

  • nsSystemInfo::GetDiskInfo: OK; it's all working with a single global.

  • Promise::MaybeResolveWithClone: Broken if PromiseResolver::ResolvedCallback gets called while in a different compartment than mPromise.

I didn't really dig into the MaybeReject cases, though obviously the one in Promise::MaybeRejectWithClone is broken.

I think that instead of this whack-a-mole we really have two options:

  1. Remove the public two-argument versions of MaybeResolve and MaybeReject. Make callers go through the one-arg MaybeSomething version. It will put an extra AutoEntryScript on the stack, but maybe that's OK.

  2. Leave the public things, but have them enter the compartment of the promise and wrap the incoming value into that compartment, calling HandleException if the wrapping fails (and adjust the comments in HandleException).

I suspect option 2 is fine and would fix this bug...

Flags: needinfo?(bzbarsky)
Regressed by: 1483036

Moving to DOM because DOM Promises..

Component: JavaScript Engine → DOM: Core & HTML

(In general we should do something to compartment handling. It is way too error prone.
Best would be some API level mechanism to force right compartment usage, or at least tell to the caller whether one needs to be
in certain compartment. Perhaps some additional API layer which gets optimized out in non-debug builds, but forces somehow reasonable compartment usage.
Least and ugliest we could do is to change method naming to hint about the right compartment.)

Hmm, I'm still missing what is actually in a wrong compartment.
MaybeRejectWithClone enters the compartment of mGlobal, similarly to MaybeSomething.
And StackScopedClone lets value to be in different compartment.
Are aValue and sourceScope in different compartments..

I see, maybe, need to check the return value of StackScopeClone and deal with possible exception.
Since if StackScopeClone fails, then value is still in the old compartment.

Assignee: nobody → bugs

Since if StackScopeClone fails, then value is still in the old compartment.

Right, exactly.

But my point is that we should consider fixing this in MaybeReject/MaybeResolve, no the *WithClone bits, so we don't need to worry about all the various callsites that might mess this up.

This is one possible approach. Try to make MaybeResolve/Reject less error prone to
compartment mismatches by wrapping the incoming value and also fix StackScopedClone usage.

Priority: -- → P2
Attachment #9078866 - Attachment is obsolete: true
Crash Signature: [@ js::ContextChecks::check]

This is happening at a pretty steady volume on Nightly.

Pushed by opettay@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/ac548c2a725b try to make Promise less error prone to compartment mismatches, r=bzbarsky
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla70

Is this something we should consider for Beta & ESR68 backport?

The patch seems to apply cleanly to beta
(but couldn't test building, since beta doesn't build locally because of issues with cbindgen + libclang)

esr68 needs a new patch.

Flags: needinfo?(bugs)

Comment on attachment 9079516 [details]
Bug 1565930, try to make Promise less error prone to compartment mismatches, r=bzbarsky

Beta/Release Uplift Approval Request

  • User impact if declined: crashes
  • Is this code covered by automated tests?: Unknown
  • Has the fix been verified in Nightly?: No
  • Needs manual test from QE?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Medium
  • Why is the change risky/not risky? (and alternatives if risky): The patch is based on code inspection. We handle unusual cases now in a less error prone way.

Based on initial crash-stat results, the patch has fixed the issue.

  • String changes made/needed: NA
Attachment #9079516 - Flags: approval-mozilla-beta?
Attached patch For ESR68Splinter Review

ESR Uplift Approval Request

  • If this is not a sec:{high,crit} bug, please state case for ESR consideration: Fixes crashes related to cross-compartment
  • User impact if declined:
  • Fix Landed on Version: 70
  • Risk to taking this patch: Medium
  • Why is the change risky/not risky? (and alternatives if risky): Not super trivial patch, but mostly to improving error case handling
  • String or UUID changes made by this patch: NA
Attachment #9082074 - Flags: approval-mozilla-esr68?

Comment on attachment 9079516 [details]
Bug 1565930, try to make Promise less error prone to compartment mismatches, r=bzbarsky

Try to avoid compartment mismatch crashes by improving Promise error handling. Approved for 69.0b10 and 68.1esr.

Attachment #9079516 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Attachment #9082074 - Flags: approval-mozilla-esr68? → approval-mozilla-esr68+

On ESR68 there is code in mozJSSubScriptLoader.cpp which just calls PeekException, but doesn't clear the exception, and thus
AutoEntryScript asserts. Using StealException instead avoids the assertion.

Flags: needinfo?(bugs)
Crash Signature: [@ js::ContextChecks::check] → [@ js::ContextChecks::check] [@ js::ContextChecks::check(JS::Value const &,int)]
Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: