69599 2011-10-06 20:00:29 -0700 [JSC] JIT buffer refcounting causing assertions in debug WebSocket tests when using proxy PAC 2011-10-07 14:11:33 -0700 1 1 1 Unclassified WebKit JavaScriptCore 528+ (Nightly build) Unspecified Unspecified RESOLVED FIXED P2 Normal --- 67329 1 dominicc dominicc ap barraclough fpizlo ggaren levin levin+threading sam webkit.review.bot yutak oldest_to_newest 479752 0 dominicc 2011-10-06 20:00:29 -0700 When I have a proxy PAC on OS X and run-webkit-tests --debug http/tests/websocket, I get a high rate (~8%) of DRT crashes with the below callstack. Removing proxy configuration PAC results in no DRT crashes. I believe JSC is used to interpret the proxy PAC file, and when it does this it reuses code buffers in different threads. We should verify that this reuse is safe, and if so, change the verifier to not squawk at this. ASSERTION FAILED: m_verifier.isSafeToUse() ./wtf/RefCounted.h(122) : bool WTF::RefCountedBase::derefBase() 2 0x1002288a4 WTF::RefCountedBase::derefBase() 3 0x1003ac931 WTF::RefCounted<WTF::MetaAllocatorHandle>::deref() 4 0x100217303 void WTF::derefIfNotNull<WTF::MetaAllocatorHandle>(WTF::MetaAllocatorHandle*) 5 0x10021731e WTF::RefPtr<WTF::MetaAllocatorHandle>::~RefPtr() 6 0x1003ac96d JSC::MacroAssemblerCodeRef::~MacroAssemblerCodeRef() 7 0x1002175e3 JSC::JITCode::~JITCode() 8 0x100208244 JSC::CodeBlock::~CodeBlock() 9 0x1002179bf JSC::GlobalCodeBlock::~GlobalCodeBlock() 10 0x1002179f7 JSC::ProgramCodeBlock::~ProgramCodeBlock() 11 0x1002649f0 void WTF::deleteOwnedPtr<JSC::ProgramCodeBlock>(JSC::ProgramCodeBlock*) 12 0x100264a51 WTF::OwnPtr<JSC::ProgramCodeBlock>::clear() 13 0x100261770 JSC::ProgramExecutable::clearCodeVirtual() 14 0x100260262 JSC::ExecutableBase::clearCode(JSC::JSCell*) 15 0x1003bcbde JSC::Heap::FinalizerOwner::finalize(JSC::Handle<JSC::Unknown>, void*) 16 0x10026d1ec JSC::HandleHeap::finalizeWeakHandles() 17 0x1003be777 JSC::Heap::collect(JSC::Heap::SweepToggle) 18 0x1003d0042 JSC::AllocationSpace::allocateSlowCase(JSC::MarkedSpace::SizeClass&) 19 0x1001ca832 JSC::AllocationSpace::allocate(JSC::MarkedSpace::SizeClass&) 20 0x1002021b6 JSC::AllocationSpace::allocate(unsigned long) 21 0x100202223 JSC::Heap::allocate(unsigned long) 22 0x10024c692 void* JSC::allocateCell<JSC::JSFinalObject>(JSC::Heap&) 23 0x10024c6c4 JSC::JSFinalObject::create(JSC::ExecState*, JSC::Structure*) 24 0x1002ac281 JSC::constructEmptyObject(JSC::ExecState*, JSC::Structure*) 25 0x10024c72f JSC::constructEmptyObject(JSC::ExecState*, JSC::JSGlobalObject*) 26 0x1003333e1 JSC::constructEmptyObject(JSC::ExecState*) 27 0x10029bfaa cti_op_new_object 28 0x10029b301 jscGeneratedNativeCode 29 0x1002797f4 JSC::JITCode::execute(JSC::RegisterFile*, JSC::ExecState*, JSC::JSGlobalData*) 30 0x100273aaf JSC::Interpreter::executeCall(JSC::ExecState*, JSC::JSObject*, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) 31 0x100205021 JSC::call(JSC::ExecState*, JSC::JSValue, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) 32 0x1002e6303 JSObjectCallAsFunction 479765 1 dominicc 2011-10-06 20:37:55 -0700 Here’s evidence of calling FindProxyForURL using the same objects. ASSERTION FAILED: m_verifier.isSafeToUse() ./wtf/RefCounted.h(122) : bool WTF::RefCountedBase::derefBase() 2 0x1002288a4 WTF::RefCountedBase::derefBase() 3 0x1003ac931 WTF::RefCounted<WTF::MetaAllocatorHandle>::deref() 4 0x100217303 void WTF::derefIfNotNull<WTF::MetaAllocatorHandle>(WTF::MetaAllocatorHandle*) 5 0x1003acc49 WTF::RefPtr<WTF::MetaAllocatorHandle>::operator=(WTF::RefPtr<WTF::MetaAllocatorHandle> const&) 6 0x1003acc83 JSC::MacroAssemblerCodeRef::operator=(JSC::MacroAssemblerCodeRef const&) 7 0x100247b2d JSC::JITCode::operator=(JSC::JITCode const&) 8 0x100242466 JSC::DFG::JITCompiler::compileFunction(JSC::JITCode&, JSC::MacroAssemblerCodePtr&) 9 0x1001c11a9 JSC::DFG::compile(JSC::DFG::CompileMode, JSC::ExecState*, JSC::ExecState*, JSC::CodeBlock*, JSC::JITCode&, JSC::MacroAssemblerCodePtr*) 10 0x1001bc9a0 JSC::DFG::tryCompileFunction(JSC::ExecState*, JSC::ExecState*, JSC::CodeBlock*, JSC::JITCode&, JSC::MacroAssemblerCodePtr&) 11 0x100262d0e JSC::FunctionExecutable::compileForCallInternal(JSC::ExecState*, JSC::ScopeChainNode*, JSC::ExecState*, JSC::JITCode::JITType) 12 0x100263076 JSC::FunctionExecutable::compileOptimizedForCall(JSC::ExecState*, JSC::ScopeChainNode*, JSC::ExecState*) 13 0x100215c5d JSC::FunctionExecutable::compileOptimizedFor(JSC::ExecState*, JSC::ScopeChainNode*, JSC::CodeSpecializationKind) 14 0x100206766 JSC::FunctionCodeBlock::compileOptimized(JSC::ExecState*, JSC::ScopeChainNode*) 15 0x1002a2f86 cti_optimize_from_ret 16 0x10029b301 jscGeneratedNativeCode 17 0x1002797f4 JSC::JITCode::execute(JSC::RegisterFile*, JSC::ExecState*, JSC::JSGlobalData*) 18 0x100273aaf JSC::Interpreter::executeCall(JSC::ExecState*, JSC::JSObject*, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) 19 0x100205021 JSC::call(JSC::ExecState*, JSC::JSValue, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) 20 0x1002e6303 JSObjectCallAsFunction 21 0x7fff8210c6c1 CallFindProxyForURL 22 0x7fff8210eb44 executionContextPerform(void*) 23 0x7fff83d22401 __CFRunLoopDoSources0 24 0x7fff83d205f9 __CFRunLoopRun 25 0x7fff83d1fdbf CFRunLoopRunSpecific 26 0x7fff8a090c64 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] 27 0x100013788 runTest(std::string const&) 28 0x100013c9f runTestingServerLoop() 29 0x1000140b4 dumpRenderTree(int, char const**) 30 0x1000142d6 main 31 0x1000023a8 start This is with a small PAC file: function FindProxyForURL(url, host) { return 'DIRECT'; } 479768 2 ap 2011-10-06 20:47:12 -0700 Does DFG JIT have thread safety issues? 479772 3 ggaren 2011-10-06 20:59:35 -0700 FYI, what's interesting about a PAC (Proxy Auto-Config) file is that the networking thread will run the PAC .js code on a secondary thread while JS runs on the main thread. A cursory glance shows that MetaAllocator uses locking in a seemingly appropriate way. I believe the bug here is that the RefCountedBase debug verifier is in SingleThreadVerificationMode, but the JSC API allows an object to be used on more than one thread, as long as it's not at the same time. NoVerificationMode seems to be the only mode in ThreadRestrictionVerifier that's compatible with our API. 479773 4 levin 2011-10-06 21:02:16 -0700 (In reply to comment #3) > FYI, what's interesting about a PAC (Proxy Auto-Config) file is that the networking thread will run the PAC .js code on a secondary thread while JS runs on the main thread. > > A cursory glance shows that MetaAllocator uses locking in a seemingly appropriate way. I believe the bug here is that the RefCountedBase debug verifier is in SingleThreadVerificationMode, but the JSC API allows an object to be used on more than one thread, as long as it's not at the same time. > > NoVerificationMode seems to be the only mode in ThreadRestrictionVerifier that's compatible with our API. I haven't yet added anything for JSC, so this object will need to call the deprecated api that I put in for the other JSC objects. If anyone would like to add to ThreadRestrictionVerifier to make a mode compatible with the JSC API, that would be delightful! (because I must admit that I don't understand it completely so it will take me a while when I get to it). 479852 5 110101 dominicc 2011-10-07 00:52:27 -0700 Created attachment 110101 Patch 479856 6 dominicc 2011-10-07 00:57:51 -0700 (In reply to comment #3) > A cursory glance shows that MetaAllocator uses locking in a seemingly appropriate way. I believe the bug here is that the RefCountedBase debug verifier is in SingleThreadVerificationMode, but the JSC API allows an object to be used on more than one thread, as long as it's not at the same time. It looks like a JITCode buffer touched by one thread is deref'ed during GC on another thread. Is the GC under a mutex? If not, should MetaAllocatorHandles be thread-shared refcounted? > NoVerificationMode seems to be the only mode in ThreadRestrictionVerifier that's compatible with our API. I have uploaded a patch that sets this mode with a FIXME to work out a more detailed verification scheme. 479871 7 110103 dominicc 2011-10-07 01:36:12 -0700 Created attachment 110103 Alternative patch 479873 8 dominicc 2011-10-07 01:39:29 -0700 I am having a hard time convincing myself that this isn’t racy, given that callstacks include both JITting and GC; it isn’t immediately obvious what is stopping these being used concurrently. So I have uploaded an alternative patch that makes MetaAllocatorHandle : ThreadSafeRefCounted<…>. 479990 9 110101 webkit.review.bot 2011-10-07 07:48:54 -0700 Comment on attachment 110101 Patch Clearing flags on attachment: 110101 Committed r96936: <http://trac.webkit.org/changeset/96936> 479992 10 webkit.review.bot 2011-10-07 07:49:00 -0700 All reviewed patches have been landed. Closing bug. 480076 11 ggaren 2011-10-07 09:38:36 -0700 > I am having a hard time convincing myself that this isn’t racy, given that callstacks include both JITting and GC; it isn’t immediately obvious what is stopping these being used concurrently. The design here is that clients should either use separate virtual machines ("JSGlobalData") on separate threads, or use locking external to JSC to ensure that the same virtual machine is not used concurrently on two different threads. For PAC files, I believe you should end up with separate heaps on separate threads. The only shared resource here is the MetaAllocator. Access to the MetaAllocator should be locked and, as far as I can tell, is. 480211 12 fpizlo 2011-10-07 12:32:29 -0700 (In reply to comment #11) > > I am having a hard time convincing myself that this isn’t racy, given that callstacks include both JITting and GC; it isn’t immediately obvious what is stopping these being used concurrently. > > The design here is that clients should either use separate virtual machines ("JSGlobalData") on separate threads, or use locking external to JSC to ensure that the same virtual machine is not used concurrently on two different threads. For PAC files, I believe you should end up with separate heaps on separate threads. > > The only shared resource here is the MetaAllocator. Access to the MetaAllocator should be locked and, as far as I can tell, is. Indeed. The code was definitely not racy, so this patch does more synchronization than necessary. In particular, since: - Each instance of JSC is itself not thread safe (i.e. if you call into one instance of JSC from multiple threads, you die), and - An instance of JSC will never leak its meta allocator handles (since these are references to executable code, and executable code generated by one JSC instance is invalid for use in another), Then if you do encounter a case where two threads are simultaneously trying to fiddle with the same meta allocator handle's reference count, it means that you're already dead for a multitude of other reasons. And yes, it is true that there is one MetaAllocator instance globally, but that instance only hands out handles and frees them; there is no way for it to take one JSC instance's handle and somehow transfer it to someone else. And MetaAllocator itself is thread safe by brute force: all entrypoints into it are locked. But on the other hand, this patch doesn't appear to have regressed our performance. So, I guess we can revisit this if we ever find that the synchronization on MetaAllocator handle starts to get hot. 480218 13 fpizlo 2011-10-07 12:36:05 -0700 > NoVerificationMode seems to be the only mode in ThreadRestrictionVerifier that's compatible with our API. Exactly! The JavaScript language is not designed for concurrency. That does not preclude multiple threads for running JS code within the same VM so long as the code that calls into JS ensures that there is no way for multiple threads to simultaneously run JS code in the same VM. JavaScriptCore offloads this work onto the user of the JavaScriptCore APIs as a matter of policy. So I don't see how anything but NoVerificationMode is appropriate for reference counted objects in JSC. 480221 14 levin 2011-10-07 12:40:32 -0700 (In reply to comment #13) > > NoVerificationMode seems to be the only mode in ThreadRestrictionVerifier that's compatible with our API. > > Exactly! > > The JavaScript language is not designed for concurrency. That does not preclude multiple threads for running JS code within the same VM so long as the code that calls into JS ensures that there is no way for multiple threads to simultaneously run JS code in the same VM. JavaScriptCore offloads this work onto the user of the JavaScriptCore APIs as a matter of policy. > > So I don't see how anything but NoVerificationMode is appropriate for reference counted objects in JSC. To my memory I heard something about JSLock that may not do anything but would be useful for setting a flag. Anyway, this is on my list for later. I have a bug about adding a mode for jsc. Sorry for this disturbance. I "fixed" as many of the jsc objects as I found by using this deprecated api call. 480242 15 ap 2011-10-07 13:00:28 -0700 JSLock is indeed something that automatically prevents concurrent JavaScript execution. It's an obsolete feature, and is only used for Mac OS X applications linked against old versions of WebKit. Comments in JSContextRef.h have more information about JSC threading. 480304 16 ggaren 2011-10-07 14:11:33 -0700 > But on the other hand, this patch doesn't appear to have regressed our performance. So, I guess we can revisit this if we ever find that the synchronization on MetaAllocator handle starts to get hot. Note that the fix that landed just disabled verification. The patch that changed to using ThreadSafeRefCounted did not land. (And should not, for the reasons you've explained.) 110101 2011-10-07 00:52:27 -0700 2011-10-07 07:48:54 -0700 Patch bug-69599-20111007165225.patch text/plain 1963 dominicc U3VidmVyc2lvbiBSZXZpc2lvbjogOTY4NjgKZGlmZiAtLWdpdCBhL1NvdXJjZS9KYXZhU2NyaXB0 Q29yZS9DaGFuZ2VMb2cgYi9Tb3VyY2UvSmF2YVNjcmlwdENvcmUvQ2hhbmdlTG9nCmluZGV4IDI5 ZDg3MzNjNjY1NWNmNmQzMDQxMTVkYjIyZGE3YzU1OTBkMWE3YjIuLmM2ZjRkYWUzZjAwZjNkMjgy MDBmZTE2YmU3NDMxYzI1NjhmZmY1YTggMTAwNjQ0Ci0tLSBhL1NvdXJjZS9KYXZhU2NyaXB0Q29y ZS9DaGFuZ2VMb2cKKysrIGIvU291cmNlL0phdmFTY3JpcHRDb3JlL0NoYW5nZUxvZwpAQCAtMSwz ICsxLDIwIEBACisyMDExLTEwLTA3ICBEb21pbmljIENvb25leSAgPGRvbWluaWNjQGNocm9taXVt Lm9yZz4KKworICAgICAgICBbSlNDXSBEaXNhYmxlIFRocmVhZFJlc3RyaWN0aW9uVmVyaWZpZXIg Zm9yIEpJVCBFeGVjdXRhYmxlTWVtb3J5SGFuZGxlcworICAgICAgICBodHRwczovL2J1Z3Mud2Vi a2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9Njk1OTkKKworICAgICAgICBSZXZpZXdlZCBieSBOT0JP RFkgKE9PUFMhKS4KKworICAgICAgICBERkcgSklUIG1hbmlwdWxhdGVzIE1ldGFBbGxvY2F0b3JI YW5kbGVzIGFjcm9zcyB0aHJlYWRzLCBlZyBpbgorICAgICAgICBhbGxvY2F0aW5nIEpJVENvZGUg YnVmZmVycyBvbiBhIGJhY2tncm91bmQgdGhyZWFkIHRvIGV4ZWN1dGUgYQorICAgICAgICBwcm94 eSBhdXRvY29uZmlndXJhdGlvbiBQQUMgZmlsZSBidXQgZ2FyYmFnZSBjb2xsZWN0aW5nIGl0IGlu CisgICAgICAgIHJlc3BvbnNlIHRvIGFsbG9jYXRpb24gb24gdGhlIG1haW4gdGhyZWFkLiBEaXNh YmxpbmcKKyAgICAgICAgVGhyZWFkUmVzdHJpY3Rpb25WZXJpZmljYXRpb24gdW50aWwgdGhlcmUg aXMgYSB2ZXJpZmljYXRpb24gc2NoZW1lCisgICAgICAgIHRoYXQgdW5kZXJzdGFuZHMgdGhpcyBo YW5kb2ZmLgorCisgICAgICAgICogd3RmL01ldGFBbGxvY2F0b3IuY3BwOgorICAgICAgICAoV1RG OjpNZXRhQWxsb2NhdG9yOjphbGxvY2F0ZSk6CisKIDIwMTEtMTAtMDYgIEZpbGlwIFBpemxvICA8 ZnBpemxvQGFwcGxlLmNvbT4KIAogICAgICAgICBERkcgaW1wbGVtZW50YXRpb24gb2YgVUludDMy VG9OdW1iZXIgaXMgbWlzc2luZyBhIGJyZWFrIHN0YXRlbWVudApkaWZmIC0tZ2l0IGEvU291cmNl L0phdmFTY3JpcHRDb3JlL3d0Zi9NZXRhQWxsb2NhdG9yLmNwcCBiL1NvdXJjZS9KYXZhU2NyaXB0 Q29yZS93dGYvTWV0YUFsbG9jYXRvci5jcHAKaW5kZXggNWQxZmNmMDBhMjhmMTg5MTExNGQzOThk NzcxNzM2ZDQwYjY2NDg2Mi4uMmIzMTFkNzI1NDA5MGU3NTY2NjgyZWNmZjM0YmI2ZDRiNTczMzg2 YyAxMDA2NDQKLS0tIGEvU291cmNlL0phdmFTY3JpcHRDb3JlL3d0Zi9NZXRhQWxsb2NhdG9yLmNw cAorKysgYi9Tb3VyY2UvSmF2YVNjcmlwdENvcmUvd3RmL01ldGFBbGxvY2F0b3IuY3BwCkBAIC0x NTMsNyArMTUzLDEyIEBAIFBhc3NSZWZQdHI8TWV0YUFsbG9jYXRvckhhbmRsZT4gTWV0YUFsbG9j YXRvcjo6YWxsb2NhdGUoc2l6ZV90IHNpemVJbkJ5dGVzKQogI2lmIEVOQUJMRShNRVRBX0FMTE9D QVRPUl9QUk9GSUxFKQogICAgIG1fbnVtQWxsb2NhdGlvbnMrKzsKICNlbmRpZgotICAgIHJldHVy biBhZG9wdFJlZihuZXcgTWV0YUFsbG9jYXRvckhhbmRsZSh0aGlzLCBzdGFydCwgc2l6ZUluQnl0 ZXMpKTsKKworICAgIE1ldGFBbGxvY2F0b3JIYW5kbGUqIGhhbmRsZSA9IG5ldyBNZXRhQWxsb2Nh dG9ySGFuZGxlKHRoaXMsIHN0YXJ0LCBzaXplSW5CeXRlcyk7CisgICAgLy8gRklYTUU6IEltcGxl bWVudCBhIHZlcmlmaWVyIHNjaGVtZSB0aGF0IGdyb2tzIE1ldGFBbGxvY2F0b3JIYW5kbGVzCisg ICAgaGFuZGxlLT5kZXByZWNhdGVkVHVybk9mZlZlcmlmaWVyKCk7CisKKyAgICByZXR1cm4gYWRv cHRSZWYoaGFuZGxlKTsKIH0KIAogTWV0YUFsbG9jYXRvcjo6U3RhdGlzdGljcyBNZXRhQWxsb2Nh dG9yOjpjdXJyZW50U3RhdGlzdGljcygpCg== 110103 2011-10-07 01:36:12 -0700 2011-10-07 01:36:12 -0700 Alternative patch bug-69599-20111007173610.patch text/plain 1851 dominicc U3VidmVyc2lvbiBSZXZpc2lvbjogOTY4NjgKZGlmZiAtLWdpdCBhL1NvdXJjZS9KYXZhU2NyaXB0 Q29yZS9DaGFuZ2VMb2cgYi9Tb3VyY2UvSmF2YVNjcmlwdENvcmUvQ2hhbmdlTG9nCmluZGV4IDI5 ZDg3MzNjNjY1NWNmNmQzMDQxMTVkYjIyZGE3YzU1OTBkMWE3YjIuLjJiMmZlOTZkNDEzMzk0NjBh ZDRkYmIyY2Y1YjExODY4ODI3MDVkNDAgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9KYXZhU2NyaXB0Q29y ZS9DaGFuZ2VMb2cKKysrIGIvU291cmNlL0phdmFTY3JpcHRDb3JlL0NoYW5nZUxvZwpAQCAtMSwz ICsxLDIwIEBACisyMDExLTEwLTA3ICBEb21pbmljIENvb25leSAgPGRvbWluaWNjQGNocm9taXVt Lm9yZz4KKworICAgICAgICBbSlNDXSBNYWtlIE1ldGFBbGxvY2F0b3JIYW5kbGVzIFRocmVhZFNh ZmVSZWZDb3VudGVkCisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNn aT9pZD02OTU5OQorCisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisgICAg ICAgIE1ldGFBbGxvY2F0b3JIYW5kbGUgcmVmY291bnRzIGNhbiBiZSBzaGFyZWQgYWNyb3NzIHRo ZSBuZXR3b3JrCisgICAgICAgIHRocmVhZCBleGVjdXRpbmcgcHJveHkgUEFDIGZpbGVzIGFuZCBt YWluIHRocmVhZCBleGVjdXRpbmcKKyAgICAgICAgSmF2YVNjcmlwdCBpbiBwYWdlcy4gU28gdGhl eSBzaG91bGQgYmUgVGhyZWFkU2FmZVJlZkNvdW50ZWQuCisKKyAgICAgICAgVGVzdD1zZXQgcHJv eHkgYXV0b2NvbmZpZ3VyYXRpb24gUEFDIGZpbGUsIGRlYnVnIGJ1aWxkLCBydW4gdGVzdHMKKyAg ICAgICAgYW5kIG9ic2VydmUgYWJzZW5jZSBvZiBBU1NFUlQobV92ZXJpZmllci5pc1NhZmVUb1Vz ZSgpKSBmYWlsdXJlcworICAgICAgICBpbiBNZXRhQWxsb2NhdG9ySGFuZGxlOjpkZXJlZi4KKwor ICAgICAgICAqIHd0Zi9NZXRhQWxsb2NhdG9ySGFuZGxlLmg6CisKIDIwMTEtMTAtMDYgIEZpbGlw IFBpemxvICA8ZnBpemxvQGFwcGxlLmNvbT4KIAogICAgICAgICBERkcgaW1wbGVtZW50YXRpb24g b2YgVUludDMyVG9OdW1iZXIgaXMgbWlzc2luZyBhIGJyZWFrIHN0YXRlbWVudApkaWZmIC0tZ2l0 IGEvU291cmNlL0phdmFTY3JpcHRDb3JlL3d0Zi9NZXRhQWxsb2NhdG9ySGFuZGxlLmggYi9Tb3Vy Y2UvSmF2YVNjcmlwdENvcmUvd3RmL01ldGFBbGxvY2F0b3JIYW5kbGUuaAppbmRleCAxMjBmNmJk Mzg2N2I1OGJmZjY2NTkzZWI1YjA0NmMyZTM5NTMxMjkyLi5hYzMzYWJhNjVjM2QwM2MzN2ZlYzQw NTYyYWVjOTc0YmM5MzUyZjU0IDEwMDY0NAotLS0gYS9Tb3VyY2UvSmF2YVNjcmlwdENvcmUvd3Rm L01ldGFBbGxvY2F0b3JIYW5kbGUuaAorKysgYi9Tb3VyY2UvSmF2YVNjcmlwdENvcmUvd3RmL01l dGFBbGxvY2F0b3JIYW5kbGUuaApAQCAtMzAsMTQgKzMwLDE0IEBACiAjZGVmaW5lIFdURl9NZXRh QWxsb2NhdG9ySGFuZGxlX2gKIAogI2luY2x1ZGUgPHd0Zi9Bc3NlcnRpb25zLmg+Ci0jaW5jbHVk ZSA8d3RmL1JlZkNvdW50ZWQuaD4KKyNpbmNsdWRlIDx3dGYvVGhyZWFkU2FmZVJlZkNvdW50ZWQu aD4KICNpbmNsdWRlIDx3dGYvUmVmUHRyLmg+CiAKIG5hbWVzcGFjZSBXVEYgewogCiBjbGFzcyBN ZXRhQWxsb2NhdG9yOwogCi1jbGFzcyBNZXRhQWxsb2NhdG9ySGFuZGxlOiBwdWJsaWMgUmVmQ291 bnRlZDxNZXRhQWxsb2NhdG9ySGFuZGxlPiB7CitjbGFzcyBNZXRhQWxsb2NhdG9ySGFuZGxlOiBw dWJsaWMgVGhyZWFkU2FmZVJlZkNvdW50ZWQ8TWV0YUFsbG9jYXRvckhhbmRsZT4gewogcHJpdmF0 ZToKICAgICBNZXRhQWxsb2NhdG9ySGFuZGxlKE1ldGFBbGxvY2F0b3IqLCB2b2lkKiBzdGFydCwg c2l6ZV90IHNpemVJbkJ5dGVzKTsKICAgICAK