96201 2012-09-09 04:10:43 -0700 [EFL][WK2] WKEinaSharedString needs a function to adopt eina stringshare. 2012-09-11 02:36:20 -0700 1 1 1 Unclassified WebKit WebKit EFL 528+ (Nightly build) Unspecified Unspecified RESOLVED FIXED P2 Normal --- 95672 0 bw80.lee webkit-unassigned cdumez gyuyoung.kim hausmann jinwoo7.song kenneth lucas.de.marchi mikhail.pozdnyakov rakuco webkit.review.bot oldest_to_newest 715474 0 bw80.lee 2012-09-09 04:10:43 -0700 WKEinaSharedString class needs some mechanism like adoptRef and PassRefPtr. Without this, calling additional eina_stringshare_del() function will be needed in some case for preventing memory leak. 715528 1 163001 bw80.lee 2012-09-09 10:21:27 -0700 Created attachment 163001 Patch 715539 2 163001 hausmann 2012-09-09 11:11:01 -0700 Comment on attachment 163001 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=163001&action=review > Source/WebKit2/UIProcess/API/cpp/efl/WKEinaSharedString.h:73 > +WK_EXPORT WKEinaSharedString adoptEinaStringShare(const char* string); Why not make it an overloaded constructor instead? WKEinaSharedString(AdoptTag, const char*) ? Seems more consistent with other adoption patterns in WebKit. 715650 3 163001 gyuyoung.kim 2012-09-09 18:03:54 -0700 Comment on attachment 163001 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=163001&action=review > Source/WebKit2/ChangeLog:8 > + WKEinaSharedString needs a to adopt eina stringshare directly. s/needs a to/needs to/g ? > Source/WebKit2/UIProcess/API/cpp/efl/WKEinaSharedString.h:67 > + // adopting constructor // adopting -> // Adopting 715690 4 bw80.lee 2012-09-09 21:07:12 -0700 (In reply to comment #2) > (From update of attachment 163001 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=163001&action=review > > > Source/WebKit2/UIProcess/API/cpp/efl/WKEinaSharedString.h:73 > > +WK_EXPORT WKEinaSharedString adoptEinaStringShare(const char* string); > > Why not make it an overloaded constructor instead? WKEinaSharedString(AdoptTag, const char*) ? Seems more consistent with other adoption patterns in WebKit. Yes, I considered using WKAdoptTag initially, but that seems to be designed to adopt data from api object type (WKXXX) that is related with APIObject and Opaque types. (This seems to be a reason that the adopt tag name is 'AdoptWK' - adopting WK api object) But the data that this function tries to adopt is not WK api object type, but eina stringshare which is provided by efl platform and has it's own ref, unref function - eina_stringshare_add, eina_stringshare_del) And Wrapper class for the eina stringshare is that WKEinaSharedString. So I decided not to use AdoptWK tag but add a function for adopt. (I referenced the adoptRef() function, and the function also defined as a friend function of PassRefPtr) If there is any way that I can apply the adoption pattern with AdoptTag, please share it. It will be very helpful. Thank you :) 715693 5 bw80.lee 2012-09-09 21:09:31 -0700 (In reply to comment #3) > (From update of attachment 163001 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=163001&action=review > > > Source/WebKit2/ChangeLog:8 > > + WKEinaSharedString needs a to adopt eina stringshare directly. > > s/needs a to/needs to/g ? Oops, typo. I'll fix it. > > > Source/WebKit2/UIProcess/API/cpp/efl/WKEinaSharedString.h:67 > > + // adopting constructor > > // adopting -> // Adopting Ok~ I'll fix it. 715710 6 hausmann 2012-09-09 22:05:54 -0700 (In reply to comment #4) > (In reply to comment #2) > > (From update of attachment 163001 [details] [details]) > > View in context: https://bugs.webkit.org/attachment.cgi?id=163001&action=review > > > > > Source/WebKit2/UIProcess/API/cpp/efl/WKEinaSharedString.h:73 > > > +WK_EXPORT WKEinaSharedString adoptEinaStringShare(const char* string); > > > > Why not make it an overloaded constructor instead? WKEinaSharedString(AdoptTag, const char*) ? Seems more consistent with other adoption patterns in WebKit. > > > Yes, I considered using WKAdoptTag initially, but that seems to be designed to adopt data from api object type (WKXXX) that is related with APIObject and Opaque types. > (This seems to be a reason that the adopt tag name is 'AdoptWK' - adopting WK api object) > > But the data that this function tries to adopt is not WK api object type, but eina stringshare which is provided by efl platform and has it's own ref, unref function - eina_stringshare_add, eina_stringshare_del) > And Wrapper class for the eina stringshare is that WKEinaSharedString. > So I decided not to use AdoptWK tag but add a function for adopt. > (I referenced the adoptRef() function, and the function also defined as a friend function of PassRefPtr) > > If there is any way that I can apply the adoption pattern with AdoptTag, please share it. It will be very helpful. Don't worry, I doubt anybody is going to complain if you decide to use the pattern in a slightly different way in _your_ API :) That said, it's completely up to you. This is a question of aesthetics, i.e. which approach you find more readable on the caller side and which approach creates a cleaner implementation. You could also consider using a new tag, like AdoptCF and AdoptNS are used in WTF for the adoption of CoreFoundation and NextStep objects that follow the same reference counting pattern. Anyway, just saying that it's up to you - whichever you like better. 715723 7 bw80.lee 2012-09-09 22:39:01 -0700 (In reply to comment #6) > (In reply to comment #4) > > (In reply to comment #2) > > > (From update of attachment 163001 [details] [details] [details]) > > > View in context: https://bugs.webkit.org/attachment.cgi?id=163001&action=review > > > > > > > Source/WebKit2/UIProcess/API/cpp/efl/WKEinaSharedString.h:73 > > > > +WK_EXPORT WKEinaSharedString adoptEinaStringShare(const char* string); > > > > > > Why not make it an overloaded constructor instead? WKEinaSharedString(AdoptTag, const char*) ? Seems more consistent with other adoption patterns in WebKit. > > > > > > Yes, I considered using WKAdoptTag initially, but that seems to be designed to adopt data from api object type (WKXXX) that is related with APIObject and Opaque types. > > (This seems to be a reason that the adopt tag name is 'AdoptWK' - adopting WK api object) > > > > But the data that this function tries to adopt is not WK api object type, but eina stringshare which is provided by efl platform and has it's own ref, unref function - eina_stringshare_add, eina_stringshare_del) > > And Wrapper class for the eina stringshare is that WKEinaSharedString. > > So I decided not to use AdoptWK tag but add a function for adopt. > > (I referenced the adoptRef() function, and the function also defined as a friend function of PassRefPtr) > > > > If there is any way that I can apply the adoption pattern with AdoptTag, please share it. It will be very helpful. > > Don't worry, I doubt anybody is going to complain if you decide to use the pattern in a slightly different way in _your_ API :) > > That said, it's completely up to you. This is a question of aesthetics, i.e. which approach you find more readable on the caller side and which approach creates a cleaner implementation. > > You could also consider using a new tag, like AdoptCF and AdoptNS are used in WTF for the adoption of CoreFoundation and NextStep objects that follow the same reference counting pattern. > > Anyway, just saying that it's up to you - whichever you like better. Thank you for the kind explanation. A thought about creating a new tag like below, but I'm not sure whether this is acceptable. Source/WebKit2/UIProcess/API/cpp/efl/WKEinaSharedString.h ... + enum EinaAdoptTag { AdoptEinaStringShare }; ... + WKEinaSharedString(EinaAdoptTag, const char* string); Source/WebKit2/UIProcess/API/cpp/efl/WKEinaSharedString.cpp *WKEinaSharedString::WKEinaSharedString(EinaAdoptTag adoptTag, const char* string) + : m_string(string) +{ + ASSERT(adoptTag == AdoptEinaStringShare); // Guard for future enum chang +} How about this approach? I think this is more simple and matches with other adoptation. 715776 8 163001 mikhail.pozdnyakov 2012-09-10 00:24:26 -0700 Comment on attachment 163001 Patch At first WKEinaSharedString class contains already WKEinaSharedString(WKAdoptTag, WKStringRef); so there is no need to inject friend functions and private constructors, you can follow existing pattern. Secondly, WKAdoptTag is quite OK to use here IMHO, and it will look much more readable than just 'bool'. Thirdly, adoption is needed for the strings which have been already shared, right? So why don't you point that out? We could use 'Eina_Stringshare *' type for the argument. Informal R- 715802 9 bw80.lee 2012-09-10 01:04:06 -0700 (In reply to comment #8) > (From update of attachment 163001 [details]) > At first WKEinaSharedString class contains already WKEinaSharedString(WKAdoptTag, WKStringRef); so there is no need to inject friend functions > and private constructors, you can follow existing pattern. This patch is come from the patch 95672 for some requirement that handles eina stringhshare data that run_javascript_prompt() callback returns. (I think that the callback cannot return WKStringRef because it is the smart class member function) In the application side, eina stringshare will be returned by the callback. For preventing memory leak, adopt function for eina stringshare is needed. > Secondly, WKAdoptTag is quite OK to use here IMHO, and it will look much more readable than just 'bool'. Is it ok to use WKAdoptTag (adoptWK) for eina_stringshare even if it is not a WK api object? > Thirdly, adoption is needed for the strings which have been already shared, right? So why don't you point that out? We could use > 'Eina_Stringshare *' type for the argument. Thanks for pointing this. It will be more clear than const char* 715816 10 mikhail.pozdnyakov 2012-09-10 01:21:11 -0700 (In reply to comment #9) > (In reply to comment #8) > > (From update of attachment 163001 [details] [details]) > > At first WKEinaSharedString class contains already WKEinaSharedString(WKAdoptTag, WKStringRef); so there is no need to inject friend functions > > and private constructors, you can follow existing pattern. > This patch is come from the patch 95672 for some requirement that handles eina stringhshare data that run_javascript_prompt() callback returns. > (I think that the callback cannot return WKStringRef because it is the smart class member function) > In the application side, eina stringshare will be returned by the callback. > For preventing memory leak, adopt function for eina stringshare is needed. > I just meant that it should be just (one more) adopt constructor and not adopt function. > > Secondly, WKAdoptTag is quite OK to use here IMHO, and it will look much more readable than just 'bool'. > Is it ok to use WKAdoptTag (adoptWK) for eina_stringshare even if it is not a WK api object? I think yes, unless we want to introduce our own tag, I would use existing one.. 715822 11 mikhail.pozdnyakov 2012-09-10 01:30:05 -0700 > > Is it ok to use WKAdoptTag (adoptWK) for eina_stringshare even if it is not a WK api object? > > I think yes, unless we want to introduce our own tag, I would use existing > one.. Another option is to add a new static member like 'static WKEinaSharedString fromEinaStringShare(Eina_Stringshare*);' 715878 12 bw80.lee 2012-09-10 02:57:57 -0700 (In reply to comment #11) > > > Is it ok to use WKAdoptTag (adoptWK) for eina_stringshare even if it is not a WK api object? > > > > I think yes, unless we want to introduce our own tag, I would use existing > > one.. I think using WKAdoptTag for eina_stringshare can make human mistakes or misunderstanding, because some related template functions and class (e.g. WKRetainPtr, adoptWK()...) are also opened by cpp apis. If a constructor uses WKAdoptTag for adopting eina_stringshare, api user can try to use adoptWK() function for eina_stringshare, because it already used in the header file. How about your opinion? > Another option is to add a new static member like 'static WKEinaSharedString fromEinaStringShare(Eina_Stringshare*);' Ok, I think this is the issue about static function and friend function. I also thought about this, and followed the way that adoptPtr() or adoptRef() is designed because it is slightly easy for api users. With static function, create sharedstring by adoption will be as below WKEinaSharedString string = WKEinaSharedString::fromEinaStringShare(eina_stringshare_add(testString)) And with friend function, create sharedstring by adoption will be as below WKEinaSharedString string = adoptEinaStringShare(eina_stringshare_add(testString)) after we added below line in the header file. + using WebKit::adoptEinaStringShare(...); I prefer the second personally (for an api user), but If there is some reason that this should be a static function, I'll change it. Thanks for your comments :) 715883 13 mikhail.pozdnyakov 2012-09-10 03:12:36 -0700 (In reply to comment #12) > (In reply to comment #11) > > > > Is it ok to use WKAdoptTag (adoptWK) for eina_stringshare even if it is not a WK api object? > > > > > > I think yes, unless we want to introduce our own tag, I would use existing > > > one.. > I think using WKAdoptTag for eina_stringshare can make human mistakes or misunderstanding, because some related template functions and class (e.g. WKRetainPtr, adoptWK()...) are also opened by cpp apis. > > If a constructor uses WKAdoptTag for adopting eina_stringshare, api user can try to use adoptWK() function for eina_stringshare, because it already used in the header file. > > How about your opinion? > > > Another option is to add a new static member like 'static WKEinaSharedString fromEinaStringShare(Eina_Stringshare*);' > Ok, I think this is the issue about static function and friend function. > > I also thought about this, and followed the way that adoptPtr() or adoptRef() is designed because it is slightly easy for api users. > > With static function, > create sharedstring by adoption will be as below > WKEinaSharedString string = WKEinaSharedString::fromEinaStringShare(eina_stringshare_add(testString)) > > And with friend function, > create sharedstring by adoption will be as below > WKEinaSharedString string = adoptEinaStringShare(eina_stringshare_add(testString)) > > after we added below line in the header file. > + using WebKit::adoptEinaStringShare(...); > > I prefer the second personally (for an api user), but If there is some reason that this should be a static function, I'll change it. > > Thanks for your comments :) I would personally go with static function approach, as it looks more explicit for me and produces better-looking code.. But let's see what reviewers will tell. We could think also about how to to make the method name shorter, what about WKEinaSharedString::adopt() ? 715895 14 bw80.lee 2012-09-10 03:43:57 -0700 (In reply to comment #13) > (In reply to comment #12) > > (In reply to comment #11) > > > > > Is it ok to use WKAdoptTag (adoptWK) for eina_stringshare even if it is not a WK api object? > > > > > > > > I think yes, unless we want to introduce our own tag, I would use existing > > > > one.. > > I think using WKAdoptTag for eina_stringshare can make human mistakes or misunderstanding, because some related template functions and class (e.g. WKRetainPtr, adoptWK()...) are also opened by cpp apis. > > > > If a constructor uses WKAdoptTag for adopting eina_stringshare, api user can try to use adoptWK() function for eina_stringshare, because it already used in the header file. > > > > How about your opinion? > > > > > Another option is to add a new static member like 'static WKEinaSharedString fromEinaStringShare(Eina_Stringshare*);' > > Ok, I think this is the issue about static function and friend function. > > > > I also thought about this, and followed the way that adoptPtr() or adoptRef() is designed because it is slightly easy for api users. > > > > With static function, > > create sharedstring by adoption will be as below > > WKEinaSharedString string = WKEinaSharedString::fromEinaStringShare(eina_stringshare_add(testString)) > > > > And with friend function, > > create sharedstring by adoption will be as below > > WKEinaSharedString string = adoptEinaStringShare(eina_stringshare_add(testString)) > > > > after we added below line in the header file. > > + using WebKit::adoptEinaStringShare(...); > > > > I prefer the second personally (for an api user), but If there is some reason that this should be a static function, I'll change it. > > > > Thanks for your comments :) > I would personally go with static function approach, as it looks more explicit for me and produces better-looking code.. But let's see what reviewers will tell. We could think also about how to to make the method name shorter, what about WKEinaSharedString::adopt() ? Ok, it can be more explicit as you said, and short function name will be good for using. I'll apply it. Thanks :) 715897 15 kenneth 2012-09-10 03:48:31 -0700 > Ok, it can be more explicit as you said, and short function name will be good for using. > I'll apply it. Thanks :) adoptEinaStringShare() WKEinaSharedString::adopt() Are pretty much the same length and the latter doesn't require you to add any 'using' lines. 715921 16 bw80.lee 2012-09-10 04:23:54 -0700 (In reply to comment #15) > > Ok, it can be more explicit as you said, and short function name will be good for using. > > I'll apply it. Thanks :) > > adoptEinaStringShare() > WKEinaSharedString::adopt() > > Are pretty much the same length and the latter doesn't require you to add any 'using' lines. Yes, I'm applying it. Thanks for point other good point :) 715923 17 jinwoo7.song 2012-09-10 04:31:54 -0700 BTW, the class name, WKEinaSharedString seems to be out of sync with EFL's Eina_StringShare. http://docs.enlightenment.org/auto/eina/group__Eina__Stringshare__Group.html Is there anyone who knows the reason? IMO, WKEinaStringShare looks more consistent. 715929 18 mikhail.pozdnyakov 2012-09-10 04:40:55 -0700 (In reply to comment #17) > BTW, the class name, WKEinaSharedString seems to be out of sync with EFL's Eina_StringShare. > http://docs.enlightenment.org/auto/eina/group__Eina__Stringshare__Group.html > > Is there anyone who knows the reason? IMO, WKEinaStringShare looks more consistent. The existing name better reflects purpose of this class. WKEinaSharedString represents 'string' rather than 'share'. 716009 19 163110 bw80.lee 2012-09-10 06:17:15 -0700 Created attachment 163110 Patch 716011 20 163110 mikhail.pozdnyakov 2012-09-10 06:21:54 -0700 Comment on attachment 163110 Patch LGTM. Thanks. 716097 21 163110 kenneth 2012-09-10 08:23:36 -0700 Comment on attachment 163110 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=163110&action=review > Source/WebKit2/UIProcess/API/cpp/efl/WKEinaSharedString.cpp:114 > +{ > + WKEinaSharedString sharedString; > + sharedString.m_string = static_cast<const char*>(string); > + return sharedString; > +} So that will copy and deallocate the local one. I suppose the copy constructor is effective :-) 716737 22 bw80.lee 2012-09-10 17:55:47 -0700 (In reply to comment #21) > (From update of attachment 163110 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=163110&action=review > > > Source/WebKit2/UIProcess/API/cpp/efl/WKEinaSharedString.cpp:114 > > +{ > > + WKEinaSharedString sharedString; > > + sharedString.m_string = static_cast<const char*>(string); > > + return sharedString; > > +} > > So that will copy and deallocate the local one. I suppose the copy constructor is effective :-) Ok~ then I'll add some private constructor that just adopt eina_stringshare, and use it. But I have a question. On the previous patch, I defined the private constructor like below. + // Aopting constructor + WKEinaSharedString(Eina_Stringshare* string, bool) : m_string(string) { } I referenced the adopting constructor of PassRefPtr. Additional bool parameter seems to have some purpose for preventing some mistakes. Should I follow this way for WKEinaSharedString? 716896 23 kenneth 2012-09-11 00:22:18 -0700 (In reply to comment #22) > (In reply to comment #21) > > (From update of attachment 163110 [details] [details]) > > View in context: https://bugs.webkit.org/attachment.cgi?id=163110&action=review > > > > > Source/WebKit2/UIProcess/API/cpp/efl/WKEinaSharedString.cpp:114 > > > +{ > > > + WKEinaSharedString sharedString; > > > + sharedString.m_string = static_cast<const char*>(string); > > > + return sharedString; > > > +} > > > > So that will copy and deallocate the local one. I suppose the copy constructor is effective :-) > Ok~ then I'll add some private constructor that just adopt eina_stringshare, and use it. The code is fine, I just wanted you to verify that the copying is efficient. Or if not, implement an efficient copy constructor. I guess the class only has one pointer (m_string?) so it is quite efficient 716898 24 bw80.lee 2012-09-11 00:27:22 -0700 > The code is fine, I just wanted you to verify that the copying is efficient. Or if not, implement an efficient copy constructor. I guess the class only has one pointer (m_string?) so it is quite efficient I also think that copy constructor will be good and efficient if the coding style is ok. Thank you for your guide :) 716904 25 163110 kenneth 2012-09-11 00:32:33 -0700 Comment on attachment 163110 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=163110&action=review > Source/WebKit2/UIProcess/API/efl/tests/test_ewk2_eina_shared_string.cpp:87 > + WKEinaSharedString string(WKEinaSharedString::adopt(eina_stringshare_add(testString))); > + checkString(string, testString); > + > + string = WKEinaSharedString::adopt(eina_stringshare_add(anotherTestString)); > + checkString(string, anotherTestString); > + > + string = string; > + checkString(string, anotherTestString); Why not test that the first one got free'd? 716919 26 bw80.lee 2012-09-11 00:53:46 -0700 (In reply to comment #25) > (From update of attachment 163110 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=163110&action=review > > > Source/WebKit2/UIProcess/API/efl/tests/test_ewk2_eina_shared_string.cpp:87 > > + WKEinaSharedString string(WKEinaSharedString::adopt(eina_stringshare_add(testString))); > > + checkString(string, testString); > > + > > + string = WKEinaSharedString::adopt(eina_stringshare_add(anotherTestString)); > > + checkString(string, anotherTestString); > > + > > + string = string; > > + checkString(string, anotherTestString); > > Why not test that the first one got free'd? Yes, I want to test it, but I think there is no way to verify whether the first one got free'd or not, because there is no api to get the reference count for the eina_stringshare, and accessing free'd eina_stringshare can make segmentation fault according to the eina_stringshare.h The thing that we can get from this test case is that, eina_stringshare_del() function in WKEinaSharedString destructor will not make a segmentation fault even if we created it by adopting eina_stringshare directly (without eina_stringshare_ref()). With this, I can think that the eina_stringshare that adopted by WKEinaSharedString will be deallocated by it's destructor. 716928 27 bw80.lee 2012-09-11 01:13:10 -0700 I'm applying the last comment from kenneth about coping constructor. 716938 28 163299 bw80.lee 2012-09-11 01:29:05 -0700 Created attachment 163299 Patch 716939 29 163299 webkit.review.bot 2012-09-11 01:29:30 -0700 Comment on attachment 163299 Patch Rejecting attachment 163299 from commit-queue. bw80.lee@samsung.com does not have committer permissions according to http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/common/config/committers.py. - If you do not have committer rights please read http://webkit.org/coding/contributing.html for instructions on how to use bugzilla flags. - If you have committer rights please correct the error in Tools/Scripts/webkitpy/common/config/committers.py by adding yourself to the file (no review needed). The commit-queue restarts itself every 2 hours. After restart the commit-queue will correctly respect your committer rights. 716979 30 163110 webkit.review.bot 2012-09-11 02:36:14 -0700 Comment on attachment 163110 Patch Clearing flags on attachment: 163110 Committed r128160: <http://trac.webkit.org/changeset/128160> 716980 31 webkit.review.bot 2012-09-11 02:36:20 -0700 All reviewed patches have been landed. Closing bug. 163001 2012-09-09 10:21:27 -0700 2012-09-10 06:17:05 -0700 Patch bug-96201-20120910022103.patch text/plain 3733 bw80.lee U3VidmVyc2lvbiBSZXZpc2lvbjogMTI3MzcxCmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViS2l0Mi9D aGFuZ2VMb2cgYi9Tb3VyY2UvV2ViS2l0Mi9DaGFuZ2VMb2cKaW5kZXggZTVjNjI1MTczMDg5YzZm MzVjNjE2N2UwMmY0YmZjMjQ4YmMxZGJjMC4uZGNkMTA3NTg1NzlmODllZTMzMWExN2U0YzJhOTg0 NjBlOWQzZWMxNyAxMDA2NDQKLS0tIGEvU291cmNlL1dlYktpdDIvQ2hhbmdlTG9nCisrKyBiL1Nv dXJjZS9XZWJLaXQyL0NoYW5nZUxvZwpAQCAtMSwzICsxLDIyIEBACisyMDEyLTA5LTA5ICBCeXVu Z3dvbyBMZWUgIDxidzgwLmxlZUBzYW1zdW5nLmNvbT4KKworICAgICAgICBbRUZMXVtXSzJdIFdL RWluYVNoYXJlZFN0cmluZyBuZWVkcyBhIGZ1bmN0aW9uIHRvIGFkb3B0IGVpbmEgc3RyaW5nc2hh cmUuCisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD05NjIw MQorCisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAgIFdLRWlu YVNoYXJlZFN0cmluZyBuZWVkcyBhIHRvIGFkb3B0IGVpbmEgc3RyaW5nc2hhcmUgZGlyZWN0bHku CisgICAgICAgIAorICAgICAgICBXaXRoIHRoaXMgYWRvcHQgZnVuY3Rpb24sIGFuIGluc3RhbmNl IHRoYXQgaXMgZGlyZWN0bHkgY3JlYXRlZCB3aXRoCisgICAgICAgIGVpbmFfc3RyaW5nc2hhcmVf YWRkKCkgY2FuIGJlIGVhc2lseSBoYW5kbGVkIGJ5IFdLRWluYVNoYXJlZFN0cmluZworICAgICAg ICB3aXRob3V0IGNhbGxpbmcgZWluYV9zdHJpbmdzaGFyZV9kZWwoKSBmb3IgcHJldmVudGluZyBt ZW1vcnkgbGVhay4KKworICAgICAgICAqIFVJUHJvY2Vzcy9BUEkvY3BwL2VmbC9XS0VpbmFTaGFy ZWRTdHJpbmcuY3BwOgorICAgICAgICAoV2ViS2l0OjphZG9wdEVpbmFTdHJpbmdTaGFyZSk6Cisg ICAgICAgICogVUlQcm9jZXNzL0FQSS9jcHAvZWZsL1dLRWluYVNoYXJlZFN0cmluZy5oOgorICAg ICAgICAqIFVJUHJvY2Vzcy9BUEkvZWZsL3Rlc3RzL3Rlc3RfZXdrMl9laW5hX3NoYXJlZF9zdHJp bmcuY3BwOgorICAgICAgICAoVEVTVF9GKToKKwogMjAxMi0wOC0zMSAgQnl1bmd3b28gTGVlICA8 Ync4MC5sZWVAc2Ftc3VuZy5jb20+CiAKICAgICAgICAgQnVpbGQgd2FybmluZyA6IC1XZm9ybWF0 IG9uIFdlYk1lbW9yeVNhbXBsZXIuY3BwLgpkaWZmIC0tZ2l0IGEvU291cmNlL1dlYktpdDIvVUlQ cm9jZXNzL0FQSS9jcHAvZWZsL1dLRWluYVNoYXJlZFN0cmluZy5jcHAgYi9Tb3VyY2UvV2ViS2l0 Mi9VSVByb2Nlc3MvQVBJL2NwcC9lZmwvV0tFaW5hU2hhcmVkU3RyaW5nLmNwcAppbmRleCBlYTQz ZGYxNjdhZmQwNmUzMDZkMGMyN2Y2ZmNmOWZhMzFlMjEyOGI1Li5iMjI4YmY1MDViMTM2MDBmMmVj MjA4MzJkNzYzODBhYTMyMjEzOTBhIDEwMDY0NAotLS0gYS9Tb3VyY2UvV2ViS2l0Mi9VSVByb2Nl c3MvQVBJL2NwcC9lZmwvV0tFaW5hU2hhcmVkU3RyaW5nLmNwcAorKysgYi9Tb3VyY2UvV2ViS2l0 Mi9VSVByb2Nlc3MvQVBJL2NwcC9lZmwvV0tFaW5hU2hhcmVkU3RyaW5nLmNwcApAQCAtMzMsNiAr MzMsMTEgQEAKIAogdXNpbmcgbmFtZXNwYWNlIFdlYktpdDsKIAorV0tFaW5hU2hhcmVkU3RyaW5n IFdlYktpdDo6YWRvcHRFaW5hU3RyaW5nU2hhcmUoY29uc3QgY2hhciogc3RyaW5nKQoreworICAg IHJldHVybiBXS0VpbmFTaGFyZWRTdHJpbmcoc3RyaW5nLCB0cnVlKTsKK30KKwogdGVtcGxhdGUg PHR5cGVuYW1lIFdLUmVmVHlwZT4KIEFMV0FZU19JTkxJTkUgY29uc3QgY2hhciogZnJvbVJlZlR5 cGUoV0tSZWZUeXBlIHN0clJlZiwgYm9vbCBhZG9wdCA9IGZhbHNlKQogewpkaWZmIC0tZ2l0IGEv U291cmNlL1dlYktpdDIvVUlQcm9jZXNzL0FQSS9jcHAvZWZsL1dLRWluYVNoYXJlZFN0cmluZy5o IGIvU291cmNlL1dlYktpdDIvVUlQcm9jZXNzL0FQSS9jcHAvZWZsL1dLRWluYVNoYXJlZFN0cmlu Zy5oCmluZGV4IDY4ZDc2ZjRlYWQxYmJjYmQ5ZTU0NWNlOWRjYzM1OTljMzMyNjZkOGIuLjMwN2Nm MDMxMjNmNTQwNjEyYTZlM2Y4NzQ5NjhjZjBmOWQzZTYyYmQgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9X ZWJLaXQyL1VJUHJvY2Vzcy9BUEkvY3BwL2VmbC9XS0VpbmFTaGFyZWRTdHJpbmcuaAorKysgYi9T b3VyY2UvV2ViS2l0Mi9VSVByb2Nlc3MvQVBJL2NwcC9lZmwvV0tFaW5hU2hhcmVkU3RyaW5nLmgK QEAgLTYxLDEyICs2MSwyMCBAQCBwdWJsaWM6CiAKICAgICBBTFdBWVNfSU5MSU5FIHNpemVfdCBs ZW5ndGgoKSBjb25zdCB7IHJldHVybiBtX3N0cmluZyA/IHN0YXRpY19jYXN0PHNpemVfdD4oZWlu YV9zdHJpbmdzaGFyZV9zdHJsZW4obV9zdHJpbmcpKSA6IDA7IH0KIAorICAgIGZyaWVuZCBXS0Vp bmFTaGFyZWRTdHJpbmcgYWRvcHRFaW5hU3RyaW5nU2hhcmUoY29uc3QgY2hhciogc3RyaW5nKTsK KwogcHJpdmF0ZToKKyAgICAvLyBhZG9wdGluZyBjb25zdHJ1Y3RvcgorICAgIFdLRWluYVNoYXJl ZFN0cmluZyhjb25zdCBjaGFyKiBzdHJpbmcsIGJvb2wpIDogbV9zdHJpbmcoc3RyaW5nKSB7IH0K KwogICAgIGNvbnN0IGNoYXIqIG1fc3RyaW5nOwogfTsKIAorV0tfRVhQT1JUIFdLRWluYVNoYXJl ZFN0cmluZyBhZG9wdEVpbmFTdHJpbmdTaGFyZShjb25zdCBjaGFyKiBzdHJpbmcpOworCiB9IC8v IG5hbWVzcGFjZSBXZWJLaXQKIAogdXNpbmcgV2ViS2l0OjpXS0VpbmFTaGFyZWRTdHJpbmc7Cit1 c2luZyBXZWJLaXQ6OmFkb3B0RWluYVN0cmluZ1NoYXJlOwogCiAjZW5kaWYgLy8gV0tFaW5hU2hh cmVkU3RyaW5nX2gKZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJLaXQyL1VJUHJvY2Vzcy9BUEkvZWZs L3Rlc3RzL3Rlc3RfZXdrMl9laW5hX3NoYXJlZF9zdHJpbmcuY3BwIGIvU291cmNlL1dlYktpdDIv VUlQcm9jZXNzL0FQSS9lZmwvdGVzdHMvdGVzdF9ld2syX2VpbmFfc2hhcmVkX3N0cmluZy5jcHAK aW5kZXggN2Y2MmUwYjFlM2ZiNTBmYWQ4NzZmNWU4M2ZjMzBkZjVjZjY5ZmZiYy4uMzk1NDAzODQw OGNlMTQyZWJhYTg0ODkxN2M1MzljM2FjM2Q1MjI0MyAxMDA2NDQKLS0tIGEvU291cmNlL1dlYktp dDIvVUlQcm9jZXNzL0FQSS9lZmwvdGVzdHMvdGVzdF9ld2syX2VpbmFfc2hhcmVkX3N0cmluZy5j cHAKKysrIGIvU291cmNlL1dlYktpdDIvVUlQcm9jZXNzL0FQSS9lZmwvdGVzdHMvdGVzdF9ld2sy X2VpbmFfc2hhcmVkX3N0cmluZy5jcHAKQEAgLTc1LDYgKzc1LDE4IEBAIFRFU1RfRihFV0syVW5p dFRlc3RCYXNlLCBjb25zdHJ1Y3RGcm9tV0tVUkwpCiAgICAgY2hlY2tTdHJpbmcoc3RyaW5nLCB0 ZXN0VXJsKTsKIH0KIAorVEVTVF9GKEVXSzJVbml0VGVzdEJhc2UsIGNvbnN0cnVjdEZyb21FaW5h U3RyaW5nU2hhcmUpCit7CisgICAgV0tFaW5hU2hhcmVkU3RyaW5nIHN0cmluZyhhZG9wdEVpbmFT dHJpbmdTaGFyZShlaW5hX3N0cmluZ3NoYXJlX2FkZCh0ZXN0U3RyaW5nKSkpOworICAgIGNoZWNr U3RyaW5nKHN0cmluZywgdGVzdFN0cmluZyk7CisKKyAgICBzdHJpbmcgPSBhZG9wdEVpbmFTdHJp bmdTaGFyZShlaW5hX3N0cmluZ3NoYXJlX2FkZChhbm90aGVyVGVzdFN0cmluZykpOworICAgIGNo ZWNrU3RyaW5nKHN0cmluZywgYW5vdGhlclRlc3RTdHJpbmcpOworCisgICAgc3RyaW5nID0gc3Ry aW5nOworICAgIGNoZWNrU3RyaW5nKHN0cmluZywgYW5vdGhlclRlc3RTdHJpbmcpOworfQorCiBU RVNUX0YoRVdLMlVuaXRUZXN0QmFzZSwgY29zdHJ1Y3RDb3B5KQogewogICAgIFdLRWluYVNoYXJl ZFN0cmluZyBzdHJpbmcodGVzdFN0cmluZyk7Cg== 163110 2012-09-10 06:17:15 -0700 2012-09-11 02:36:14 -0700 Patch bug-96201-20120910221649.patch text/plain 3514 bw80.lee U3VidmVyc2lvbiBSZXZpc2lvbjogMTI4MDA3CmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViS2l0Mi9D aGFuZ2VMb2cgYi9Tb3VyY2UvV2ViS2l0Mi9DaGFuZ2VMb2cKaW5kZXggNGMxNDhmZjEzM2MzZWZl MThkZDdjZDA4ZGE2ZTE3M2MzNzc1NTYyNi4uNjI3NDhhNTA4NmJmMDk2YjkwMzlkZWE2MzdjYTBi OWMyZWRjMzJmNiAxMDA2NDQKLS0tIGEvU291cmNlL1dlYktpdDIvQ2hhbmdlTG9nCisrKyBiL1Nv dXJjZS9XZWJLaXQyL0NoYW5nZUxvZwpAQCAtMSwzICsxLDIyIEBACisyMDEyLTA5LTEwICBCeXVu Z3dvbyBMZWUgIDxidzgwLmxlZUBzYW1zdW5nLmNvbT4KKworICAgICAgICBbRUZMXVtXSzJdIFdL RWluYVNoYXJlZFN0cmluZyBuZWVkcyBhIGZ1bmN0aW9uIHRvIGFkb3B0IGVpbmEgc3RyaW5nc2hh cmUuCisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD05NjIw MQorCisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAgIFdLRWlu YVNoYXJlZFN0cmluZyBuZWVkcyBhIHRvIGFkb3B0IGVpbmEgc3RyaW5nc2hhcmUgZGlyZWN0bHku CisKKyAgICAgICAgV2l0aCB0aGlzIGFkb3B0IGZ1bmN0aW9uLCBhbiBpbnN0YW5jZSB0aGF0IGlz IGRpcmVjdGx5IGNyZWF0ZWQgd2l0aAorICAgICAgICBlaW5hX3N0cmluZ3NoYXJlX2FkZCgpIGNh biBiZSBlYXNpbHkgaGFuZGxlZCBieSBXS0VpbmFTaGFyZWRTdHJpbmcKKyAgICAgICAgd2l0aG91 dCBjYWxsaW5nIGVpbmFfc3RyaW5nc2hhcmVfZGVsKCkgZm9yIHByZXZlbnRpbmcgbWVtb3J5IGxl YWsuCisKKyAgICAgICAgKiBVSVByb2Nlc3MvQVBJL2NwcC9lZmwvV0tFaW5hU2hhcmVkU3RyaW5n LmNwcDoKKyAgICAgICAgKFdLRWluYVNoYXJlZFN0cmluZzo6YWRvcHQpOgorICAgICAgICAqIFVJ UHJvY2Vzcy9BUEkvY3BwL2VmbC9XS0VpbmFTaGFyZWRTdHJpbmcuaDoKKyAgICAgICAgKiBVSVBy b2Nlc3MvQVBJL2VmbC90ZXN0cy90ZXN0X2V3azJfZWluYV9zaGFyZWRfc3RyaW5nLmNwcDoKKyAg ICAgICAgKFRFU1RfRik6CisKIDIwMTItMDktMDkgIEVtaWwgQSBFa2x1bmQgIDxlYWVAY2hyb21p dW0ub3JnPgogCiAgICAgICAgIFJlbmFtZSBOb2RlOjpnZXRSZWN0L2dldFBpeGVsU25hcHBlZFJl Y3QgYW5kIHJlbW92ZSBDb250YWluZXJOb2RlOjpnZXRSZWN0CmRpZmYgLS1naXQgYS9Tb3VyY2Uv V2ViS2l0Mi9VSVByb2Nlc3MvQVBJL2NwcC9lZmwvV0tFaW5hU2hhcmVkU3RyaW5nLmNwcCBiL1Nv dXJjZS9XZWJLaXQyL1VJUHJvY2Vzcy9BUEkvY3BwL2VmbC9XS0VpbmFTaGFyZWRTdHJpbmcuY3Bw CmluZGV4IGVhNDNkZjE2N2FmZDA2ZTMwNmQwYzI3ZjZmY2Y5ZmEzMWUyMTI4YjUuLmQzMWJmZDQw ZTAyOWNjMDQ1MjM2NzQ2Njc1ZTcyMjA0NDlhOGI2OTggMTAwNjQ0Ci0tLSBhL1NvdXJjZS9XZWJL aXQyL1VJUHJvY2Vzcy9BUEkvY3BwL2VmbC9XS0VpbmFTaGFyZWRTdHJpbmcuY3BwCisrKyBiL1Nv dXJjZS9XZWJLaXQyL1VJUHJvY2Vzcy9BUEkvY3BwL2VmbC9XS0VpbmFTaGFyZWRTdHJpbmcuY3Bw CkBAIC0xMDUsMyArMTA1LDEwIEBAIGJvb2wgV0tFaW5hU2hhcmVkU3RyaW5nOjpvcGVyYXRvcj09 KGNvbnN0IGNoYXIqIHN0cikgY29uc3QKIHsKICAgICByZXR1cm4gKCFzdHIgfHwgIW1fc3RyaW5n KSA/IChzdHIgPT0gbV9zdHJpbmcpIDogIXN0cmNtcChtX3N0cmluZywgc3RyKTsKIH0KKworV0tF aW5hU2hhcmVkU3RyaW5nIFdLRWluYVNoYXJlZFN0cmluZzo6YWRvcHQoRWluYV9TdHJpbmdzaGFy ZSogc3RyaW5nKQoreworICAgIFdLRWluYVNoYXJlZFN0cmluZyBzaGFyZWRTdHJpbmc7CisgICAg c2hhcmVkU3RyaW5nLm1fc3RyaW5nID0gc3RhdGljX2Nhc3Q8Y29uc3QgY2hhcio+KHN0cmluZyk7 CisgICAgcmV0dXJuIHNoYXJlZFN0cmluZzsKK30KZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJLaXQy L1VJUHJvY2Vzcy9BUEkvY3BwL2VmbC9XS0VpbmFTaGFyZWRTdHJpbmcuaCBiL1NvdXJjZS9XZWJL aXQyL1VJUHJvY2Vzcy9BUEkvY3BwL2VmbC9XS0VpbmFTaGFyZWRTdHJpbmcuaAppbmRleCA2OGQ3 NmY0ZWFkMWJiY2JkOWU1NDVjZTlkY2MzNTk5YzMzMjY2ZDhiLi41MmNmZmZhMGVjZWUyOGUwYTU4 NjE4ZGVhNjljZWExYTE2OWVmNmVjIDEwMDY0NAotLS0gYS9Tb3VyY2UvV2ViS2l0Mi9VSVByb2Nl c3MvQVBJL2NwcC9lZmwvV0tFaW5hU2hhcmVkU3RyaW5nLmgKKysrIGIvU291cmNlL1dlYktpdDIv VUlQcm9jZXNzL0FQSS9jcHAvZWZsL1dLRWluYVNoYXJlZFN0cmluZy5oCkBAIC02MSw2ICs2MSw4 IEBAIHB1YmxpYzoKIAogICAgIEFMV0FZU19JTkxJTkUgc2l6ZV90IGxlbmd0aCgpIGNvbnN0IHsg cmV0dXJuIG1fc3RyaW5nID8gc3RhdGljX2Nhc3Q8c2l6ZV90PihlaW5hX3N0cmluZ3NoYXJlX3N0 cmxlbihtX3N0cmluZykpIDogMDsgfQogCisgICAgc3RhdGljIFdLRWluYVNoYXJlZFN0cmluZyBh ZG9wdChFaW5hX1N0cmluZ3NoYXJlKik7CisKIHByaXZhdGU6CiAgICAgY29uc3QgY2hhciogbV9z dHJpbmc7CiB9OwpkaWZmIC0tZ2l0IGEvU291cmNlL1dlYktpdDIvVUlQcm9jZXNzL0FQSS9lZmwv dGVzdHMvdGVzdF9ld2syX2VpbmFfc2hhcmVkX3N0cmluZy5jcHAgYi9Tb3VyY2UvV2ViS2l0Mi9V SVByb2Nlc3MvQVBJL2VmbC90ZXN0cy90ZXN0X2V3azJfZWluYV9zaGFyZWRfc3RyaW5nLmNwcApp bmRleCA3ZjYyZTBiMWUzZmI1MGZhZDg3NmY1ZTgzZmMzMGRmNWNmNjlmZmJjLi5jODIwMjM5YTUx YTI0OGU3NzM0NjY0MjY1MWRlMjgyZTc4YWM2NGU1IDEwMDY0NAotLS0gYS9Tb3VyY2UvV2ViS2l0 Mi9VSVByb2Nlc3MvQVBJL2VmbC90ZXN0cy90ZXN0X2V3azJfZWluYV9zaGFyZWRfc3RyaW5nLmNw cAorKysgYi9Tb3VyY2UvV2ViS2l0Mi9VSVByb2Nlc3MvQVBJL2VmbC90ZXN0cy90ZXN0X2V3azJf ZWluYV9zaGFyZWRfc3RyaW5nLmNwcApAQCAtNzUsNiArNzUsMTggQEAgVEVTVF9GKEVXSzJVbml0 VGVzdEJhc2UsIGNvbnN0cnVjdEZyb21XS1VSTCkKICAgICBjaGVja1N0cmluZyhzdHJpbmcsIHRl c3RVcmwpOwogfQogCitURVNUX0YoRVdLMlVuaXRUZXN0QmFzZSwgY29uc3RydWN0RnJvbUVpbmFT dHJpbmdTaGFyZSkKK3sKKyAgICBXS0VpbmFTaGFyZWRTdHJpbmcgc3RyaW5nKFdLRWluYVNoYXJl ZFN0cmluZzo6YWRvcHQoZWluYV9zdHJpbmdzaGFyZV9hZGQodGVzdFN0cmluZykpKTsKKyAgICBj aGVja1N0cmluZyhzdHJpbmcsIHRlc3RTdHJpbmcpOworCisgICAgc3RyaW5nID0gV0tFaW5hU2hh cmVkU3RyaW5nOjphZG9wdChlaW5hX3N0cmluZ3NoYXJlX2FkZChhbm90aGVyVGVzdFN0cmluZykp OworICAgIGNoZWNrU3RyaW5nKHN0cmluZywgYW5vdGhlclRlc3RTdHJpbmcpOworCisgICAgc3Ry aW5nID0gc3RyaW5nOworICAgIGNoZWNrU3RyaW5nKHN0cmluZywgYW5vdGhlclRlc3RTdHJpbmcp OworfQorCiBURVNUX0YoRVdLMlVuaXRUZXN0QmFzZSwgY29zdHJ1Y3RDb3B5KQogewogICAgIFdL RWluYVNoYXJlZFN0cmluZyBzdHJpbmcodGVzdFN0cmluZyk7Cg== 163299 2012-09-11 01:29:05 -0700 2012-09-11 02:29:29 -0700 Patch bug-96201-20120911172838.patch text/plain 3582 bw80.lee U3VidmVyc2lvbiBSZXZpc2lvbjogMTI4MDA3CmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViS2l0Mi9D aGFuZ2VMb2cgYi9Tb3VyY2UvV2ViS2l0Mi9DaGFuZ2VMb2cKaW5kZXggNGMxNDhmZjEzM2MzZWZl MThkZDdjZDA4ZGE2ZTE3M2MzNzc1NTYyNi4uZTQwNmY4ZWE4NTAwNWVjNDdmOWFlMmVmYzk5NmNl MzE2ZGVmNWFiZSAxMDA2NDQKLS0tIGEvU291cmNlL1dlYktpdDIvQ2hhbmdlTG9nCisrKyBiL1Nv dXJjZS9XZWJLaXQyL0NoYW5nZUxvZwpAQCAtMSwzICsxLDIyIEBACisyMDEyLTA5LTEwICBCeXVu Z3dvbyBMZWUgIDxidzgwLmxlZUBzYW1zdW5nLmNvbT4KKworICAgICAgICBbRUZMXVtXSzJdIFdL RWluYVNoYXJlZFN0cmluZyBuZWVkcyBhIGZ1bmN0aW9uIHRvIGFkb3B0IGVpbmEgc3RyaW5nc2hh cmUuCisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD05NjIw MQorCisgICAgICAgIFJldmlld2VkIGJ5IEtlbm5ldGggUm9oZGUgQ2hyaXN0aWFuc2VuLgorCisg ICAgICAgIFdLRWluYVNoYXJlZFN0cmluZyBuZWVkcyBhIHRvIGFkb3B0IGVpbmEgc3RyaW5nc2hh cmUgZGlyZWN0bHkuCisKKyAgICAgICAgV2l0aCB0aGlzIGFkb3B0IGZ1bmN0aW9uLCBhbiBpbnN0 YW5jZSB0aGF0IGlzIGRpcmVjdGx5IGNyZWF0ZWQgd2l0aAorICAgICAgICBlaW5hX3N0cmluZ3No YXJlX2FkZCgpIGNhbiBiZSBlYXNpbHkgaGFuZGxlZCBieSBXS0VpbmFTaGFyZWRTdHJpbmcKKyAg ICAgICAgd2l0aG91dCBjYWxsaW5nIGVpbmFfc3RyaW5nc2hhcmVfZGVsKCkgZm9yIHByZXZlbnRp bmcgbWVtb3J5IGxlYWsuCisKKyAgICAgICAgKiBVSVByb2Nlc3MvQVBJL2NwcC9lZmwvV0tFaW5h U2hhcmVkU3RyaW5nLmNwcDoKKyAgICAgICAgKFdLRWluYVNoYXJlZFN0cmluZzo6YWRvcHQpOgor ICAgICAgICAqIFVJUHJvY2Vzcy9BUEkvY3BwL2VmbC9XS0VpbmFTaGFyZWRTdHJpbmcuaDoKKyAg ICAgICAgKiBVSVByb2Nlc3MvQVBJL2VmbC90ZXN0cy90ZXN0X2V3azJfZWluYV9zaGFyZWRfc3Ry aW5nLmNwcDoKKyAgICAgICAgKFRFU1RfRik6CisKIDIwMTItMDktMDkgIEVtaWwgQSBFa2x1bmQg IDxlYWVAY2hyb21pdW0ub3JnPgogCiAgICAgICAgIFJlbmFtZSBOb2RlOjpnZXRSZWN0L2dldFBp eGVsU25hcHBlZFJlY3QgYW5kIHJlbW92ZSBDb250YWluZXJOb2RlOjpnZXRSZWN0CmRpZmYgLS1n aXQgYS9Tb3VyY2UvV2ViS2l0Mi9VSVByb2Nlc3MvQVBJL2NwcC9lZmwvV0tFaW5hU2hhcmVkU3Ry aW5nLmNwcCBiL1NvdXJjZS9XZWJLaXQyL1VJUHJvY2Vzcy9BUEkvY3BwL2VmbC9XS0VpbmFTaGFy ZWRTdHJpbmcuY3BwCmluZGV4IGVhNDNkZjE2N2FmZDA2ZTMwNmQwYzI3ZjZmY2Y5ZmEzMWUyMTI4 YjUuLmUwM2ZhZjZjNTRjYmQ4NTY3NjQ2MjhhMTUwNjI1N2NmOTYzMWRkN2QgMTAwNjQ0Ci0tLSBh L1NvdXJjZS9XZWJLaXQyL1VJUHJvY2Vzcy9BUEkvY3BwL2VmbC9XS0VpbmFTaGFyZWRTdHJpbmcu Y3BwCisrKyBiL1NvdXJjZS9XZWJLaXQyL1VJUHJvY2Vzcy9BUEkvY3BwL2VmbC9XS0VpbmFTaGFy ZWRTdHJpbmcuY3BwCkBAIC0xMDUsMyArMTA1LDggQEAgYm9vbCBXS0VpbmFTaGFyZWRTdHJpbmc6 Om9wZXJhdG9yPT0oY29uc3QgY2hhciogc3RyKSBjb25zdAogewogICAgIHJldHVybiAoIXN0ciB8 fCAhbV9zdHJpbmcpID8gKHN0ciA9PSBtX3N0cmluZykgOiAhc3RyY21wKG1fc3RyaW5nLCBzdHIp OwogfQorCitXS0VpbmFTaGFyZWRTdHJpbmcgV0tFaW5hU2hhcmVkU3RyaW5nOjphZG9wdChFaW5h X1N0cmluZ3NoYXJlKiBzdHJpbmcpCit7CisgICAgcmV0dXJuIFdLRWluYVNoYXJlZFN0cmluZyhz dHJpbmcsIHRydWUpOworfQpkaWZmIC0tZ2l0IGEvU291cmNlL1dlYktpdDIvVUlQcm9jZXNzL0FQ SS9jcHAvZWZsL1dLRWluYVNoYXJlZFN0cmluZy5oIGIvU291cmNlL1dlYktpdDIvVUlQcm9jZXNz L0FQSS9jcHAvZWZsL1dLRWluYVNoYXJlZFN0cmluZy5oCmluZGV4IDY4ZDc2ZjRlYWQxYmJjYmQ5 ZTU0NWNlOWRjYzM1OTljMzMyNjZkOGIuLjdlNzQ3Y2I4ODQ1NTQxNGRiMDAxZGZhYzM2ZWE5M2M3 MTE2ZTk5MTIgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9XZWJLaXQyL1VJUHJvY2Vzcy9BUEkvY3BwL2Vm bC9XS0VpbmFTaGFyZWRTdHJpbmcuaAorKysgYi9Tb3VyY2UvV2ViS2l0Mi9VSVByb2Nlc3MvQVBJ L2NwcC9lZmwvV0tFaW5hU2hhcmVkU3RyaW5nLmgKQEAgLTYxLDcgKzYxLDEyIEBAIHB1YmxpYzoK IAogICAgIEFMV0FZU19JTkxJTkUgc2l6ZV90IGxlbmd0aCgpIGNvbnN0IHsgcmV0dXJuIG1fc3Ry aW5nID8gc3RhdGljX2Nhc3Q8c2l6ZV90PihlaW5hX3N0cmluZ3NoYXJlX3N0cmxlbihtX3N0cmlu ZykpIDogMDsgfQogCisgICAgc3RhdGljIFdLRWluYVNoYXJlZFN0cmluZyBhZG9wdChFaW5hX1N0 cmluZ3NoYXJlKik7CisKIHByaXZhdGU6CisgICAgLy8gQW9wdGluZyBjb25zdHJ1Y3RvcgorICAg IFdLRWluYVNoYXJlZFN0cmluZyhFaW5hX1N0cmluZ3NoYXJlKiBzdHJpbmcsIGJvb2wpIDogbV9z dHJpbmcoc3RhdGljX2Nhc3Q8Y29uc3QgY2hhcio+KHN0cmluZykpIHsgfQorCiAgICAgY29uc3Qg Y2hhciogbV9zdHJpbmc7CiB9OwogCmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViS2l0Mi9VSVByb2Nl c3MvQVBJL2VmbC90ZXN0cy90ZXN0X2V3azJfZWluYV9zaGFyZWRfc3RyaW5nLmNwcCBiL1NvdXJj ZS9XZWJLaXQyL1VJUHJvY2Vzcy9BUEkvZWZsL3Rlc3RzL3Rlc3RfZXdrMl9laW5hX3NoYXJlZF9z dHJpbmcuY3BwCmluZGV4IDdmNjJlMGIxZTNmYjUwZmFkODc2ZjVlODNmYzMwZGY1Y2Y2OWZmYmMu LmM4MjAyMzlhNTFhMjQ4ZTc3MzQ2NjQyNjUxZGUyODJlNzhhYzY0ZTUgMTAwNjQ0Ci0tLSBhL1Nv dXJjZS9XZWJLaXQyL1VJUHJvY2Vzcy9BUEkvZWZsL3Rlc3RzL3Rlc3RfZXdrMl9laW5hX3NoYXJl ZF9zdHJpbmcuY3BwCisrKyBiL1NvdXJjZS9XZWJLaXQyL1VJUHJvY2Vzcy9BUEkvZWZsL3Rlc3Rz L3Rlc3RfZXdrMl9laW5hX3NoYXJlZF9zdHJpbmcuY3BwCkBAIC03NSw2ICs3NSwxOCBAQCBURVNU X0YoRVdLMlVuaXRUZXN0QmFzZSwgY29uc3RydWN0RnJvbVdLVVJMKQogICAgIGNoZWNrU3RyaW5n KHN0cmluZywgdGVzdFVybCk7CiB9CiAKK1RFU1RfRihFV0syVW5pdFRlc3RCYXNlLCBjb25zdHJ1 Y3RGcm9tRWluYVN0cmluZ1NoYXJlKQoreworICAgIFdLRWluYVNoYXJlZFN0cmluZyBzdHJpbmco V0tFaW5hU2hhcmVkU3RyaW5nOjphZG9wdChlaW5hX3N0cmluZ3NoYXJlX2FkZCh0ZXN0U3RyaW5n KSkpOworICAgIGNoZWNrU3RyaW5nKHN0cmluZywgdGVzdFN0cmluZyk7CisKKyAgICBzdHJpbmcg PSBXS0VpbmFTaGFyZWRTdHJpbmc6OmFkb3B0KGVpbmFfc3RyaW5nc2hhcmVfYWRkKGFub3RoZXJU ZXN0U3RyaW5nKSk7CisgICAgY2hlY2tTdHJpbmcoc3RyaW5nLCBhbm90aGVyVGVzdFN0cmluZyk7 CisKKyAgICBzdHJpbmcgPSBzdHJpbmc7CisgICAgY2hlY2tTdHJpbmcoc3RyaW5nLCBhbm90aGVy VGVzdFN0cmluZyk7Cit9CisKIFRFU1RfRihFV0syVW5pdFRlc3RCYXNlLCBjb3N0cnVjdENvcHkp CiB7CiAgICAgV0tFaW5hU2hhcmVkU3RyaW5nIHN0cmluZyh0ZXN0U3RyaW5nKTsK