20777 2008-09-11 03:57:44 -0700 [CURL] memory leak of ResouceHandles 2008-12-19 08:03:58 -0800 1 1 1 Unclassified WebKit WebKitGTK 528+ (Nightly build) All All RESOLVED FIXED Curl P2 Normal --- 1 marco.barisione marco.barisione fmarmond marco.barisione mike.emmel zaheer.mot zuh oldest_to_newest 90841 0 marco.barisione 2008-09-11 03:57:44 -0700 ResourceHandle::start increases the ref count of the handle but this is never decrease so we leak ResourceHandles, see See https://lists.webkit.org/pipermail/webkit-dev/2008-September/004851.html Patch coming soon. 90842 1 23343 marco.barisione 2008-09-11 04:07:35 -0700 Created attachment 23343 Fix the leak Delete the ResourceHandle when the job is completed or there is an error. I used delete directly instead of deref because the win port is doing the same. 90868 2 mike.emmel 2008-09-11 09:34:41 -0700 This probably causes a crash it did last time I tried it. You need to verify that the loader code which owns the handle never references it past this point. I had to deref in the next run of the event loop. 90869 3 marco.barisione 2008-09-11 09:41:07 -0700 (In reply to comment #2) > This probably causes a crash it did last time I tried it. You need to verify > that the loader code which owns the handle never references it past this point. I used WebKit compiled with this patch for normal navigation and I didn't get any crash, but probably there are corner cases they I was not able to reproduce. > I had to deref in the next run of the event loop. I wonder why the win port uses delete instead of deref, if we want to be more sure that nothing bad is going to happen we could deref the ResourceHandle in the next run of the event loop. 90870 4 mike.emmel 2008-09-11 09:45:22 -0700 Have you looked at the ncurl patch ? 90958 5 23343 eric 2008-09-12 12:26:57 -0700 Comment on attachment 23343 Fix the leak I hate this kind of memory management. (Nothing personal). Could we change this API so that it either used ref-counting, or didn't have this kind of single-ownership memory model burried inside these functions which are named "remove" and not "destroy". Why is it clear that passing something for removal should destroy it!? 90962 6 mike.emmel 2008-09-12 12:46:04 -0700 (In reply to comment #5) > (From update of attachment 23343 [edit]) > I hate this kind of memory management. (Nothing personal). Could we change > this API so that it either used ref-counting, or didn't have this kind of > single-ownership memory model burried inside these functions which are named > "remove" and not "destroy". Why is it clear that passing something for removal > should destroy it!? > Eric if the loader would up the reference count by one we can drop ours at the right time and destroy the backend resources correctly. The ref count should be two IMHO. 94230 7 marco.barisione 2008-10-06 08:34:23 -0700 (In reply to comment #5) > (From update of attachment 23343 [edit]) > I hate this kind of memory management. (Nothing personal). Could we change > this API so that it either used ref-counting, or didn't have this kind of > single-ownership memory model burried inside these functions which are named > "remove" and not "destroy". Why is it clear that passing something for removal > should destroy it!? I'm not sure to understand what you mean. I copied the direct use of delete from the Windows port, would be enough for you to deref the object instead of deleting it? 94235 8 mike.emmel 2008-10-06 10:17:14 -0700 Unless the code has changed you will see that the Ref is still accessed in the loader. By using delete the memory is referenced after its freed. 96172 9 fmarmond 2008-10-22 08:27:04 -0700 I worked on this bug, and found that upgrading libcurl from 7.18.0 to 7.18.2 fixed memory leak problems. Can you test please? 96201 10 mike.emmel 2008-10-22 11:47:14 -0700 (In reply to comment #9) > I worked on this bug, and found that upgrading libcurl from 7.18.0 to 7.18.2 > fixed memory leak problems. > Can you test please? > How did you get the ref count down to zero ? The problem with the current patch is it deletes pointer leaving the ref pointed at freed memory. 96297 11 fmarmond 2008-10-23 00:58:16 -0700 (In reply to comment #10) > (In reply to comment #9) > > How did you get the ref count down to zero ? > The problem with the current patch is it deletes pointer leaving the ref > pointed at freed memory. > In fact, I didn't want to say upgrading libcurl solved ALL memory leaks, but lots of them, which were inside libcurl 7.18.0. I thought that this info may be useful to guys who are reading this bug. Applying the attached patch didn't made any crash for me, and save few kB. upgrading libcurl saved me few MB (on gmail load, for example). 96298 12 mike.emmel 2008-10-23 01:02:43 -0700 Understood. Correct there are actually two issues. 100047 13 zuh 2008-11-24 13:40:31 -0800 (In reply to comment #7) > (In reply to comment #5) > > (From update of attachment 23343 [review] [edit]) > > I hate this kind of memory management. (Nothing personal). Could we change > > this API so that it either used ref-counting, or didn't have this kind of > > single-ownership memory model burried inside these functions which are named > > "remove" and not "destroy". Why is it clear that passing something for removal > > should destroy it!? > > I'm not sure to understand what you mean. I copied the direct use of delete > from the Windows port, would be enough for you to deref the object instead of > deleting it? I switched the delete's to derefs() and the ResourceHandle leaks vanished from valgrind (for the cases I tested with, eg. planet.gnome.org). Reading the code, the ResourceHandleCurl implementation adds a ref for itself (to protect against the ResourceLoader releasing it's ref) and then the ResourceHandleManager code removes it. Now, to me it looks like it would be clearer to move the ref from ResourceHandleCurl to ResourceHandleManager:add() so the ref is managed by ResourceHandleManager only. I can redo Marco's patch if needed, but let's get this fixed! :) 100100 14 mike.emmel 2008-11-24 16:30:16 -0800 You probably should take a look at the lifetime of the handle over in the loader code. The original problem was that the handle was accessed by the loader code after it was removed from curl and the loader code did not ref itself. I think what should happen is both curl and the loader code should ref the handle until neither is using it i.e the ref count should be two for a active handle. I suspect the loader code has been refactored to remove this problem. If so I may be wrong about needing the ref at all in curl you might be able to remove it. So if your not segfaulting now maybe we don't need to ref at all. Thats the best approach i.e the lifetime of the Reference is fully controlled by the loader code. 100166 15 zuh 2008-11-24 22:59:33 -0800 (In reply to comment #14) > You probably should take a look at the lifetime of the handle over in the > loader code. The original problem was that the handle was accessed by the > loader code after it was removed from curl and the loader code did not ref > itself. > > I think what should happen is both curl and the loader code should ref the > handle until neither is using it i.e the ref count should be two for a active > handle. > > I suspect the loader code has been refactored to remove this problem. If so I > may be wrong about needing the ref at all in curl you might be able to remove > it. Yes, I looked at the loader and it keeps a RefPtr of the ResourceHandle. I also checked that the refcount indeed was 2 when the handle comes in. The ref is really need for the curl manager since it needs to cleanup the curl side with the ResourceHandleInternal data and calling to the ResourceHandleClient callbacks might (and does) result in the client dropping its ref. I verified that whenever we hit the removeFromCurl() where the deref happens, the refcount was already 1 (ie. the client had released the ref). > So if your not segfaulting now maybe we don't need to ref at all. Thats the > best approach i.e the lifetime of the Reference is fully controlled by the > loader code. I'm not sure if that's easily possible as the curl seems to operate in async mode, but if the curl operations are reliably cancellable I suppose it would be doable by specifically cleaning the ongoing curl actions through ~ResourceHandle or so. But before rewriting it, the patch with the proposed modifications should do the Right Thing for the current situation. 100219 16 mike.emmel 2008-11-25 08:00:54 -0800 (In reply to comment #15) > (In reply to comment #14) > > You probably should take a look at the lifetime of the handle over in the > > loader code. The original problem was that the handle was accessed by the > > loader code after it was removed from curl and the loader code did not ref > > itself. > > > > I think what should happen is both curl and the loader code should ref the > > handle until neither is using it i.e the ref count should be two for a active > > handle. > > > > I suspect the loader code has been refactored to remove this problem. If so I > > may be wrong about needing the ref at all in curl you might be able to remove > > it. > > Yes, I looked at the loader and it keeps a RefPtr of the ResourceHandle. I also > checked that the refcount indeed was 2 when the handle comes in. The ref is > really need for the curl manager since it needs to cleanup the curl side with > the ResourceHandleInternal data and calling to the ResourceHandleClient > callbacks might (and does) result in the client dropping its ref. I verified > that whenever we hit the removeFromCurl() where the deref happens, the refcount > was already 1 (ie. the client had released the ref). > > > So if your not segfaulting now maybe we don't need to ref at all. Thats the > > best approach i.e the lifetime of the Reference is fully controlled by the > > loader code. > > I'm not sure if that's easily possible as the curl seems to operate in async > mode, but if the curl operations are reliably cancellable I suppose it would be > doable by specifically cleaning the ongoing curl actions through > ~ResourceHandle or so. > > But before rewriting it, the patch with the proposed modifications should do > the Right Thing for the current situation. > Yep should finally work correctly your right it can be cleaned up later. I'd say get it submitted. 102547 17 26023 zuh 2008-12-14 23:33:28 -0800 Created attachment 26023 Updated patch with refs() and manager-side refcount handling So finally I found time to create and attach the patch, but I noticed the warning about test cases in the changelog entry and am now wondering if that will block inclusion..? I have personally no experience in creating test cases so if someone would help with that (if needed), it'd be great... 102656 18 26023 zecke 2008-12-16 06:51:36 -0800 Comment on attachment 26023 Updated patch with refs() and manager-side refcount handling > diff --git a/WebCore/ChangeLog b/WebCore/ChangeLog > + WARNING: NO TEST CASES ADDED OR CHANGED Just remove this is if you think it is not testable. I would agree that testing this is incredible hard with a LayoutTest and from within the API... I will run run-webkit-tests and see if we crash... > index bbc31d4..ca24ec5 100644 > --- a/WebCore/platform/network/curl/ResourceHandleCurl.cpp > +++ b/WebCore/platform/network/curl/ResourceHandleCurl.cpp > @@ -104,7 +104,6 @@ ResourceHandle::~ResourceHandle() > bool ResourceHandle::start(Frame* frame) > { > ASSERT(frame); > - ref(); > ResourceHandleManager::sharedInstance()->add(this); > return true; > } yes! > diff --git a/WebCore/platform/network/curl/ResourceHandleManager.cpp b/WebCore/platform/network/curl/ResourceHandleManager.cpp > index 410f9eb..f1a2be4 100644 > --- a/WebCore/platform/network/curl/ResourceHandleManager.cpp > +++ b/WebCore/platform/network/curl/ResourceHandleManager.cpp > @@ -350,6 +350,7 @@ void ResourceHandleManager::removeFromCurl(ResourceHandle* job) > curl_multi_remove_handle(m_curlMultiHandle, d->m_handle); > curl_easy_cleanup(d->m_handle); > d->m_handle = 0; > + job->deref(); > } deref when the job was started and finished by curl? looks right. > > void ResourceHandleManager::setupPUT(ResourceHandle*, struct curl_slist**) > @@ -443,6 +444,7 @@ void ResourceHandleManager::add(ResourceHandle* job) > { > // we can be called from within curl, so to avoid re-entrancy issues > // schedule this job to be added the next time we enter curl download loop > + job->ref(); yupp, ref it when we start to handle it.. > if (job == m_resourceHandleList[i]) { > m_resourceHandleList.remove(i); > + job->deref(); > return true; Cool. It looks right. When we add something to m_resourceHandleList as ref the job, when we cancel/remove a not started job we deref, once curl finished (which means the job was started and removed from the m_resourceHandleList) we will deref it. 102661 19 zecke 2008-12-16 07:32:01 -0800 Landed in r39334. 102980 20 zecke 2008-12-19 08:03:58 -0800 Closing it. 23343 2008-09-11 04:07:35 -0700 2008-09-12 12:26:57 -0700 Fix the leak curl-leak.patch text/plain 1510 marco.barisione SW5kZXg6IFdlYkNvcmUvcGxhdGZvcm0vbmV0d29yay9jdXJsL1Jlc291cmNlSGFuZGxlTWFuYWdl ci5jcHAKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PQotLS0gV2ViQ29yZS9wbGF0Zm9ybS9uZXR3b3JrL2N1cmwvUmVzb3Vy Y2VIYW5kbGVNYW5hZ2VyLmNwcAkocmV2aXNpb25lIDM2MzMyKQorKysgV2ViQ29yZS9wbGF0Zm9y bS9uZXR3b3JrL2N1cmwvUmVzb3VyY2VIYW5kbGVNYW5hZ2VyLmNwcAkoY29waWEgbG9jYWxlKQpA QCAtMzI2LDYgKzMyNiw3IEBACiAgICAgY3VybF9tdWx0aV9yZW1vdmVfaGFuZGxlKG1fY3VybE11 bHRpSGFuZGxlLCBkLT5tX2hhbmRsZSk7CiAgICAgY3VybF9lYXN5X2NsZWFudXAoZC0+bV9oYW5k bGUpOwogICAgIGQtPm1faGFuZGxlID0gMDsKKyAgICBkZWxldGUgam9iOwogfQogCiB2b2lkIFJl c291cmNlSGFuZGxlTWFuYWdlcjo6c2V0dXBQVVQoUmVzb3VyY2VIYW5kbGUqLCBzdHJ1Y3QgY3Vy bF9zbGlzdCoqKQpAQCAtNDE0LDYgKzQxNSw3IEBACiAgICAgZm9yIChpbnQgaSA9IDA7IGkgPCBz aXplOyBpKyspIHsKICAgICAgICAgaWYgKGpvYiA9PSBtX3Jlc291cmNlSGFuZGxlTGlzdFtpXSkg ewogICAgICAgICAgICAgbV9yZXNvdXJjZUhhbmRsZUxpc3QucmVtb3ZlKGkpOworICAgICAgICAg ICAgZGVsZXRlIGpvYjsKICAgICAgICAgICAgIHJldHVybiB0cnVlOwogICAgICAgICB9CiAgICAg fQpJbmRleDogV2ViQ29yZS9DaGFuZ2VMb2cKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gV2ViQ29yZS9DaGFuZ2VM b2cJKHJldmlzaW9uZSAzNjMzMykKKysrIFdlYkNvcmUvQ2hhbmdlTG9nCShjb3BpYSBsb2NhbGUp CkBAIC0xLDMgKzEsMTcgQEAKKzIwMDgtMDktMTEgIE1hcmNvIEJhcmlzaW9uZSAgPG1hcmNvLmJh cmlzaW9uZUBjb2xsYWJvcmEuY28udWs+CisKKyAgICAgICAgUmV2aWV3ZWQgYnkgTk9CT0RZIChP T1BTISkuCisKKyAgICAgICAgW0NVUkxdIG1lbW9yeSBsZWFrIG9mIFJlc291Y2VIYW5kbGVzCisg ICAgICAgIGh0dHA6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lkPTIwNzc3CisKKyAg ICAgICAgUmVzb3VyY2VIYW5kbGVzIHdlcmUgbmV2ZXIgZnJlZWQgaW4gdGhlIENVUkwgcG9ydC4g VGhhbmtzIHRvIFphaGVlcgorICAgICAgICBBaG1hZCBmb3Igc3BvdHRpbmcgdGhlIGxlYWsuCisK KyAgICAgICAgKiBwbGF0Zm9ybS9uZXR3b3JrL2N1cmwvUmVzb3VyY2VIYW5kbGVNYW5hZ2VyLmNw cDoKKyAgICAgICAgKFdlYkNvcmU6OlJlc291cmNlSGFuZGxlTWFuYWdlcjo6cmVtb3ZlRnJvbUN1 cmwpOgorICAgICAgICAoV2ViQ29yZTo6UmVzb3VyY2VIYW5kbGVNYW5hZ2VyOjpyZW1vdmVTY2hl ZHVsZWRKb2IpOgorCiAyMDA4LTA5LTExICBEaXJrIFNjaHVsemUgIDx2YnM4NUBnbXguZGU+CiAK ICAgICAgICAgUmV2aWV3ZWQgYnkgU2ltb24uCg== 26023 2008-12-14 23:33:28 -0800 2008-12-16 06:51:36 -0800 Updated patch with refs() and manager-side refcount handling curl-resourcehandle-leak.diff text/plain 2710 zuh ZGlmZiAtLWdpdCBhL1dlYkNvcmUvQ2hhbmdlTG9nIGIvV2ViQ29yZS9DaGFuZ2VMb2cKaW5kZXgg ODhlZWRiZC4uMjgwMmIyMSAxMDA2NDQKLS0tIGEvV2ViQ29yZS9DaGFuZ2VMb2cKKysrIGIvV2Vi Q29yZS9DaGFuZ2VMb2cKQEAgLTEsMyArMSwyMiBAQAorMjAwOC0xMi0xMCAgS2FsbGUgVmFobG1h biAgPGthbGxlLnZhaGxtYW5AbW92aWFsLmNvbT4KKworICAgICAgICBSZXZpZXdlZCBieSBOT0JP RFkgKE9PUFMhKS4KKworICAgICAgICBbQ1VSTF0gbWVtb3J5IGxlYWsgb2YgUmVzb3VjZUhhbmRs ZXMKKyAgICAgICAgaHR0cDovL2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9MjA3NzcK KyAgICAgICAgCisgICAgICAgIEZpeCBSZXNvdXJjZUhhbmRsZSByZWYgbWFuYWdlbWVudCB0byBi ZSBjb25zaXN0ZW50IGFuZCBjb3JyZWN0LgorICAgICAgICBPcmlnaW5hbCBwYXRjaCBmcm9tIE1h cmNvIEJhcmlzaW9uZS4KKworICAgICAgICBXQVJOSU5HOiBOTyBURVNUIENBU0VTIEFEREVEIE9S IENIQU5HRUQKKworICAgICAgICAqIHBsYXRmb3JtL25ldHdvcmsvY3VybC9SZXNvdXJjZUhhbmRs ZUN1cmwuY3BwOgorICAgICAgICAoV2ViQ29yZTo6UmVzb3VyY2VIYW5kbGU6OnN0YXJ0KToKKyAg ICAgICAgKiBwbGF0Zm9ybS9uZXR3b3JrL2N1cmwvUmVzb3VyY2VIYW5kbGVNYW5hZ2VyLmNwcDoK KyAgICAgICAgKFdlYkNvcmU6OlJlc291cmNlSGFuZGxlTWFuYWdlcjo6cmVtb3ZlRnJvbUN1cmwp OgorICAgICAgICAoV2ViQ29yZTo6UmVzb3VyY2VIYW5kbGVNYW5hZ2VyOjphZGQpOgorICAgICAg ICAoV2ViQ29yZTo6UmVzb3VyY2VIYW5kbGVNYW5hZ2VyOjpyZW1vdmVTY2hlZHVsZWRKb2IpOgor CiAyMDA4LTEyLTA5ICBOaWtvbGFzIFppbW1lcm1hbm4gIDxuaWtvbGFzLnppbW1lcm1hbm5AdG9y Y2htb2JpbGUuY29tPgogCiAgICAgICAgIFJ1YmJlci1zdGFtcGVkIGJ5IEFsZXhleSBQcm9za3Vy eWFrb3YuCmRpZmYgLS1naXQgYS9XZWJDb3JlL3BsYXRmb3JtL25ldHdvcmsvY3VybC9SZXNvdXJj ZUhhbmRsZUN1cmwuY3BwIGIvV2ViQ29yZS9wbGF0Zm9ybS9uZXR3b3JrL2N1cmwvUmVzb3VyY2VI YW5kbGVDdXJsLmNwcAppbmRleCBiYmMzMWQ0Li5jYTI0ZWM1IDEwMDY0NAotLS0gYS9XZWJDb3Jl L3BsYXRmb3JtL25ldHdvcmsvY3VybC9SZXNvdXJjZUhhbmRsZUN1cmwuY3BwCisrKyBiL1dlYkNv cmUvcGxhdGZvcm0vbmV0d29yay9jdXJsL1Jlc291cmNlSGFuZGxlQ3VybC5jcHAKQEAgLTEwNCw3 ICsxMDQsNiBAQCBSZXNvdXJjZUhhbmRsZTo6flJlc291cmNlSGFuZGxlKCkKIGJvb2wgUmVzb3Vy Y2VIYW5kbGU6OnN0YXJ0KEZyYW1lKiBmcmFtZSkKIHsKICAgICBBU1NFUlQoZnJhbWUpOwotICAg IHJlZigpOwogICAgIFJlc291cmNlSGFuZGxlTWFuYWdlcjo6c2hhcmVkSW5zdGFuY2UoKS0+YWRk KHRoaXMpOwogICAgIHJldHVybiB0cnVlOwogfQpkaWZmIC0tZ2l0IGEvV2ViQ29yZS9wbGF0Zm9y bS9uZXR3b3JrL2N1cmwvUmVzb3VyY2VIYW5kbGVNYW5hZ2VyLmNwcCBiL1dlYkNvcmUvcGxhdGZv cm0vbmV0d29yay9jdXJsL1Jlc291cmNlSGFuZGxlTWFuYWdlci5jcHAKaW5kZXggNDEwZjllYi4u ZjFhMmJlNCAxMDA2NDQKLS0tIGEvV2ViQ29yZS9wbGF0Zm9ybS9uZXR3b3JrL2N1cmwvUmVzb3Vy Y2VIYW5kbGVNYW5hZ2VyLmNwcAorKysgYi9XZWJDb3JlL3BsYXRmb3JtL25ldHdvcmsvY3VybC9S ZXNvdXJjZUhhbmRsZU1hbmFnZXIuY3BwCkBAIC0zNTAsNiArMzUwLDcgQEAgdm9pZCBSZXNvdXJj ZUhhbmRsZU1hbmFnZXI6OnJlbW92ZUZyb21DdXJsKFJlc291cmNlSGFuZGxlKiBqb2IpCiAgICAg Y3VybF9tdWx0aV9yZW1vdmVfaGFuZGxlKG1fY3VybE11bHRpSGFuZGxlLCBkLT5tX2hhbmRsZSk7 CiAgICAgY3VybF9lYXN5X2NsZWFudXAoZC0+bV9oYW5kbGUpOwogICAgIGQtPm1faGFuZGxlID0g MDsKKyAgICBqb2ItPmRlcmVmKCk7CiB9CiAKIHZvaWQgUmVzb3VyY2VIYW5kbGVNYW5hZ2VyOjpz ZXR1cFBVVChSZXNvdXJjZUhhbmRsZSosIHN0cnVjdCBjdXJsX3NsaXN0KiopCkBAIC00NDMsNiAr NDQ0LDcgQEAgdm9pZCBSZXNvdXJjZUhhbmRsZU1hbmFnZXI6OmFkZChSZXNvdXJjZUhhbmRsZSog am9iKQogewogICAgIC8vIHdlIGNhbiBiZSBjYWxsZWQgZnJvbSB3aXRoaW4gY3VybCwgc28gdG8g YXZvaWQgcmUtZW50cmFuY3kgaXNzdWVzCiAgICAgLy8gc2NoZWR1bGUgdGhpcyBqb2IgdG8gYmUg YWRkZWQgdGhlIG5leHQgdGltZSB3ZSBlbnRlciBjdXJsIGRvd25sb2FkIGxvb3AKKyAgICBqb2It PnJlZigpOwogICAgIG1fcmVzb3VyY2VIYW5kbGVMaXN0LmFwcGVuZChqb2IpOwogICAgIGlmICgh bV9kb3dubG9hZFRpbWVyLmlzQWN0aXZlKCkpCiAgICAgICAgIG1fZG93bmxvYWRUaW1lci5zdGFy dE9uZVNob3QocG9sbFRpbWVTZWNvbmRzKTsKQEAgLTQ1NCw2ICs0NTYsNyBAQCBib29sIFJlc291 cmNlSGFuZGxlTWFuYWdlcjo6cmVtb3ZlU2NoZWR1bGVkSm9iKFJlc291cmNlSGFuZGxlKiBqb2Ip CiAgICAgZm9yIChpbnQgaSA9IDA7IGkgPCBzaXplOyBpKyspIHsKICAgICAgICAgaWYgKGpvYiA9 PSBtX3Jlc291cmNlSGFuZGxlTGlzdFtpXSkgewogICAgICAgICAgICAgbV9yZXNvdXJjZUhhbmRs ZUxpc3QucmVtb3ZlKGkpOworICAgICAgICAgICAgam9iLT5kZXJlZigpOwogICAgICAgICAgICAg cmV0dXJuIHRydWU7CiAgICAgICAgIH0KICAgICB9Cg==