97528 2012-09-24 23:20:10 -0700 [EFL][WK2] Clear provider on destructor of {Vibration,Battery,NetworkInfo}Provider. 2012-09-28 03:08:19 -0700 1 1 1 Unclassified WebKit WebKit EFL 528+ (Nightly build) Unspecified Unspecified RESOLVED FIXED P2 Normal --- 97839 1 bw80.lee bw80.lee cdumez gyuyoung.kim kenneth kihong.kwon laszlo.gombos lucas.de.marchi rakuco webkit.review.bot oldest_to_newest 727317 0 bw80.lee 2012-09-24 23:20:10 -0700 Sometimes there is a crash on ewk_context_new and the callstack is as below. #0 0xb7146fb8 in VibrationProvider::cancelVibration (this=0xadb058b0) at Source/WebKit2/UIProcess/API/efl/VibrationProvider.cpp:99 #1 0xb7146d14 in cancelVibrationCallback (clientInfo=0xadb058b0) at Source/WebKit2/UIProcess/API/efl/VibrationProvider.cpp:65 #2 0xb70784e8 in WebKit::WebVibrationProvider::cancelVibration (this=0xadb128f4, vibration=0xadb128e8) at Source/WebKit2/UIProcess/WebVibrationProvider.cpp:49 #3 0xb707873f in WebKit::WebVibrationProxy::cancelVibration (this=0xadb128e8) at Source/WebKit2/UIProcess/WebVibrationProxy.cpp:71 #4 0xb7078663 in WebKit::WebVibrationProxy::invalidate (this=0xadb128e8) at Source/WebKit2/UIProcess/WebVibrationProxy.cpp:51 #5 0xb6ff550c in WebKit::WebContext::~WebContext (this=0xadb122b0, __in_chrg=<optimized out>) at Source/WebKit2/UIProcess/WebContext.cpp:226 #6 0xb6ff5799 in WebKit::WebContext::~WebContext (this=0xadb122b0, __in_chrg=<optimized out>) at Source/WebKit2/UIProcess/WebContext.cpp:237 #7 0xb6f994eb in WTF::ThreadSafeRefCounted<WebKit::APIObject>::deref (this=0xadb122b4) at Source/WTF/wtf/ThreadSafeRefCounted.h:137 #8 0xb6fdac48 in WKRelease (typeRef=0xadb122b0) at Source/WebKit2/Shared/API/c/WKType.cpp:47 #9 0xb714bc81 in WebKit::WKRetainPtr<OpaqueWKContext const*>::~WKRetainPtr (this=0xadb1292c, __in_chrg=<optimized out>) at Source/WebKit2/UIProcess/API/cpp/WKRetainPtr.h:86 #10 0xb714bb9f in _Ewk_Context::~_Ewk_Context (this=0xadb12928, __in_chrg=<optimized out>) at Source/WebKit2/UIProcess/API/efl/ewk_context.cpp:109 #11 0xb714ac66 in ewk_context_unref (ewkContext=0xadb12928) at Source/WebKit2/UIProcess/API/efl/ewk_context.cpp:136 #12 0x08054627 in EWK2UnitTestBase_ewk_context_new_Test::TestBody (this=0xadb00860) at Source/WebKit2/UIProcess/API/efl/tests/test_ewk2_context.cpp:159 #13 0xb69dc828 in testing::Test::Run (this=0xadb00860) at Source/ThirdParty/gtest/src/gtest.cc:2095 #14 0xb69dce83 in testing::internal::TestInfoImpl::Run (this=0x8063010) at Source/ThirdParty/gtest/src/gtest.cc:2314 #15 0xb69dd3e5 in testing::TestCase::Run (this=0x8062c80) at Source/ThirdParty/gtest/src/gtest.cc:2420 #16 0xb69e1b38 in testing::internal::UnitTestImpl::RunAllTests (this=0x8062a48) at Source/ThirdParty/gtest/src/gtest.cc:4024 #17 0xb69e0a34 in testing::UnitTest::Run (this=0xb6a19b20) at Source/ThirdParty/gtest/src/gtest.cc:3687 #18 0x08059582 in main (argc=1, argv=0xbffff1b4) at Source/WebKit2/UIProcess/API/efl/tests/UnitTestUtils/EWK2UnitTestMain.cpp:52 Before this callstack ~VibrationProvider() is called but provider for vibration is not cleared in the function. So the dangling pointer for the VibrationProvider is accessed at the #2 frame. 727331 1 165531 bw80.lee 2012-09-24 23:37:26 -0700 Created attachment 165531 Patch 729287 2 165947 bw80.lee 2012-09-27 00:43:13 -0700 Created attachment 165947 Patch 729289 3 165947 cdumez 2012-09-27 00:45:08 -0700 Comment on attachment 165947 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=165947&action=review > Source/WebKit2/UIProcess/API/efl/ewk_context.cpp:119 > + batteryProvider.clear(); I don't believe this is needed. > Source/WebKit2/UIProcess/API/efl/ewk_context.cpp:123 > + vibrationProvider.clear(); Ditto. 729322 4 bw80.lee 2012-09-27 01:50:44 -0700 (In reply to comment #3) > (From update of attachment 165947 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=165947&action=review > > Source/WebKit2/UIProcess/API/efl/ewk_context.cpp:119 > > + batteryProvider.clear(); > I don't believe this is needed. > > Source/WebKit2/UIProcess/API/efl/ewk_context.cpp:123 > > + vibrationProvider.clear(); > Ditto. 'context' has WebVibrationProxy and the pointer is saved in the VibrationProvider. How about the 'context' is deleted before the 'vibration'? Then the destructor will access dangling pointer. I also think this explicit clear() looks nice. So I'm checking some other way to arrange deletion order. (e.g. instead of having context as member variable, Ewk_Context inherits it.) How about your opinion? 729323 5 bw80.lee 2012-09-27 01:51:42 -0700 (In reply to comment #4) > (In reply to comment #3) > > (From update of attachment 165947 [details] [details]) > > View in context: https://bugs.webkit.org/attachment.cgi?id=165947&action=review > > > Source/WebKit2/UIProcess/API/efl/ewk_context.cpp:119 > > > + batteryProvider.clear(); > > I don't believe this is needed. > > > Source/WebKit2/UIProcess/API/efl/ewk_context.cpp:123 > > > + vibrationProvider.clear(); > > Ditto. > 'context' has WebVibrationProxy and the pointer is saved in the VibrationProvider. > How about the 'context' is deleted before the 'vibration'? > Then the destructor will access dangling pointer. *destructor of VibrationProvider* > I also think this explicit clear() looks nice. > So I'm checking some other way to arrange deletion order. > (e.g. instead of having context as member variable, Ewk_Context inherits it.) > How about your opinion? 729350 6 165947 cdumez 2012-09-27 02:34:48 -0700 Comment on attachment 165947 Patch View in context: https://bugs.webkit.org/attachment.cgi?id=165947&action=review >>>> Source/WebKit2/UIProcess/API/efl/ewk_context.cpp:119 >>>> + batteryProvider.clear(); >>> >>> I don't believe this is needed. >> >> 'context' has WebVibrationProxy and the pointer is saved in the VibrationProvider. >> How about the 'context' is deleted before the 'vibration'? >> Then the destructor will access dangling pointer. >> >> I also think this explicit clear() looks nice. >> >> So I'm checking some other way to arrange deletion order. >> (e.g. instead of having context as member variable, Ewk_Context inherits it.) >> >> How about your opinion? > > *destructor of VibrationProvider* I don't think explicitly calling clear() here is nice. It should not be required either. If it is required, then we need to fix this in some more reliable way. I still don't understand what the problem is: 1. 'context' has WebVibrationProxy member, yes, it keeps a reference to it. 2. The pointer is saved in VibrationProvider. You mean WKVibrationRef ? I don't see the problem with WKVibrationRef since it is stored in a WKRetainPtr<> inside VibrationProvider. It is ref counted so the WKVibrationRef should still be valid in VibrationProvider, no matter what. 729366 7 bw80.lee 2012-09-27 03:02:53 -0700 (In reply to comment #6) > (From update of attachment 165947 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=165947&action=review > > >>>> Source/WebKit2/UIProcess/API/efl/ewk_context.cpp:119 > >>>> + batteryProvider.clear(); > >>> > >>> I don't believe this is needed. > >> > >> 'context' has WebVibrationProxy and the pointer is saved in the VibrationProvider. > >> How about the 'context' is deleted before the 'vibration'? > >> Then the destructor will access dangling pointer. > >> > >> I also think this explicit clear() looks nice. > >> > >> So I'm checking some other way to arrange deletion order. > >> (e.g. instead of having context as member variable, Ewk_Context inherits it.) > >> > >> How about your opinion? > > > > *destructor of VibrationProvider* > > I don't think explicitly calling clear() here is nice. It should not be required either. If it is required, then we need to fix this in some more reliable way. Yes above is typo. I missed 'not' :) > > I still don't understand what the problem is: > 1. 'context' has WebVibrationProxy member, yes, it keeps a reference to it. > 2. The pointer is saved in VibrationProvider. You mean WKVibrationRef ? > > I don't see the problem with WKVibrationRef since it is stored in a WKRetainPtr<> inside VibrationProvider. It is ref counted so the WKVibrationRef should still be valid in VibrationProvider, no matter what. Yes as you said, WebVibrationProvider (== WebVibrationProxy) will not be deleted at that time. But originally, WebVibrationProxy is a member of the WebContext and at that time, WebVibrationProxy will be alive without WebContext. (And WebVibrationProxy has a raw pointer of WebContext. This can be a dangling) I searched about delete order of class member. I'm not sure but 'delete the last member first' might be the rule. (Is there anyone who knows about this?) If so, the above code can be deleted as you recommended. 729394 8 cdumez 2012-09-27 03:53:56 -0700 (In reply to comment #7) > (In reply to comment #6) > > (From update of attachment 165947 [details] [details]) > > View in context: https://bugs.webkit.org/attachment.cgi?id=165947&action=review > > > > >>>> Source/WebKit2/UIProcess/API/efl/ewk_context.cpp:119 > > >>>> + batteryProvider.clear(); > > >>> > > >>> I don't believe this is needed. > > >> > > >> 'context' has WebVibrationProxy and the pointer is saved in the VibrationProvider. > > >> How about the 'context' is deleted before the 'vibration'? > > >> Then the destructor will access dangling pointer. > > >> > > >> I also think this explicit clear() looks nice. > > >> > > >> So I'm checking some other way to arrange deletion order. > > >> (e.g. instead of having context as member variable, Ewk_Context inherits it.) > > >> > > >> How about your opinion? > > > > > > *destructor of VibrationProvider* > > > > I don't think explicitly calling clear() here is nice. It should not be required either. If it is required, then we need to fix this in some more reliable way. > Yes above is typo. I missed 'not' :) > > > > > I still don't understand what the problem is: > > 1. 'context' has WebVibrationProxy member, yes, it keeps a reference to it. > > 2. The pointer is saved in VibrationProvider. You mean WKVibrationRef ? > > > > I don't see the problem with WKVibrationRef since it is stored in a WKRetainPtr<> inside VibrationProvider. It is ref counted so the WKVibrationRef should still be valid in VibrationProvider, no matter what. > > Yes as you said, WebVibrationProvider (== WebVibrationProxy) will not be deleted at that time. > But originally, WebVibrationProxy is a member of the WebContext and at that time, WebVibrationProxy will be alive without WebContext. > (And WebVibrationProxy has a raw pointer of WebContext. This can be a dangling) > > I searched about delete order of class member. > I'm not sure but 'delete the last member first' might be the rule. > (Is there anyone who knows about this?) > > If so, the above code can be deleted as you recommended. WebVibrationProxy is a member of WebContext so it is not a problem if WebVibrationProxy contains a raw pointer to WebContext. All the proxies keep a raw pointer to WebContext. 729442 9 bw80.lee 2012-09-27 05:35:32 -0700 > WebVibrationProxy is a member of WebContext so it is not a problem if WebVibrationProxy contains a raw pointer to WebContext. All the proxies keep a raw pointer to WebContext. Yes, I'm not focusing about the raw pointer itself. If WebContext can be deleted before the VibrationProvider, WebVibrationProxy will be still alive without the WebContext. then the instance can has a dangling pointer for the WebContext because it has a raw pointer. I think that the issue is the 'deleting order' of WebContext and VibrationProvider. (And it seems that WebContext will be deleted after VibrationProvider) Do you have a clear point about the deleting order? 729460 10 cdumez 2012-09-27 06:09:04 -0700 (In reply to comment #9) > > WebVibrationProxy is a member of WebContext so it is not a problem if WebVibrationProxy contains a raw pointer to WebContext. All the proxies keep a raw pointer to WebContext. > > Yes, I'm not focusing about the raw pointer itself. > > If WebContext can be deleted before the VibrationProvider, WebVibrationProxy will be still alive without the WebContext. then the instance can has a dangling pointer for the WebContext because it has a raw pointer. VibrationProvider has no link with WebContext, so it does not matter the order in which they are deleted. WebContext owns WebVibrationProxy. WebVibration owns WebVibrationProvider. WebVibrationProvider merely calls callback functions from WKBatteryProvider. It looks like you are confusing WebVibrationProvider and VibrationProvider. 729463 11 cdumez 2012-09-27 06:12:02 -0700 (In reply to comment #10) > (In reply to comment #9) > > > WebVibrationProxy is a member of WebContext so it is not a problem if WebVibrationProxy contains a raw pointer to WebContext. All the proxies keep a raw pointer to WebContext. > > > > Yes, I'm not focusing about the raw pointer itself. > > > > If WebContext can be deleted before the VibrationProvider, WebVibrationProxy will be still alive without the WebContext. then the instance can has a dangling pointer for the WebContext because it has a raw pointer. [Sorry I repeat because I made a typo in one name and it is important to be clear here] VibrationProvider has no link with WebContext, so it does not matter the order in which they are deleted. WebContext owns WebVibrationProxy. WebVibrationProxy owns WebVibrationProvider. WebVibrationProvider merely calls callback functions from WKBatteryProvider. It looks like you are confusing WebVibrationProvider and VibrationProvider. 729489 12 cdumez 2012-09-27 06:45:38 -0700 I believe I have (finally) understood the problem. The issue is with the following member in BatteryManager: WKRetainPtr<WKBatteryManagerRef> m_wkBatteryManager; This means BatteryManager keeps a reference to the WebBatteryManagerProxy and WebContext keeps another reference to WebBatteryManagerProxy. This is indeed wrong. WebContext should own the WebBatteryManagerProxy and it should not be possible that WebBatteryManagerProxy exists after WebContext has been destroyed. A solution for this would be to pass a WKContextRef to the our EFL providers (instead of WKBatteryManagerRef for example). 1. We can have keep a member in BatteryManager such as: WKRetainPtr<WKContextRef> m_context; instead of WKRetainPtr<WKBatteryManagerRef> m_wkBatteryManager; and we can call WKContextGetBatteryManager(contextRef.get()) to get the battery manager when needed. What do you think about this? I think it is simpler than calling WKRetainPtr::clear() explicitly to enforce a given destruction order. It is also less bug prone. 730094 13 bw80.lee 2012-09-27 18:22:31 -0700 (In reply to comment #12) > I believe I have (finally) understood the problem. > > The issue is with the following member in BatteryManager: > WKRetainPtr<WKBatteryManagerRef> m_wkBatteryManager; > > This means BatteryManager keeps a reference to the WebBatteryManagerProxy and WebContext keeps another reference to WebBatteryManagerProxy. > > This is indeed wrong. WebContext should own the WebBatteryManagerProxy and it should not be possible that WebBatteryManagerProxy exists after WebContext has been destroyed. Yes~ Thats what I told about VibrationProvider. Both have same problem. > > A solution for this would be to pass a WKContextRef to the our EFL providers (instead of WKBatteryManagerRef for example). > > 1. We can have keep a member in BatteryManager such as: > WKRetainPtr<WKContextRef> m_context; > instead of > WKRetainPtr<WKBatteryManagerRef> m_wkBatteryManager; > > and we can call WKContextGetBatteryManager(contextRef.get()) to get the battery manager when needed. > > What do you think about this? I think it is simpler than calling WKRetainPtr::clear() explicitly to enforce a given destruction order. It is also less bug prone. Yes I have had a doubt about this unclear relation between VibrationProvider and WebContext. (BatteryManager also) Your suggestion looks nicer than the explicit clear() and removes the unclear point. I'll change it. 730105 14 bw80.lee 2012-09-27 18:51:31 -0700 (In reply to comment #13) > (In reply to comment #12) > > I believe I have (finally) understood the problem. > > > > The issue is with the following member in BatteryManager: > > WKRetainPtr<WKBatteryManagerRef> m_wkBatteryManager; > > > > This means BatteryManager keeps a reference to the WebBatteryManagerProxy and WebContext keeps another reference to WebBatteryManagerProxy. > > > > This is indeed wrong. WebContext should own the WebBatteryManagerProxy and it should not be possible that WebBatteryManagerProxy exists after WebContext has been destroyed. > Yes~ Thats what I told about VibrationProvider. Both have same problem. > > > > > A solution for this would be to pass a WKContextRef to the our EFL providers (instead of WKBatteryManagerRef for example). > > > > 1. We can have keep a member in BatteryManager such as: > > WKRetainPtr<WKContextRef> m_context; > > instead of > > WKRetainPtr<WKBatteryManagerRef> m_wkBatteryManager; > > > > and we can call WKContextGetBatteryManager(contextRef.get()) to get the battery manager when needed. > > > > What do you think about this? I think it is simpler than calling WKRetainPtr::clear() explicitly to enforce a given destruction order. It is also less bug prone. > > Yes I have had a doubt about this unclear relation between VibrationProvider and WebContext. (BatteryManager also) > > Your suggestion looks nicer than the explicit clear() and removes the unclear point. > I'll change it. I'm working on the above on VibrationProvider, BatteryProvider, and NetworkInfoProvider and will upload new patch for it. 730111 15 bw80.lee 2012-09-27 19:07:18 -0700 (In reply to comment #14) > (In reply to comment #13) > > (In reply to comment #12) > > > I believe I have (finally) understood the problem. > > > > > > The issue is with the following member in BatteryManager: > > > WKRetainPtr<WKBatteryManagerRef> m_wkBatteryManager; > > > > > > This means BatteryManager keeps a reference to the WebBatteryManagerProxy and WebContext keeps another reference to WebBatteryManagerProxy. > > > > > > This is indeed wrong. WebContext should own the WebBatteryManagerProxy and it should not be possible that WebBatteryManagerProxy exists after WebContext has been destroyed. > > Yes~ Thats what I told about VibrationProvider. Both have same problem. > > > > > > > > A solution for this would be to pass a WKContextRef to the our EFL providers (instead of WKBatteryManagerRef for example). > > > > > > 1. We can have keep a member in BatteryManager such as: > > > WKRetainPtr<WKContextRef> m_context; > > > instead of > > > WKRetainPtr<WKBatteryManagerRef> m_wkBatteryManager; > > > > > > and we can call WKContextGetBatteryManager(contextRef.get()) to get the battery manager when needed. > > > > > > What do you think about this? I think it is simpler than calling WKRetainPtr::clear() explicitly to enforce a given destruction order. It is also less bug prone. > > > > Yes I have had a doubt about this unclear relation between VibrationProvider and WebContext. (BatteryManager also) > > > > Your suggestion looks nicer than the explicit clear() and removes the unclear point. > > I'll change it. > I'm working on the above on VibrationProvider, BatteryProvider, and NetworkInfoProvider and will upload new patch for it. I think this need to be handled with separated bug, so I made a new bug for the relation problem : bug 97839 I'll discard the second patch and use the initial patch (that only has clear code) 730231 16 165531 cdumez 2012-09-27 21:54:26 -0700 Comment on attachment 165531 Patch LGTM. 730381 17 kenneth 2012-09-28 02:15:17 -0700 Why is the last patch not up for review? Should it be? 730389 18 cdumez 2012-09-28 02:19:00 -0700 (In reply to comment #17) > Why is the last patch not up for review? Should it be? No, the second patch's approach was discussed and we agreed it should be done another way (See Bug 97839). 730405 19 165531 webkit.review.bot 2012-09-28 02:40:09 -0700 Comment on attachment 165531 Patch Clearing flags on attachment: 165531 Committed r129866: <http://trac.webkit.org/changeset/129866> 730406 20 webkit.review.bot 2012-09-28 02:40:14 -0700 All reviewed patches have been landed. Closing bug. 165531 2012-09-24 23:37:26 -0700 2012-09-28 02:40:09 -0700 Patch bug-97528-20120925153640.patch text/plain 3105 bw80.lee U3VidmVyc2lvbiBSZXZpc2lvbjogMTI5MzE5CmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViS2l0Mi9D aGFuZ2VMb2cgYi9Tb3VyY2UvV2ViS2l0Mi9DaGFuZ2VMb2cKaW5kZXggZmI1ZTAwZjg4YmY4Y2Jl ZWE1MzA2YzZkMzQ5YTI2MDMyNjQwMGU0Zi4uOTAyZmQ0M2IyOGJhMjU0MmI0MjVkODU3NjU3MGM0 ZDhmZmU2MmE5OSAxMDA2NDQKLS0tIGEvU291cmNlL1dlYktpdDIvQ2hhbmdlTG9nCisrKyBiL1Nv dXJjZS9XZWJLaXQyL0NoYW5nZUxvZwpAQCAtMSwzICsxLDIzIEBACisyMDEyLTA5LTI0ICBCeXVu Z3dvbyBMZWUgIDxidzgwLmxlZUBzYW1zdW5nLmNvbT4KKworICAgICAgICBbRUZMXVtXSzJdIENs ZWFyIHByb3ZpZGVyIG9uIGRlc3RydWN0b3Igb2Yge1ZpYnJhdGlvbixCYXR0ZXJ5LE5ldHdvcmtJ bmZvfVByb3ZpZGVyLgorICAgICAgICBodHRwczovL2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5j Z2k/aWQ9OTc1MjgKKworICAgICAgICBSZXZpZXdlZCBieSBOT0JPRFkgKE9PUFMhKS4KKworICAg ICAgICBDb25zdHJ1Y3RvciBvZiB7VmlicmF0aW9uLEJhdHRlcnksTmV0d29ya0luZm99UHJvdmlk ZXIgc2V0IHByb3ZpZGVyCisgICAgICAgIGJ1dCB0aGUgZGVzdHJ1Y3RvciBvZiB0aGUgY2xhc3Nl cyBkb2Vzbid0IGNsZWFyIHByb3ZpZGVyLgorICAgICAgICBUaGlzIGNhbiBtYWtlIGEgcHJvYmxl bSBhYm91dCBhY2Nlc3NpbmcgZGFuZ2xpbmcgcG9pbnRlci4KKworICAgICAgICBGb3IgcHJldmVu dGluZyB0aGlzIHByb2JsZW0sIGNsZWFyIHByb3ZpZGVyIG9uIGRlc3RydWN0b3IuCisKKyAgICAg ICAgKiBVSVByb2Nlc3MvQVBJL2VmbC9CYXR0ZXJ5UHJvdmlkZXIuY3BwOgorICAgICAgICAoQmF0 dGVyeVByb3ZpZGVyOjp+QmF0dGVyeVByb3ZpZGVyKToKKyAgICAgICAgKiBVSVByb2Nlc3MvQVBJ L2VmbC9OZXR3b3JrSW5mb1Byb3ZpZGVyLmNwcDoKKyAgICAgICAgKE5ldHdvcmtJbmZvUHJvdmlk ZXI6On5OZXR3b3JrSW5mb1Byb3ZpZGVyKToKKyAgICAgICAgKiBVSVByb2Nlc3MvQVBJL2VmbC9W aWJyYXRpb25Qcm92aWRlci5jcHA6CisgICAgICAgIChWaWJyYXRpb25Qcm92aWRlcjo6flZpYnJh dGlvblByb3ZpZGVyKToKKwogMjAxMi0wOS0yMyAgQnl1bmd3b28gTGVlICA8Ync4MC5sZWVAZ21h aWwuY29tPgogCiAgICAgICAgIEZpeCBidWlsZCB3YXJuaW5ncyA6IC1XdW51c2VkLXBhcmFtZXRl ciwgLVdwYXJlbnRoZXNlcywgLVd1bmluaXRpYWxpemVkLgpkaWZmIC0tZ2l0IGEvU291cmNlL1dl YktpdDIvVUlQcm9jZXNzL0FQSS9lZmwvQmF0dGVyeVByb3ZpZGVyLmNwcCBiL1NvdXJjZS9XZWJL aXQyL1VJUHJvY2Vzcy9BUEkvZWZsL0JhdHRlcnlQcm92aWRlci5jcHAKaW5kZXggODNjYzM3MTE5 NDEyNzZiMDU5YzA3MGVjNTk2NjZlNjVlOWU0Y2U4Ni4uOWJjNmJmMzU3NTI0NjdlMDhlOWQ5MTgw OGQ2YWE4MGYwM2VmOThmMCAxMDA2NDQKLS0tIGEvU291cmNlL1dlYktpdDIvVUlQcm9jZXNzL0FQ SS9lZmwvQmF0dGVyeVByb3ZpZGVyLmNwcAorKysgYi9Tb3VyY2UvV2ViS2l0Mi9VSVByb2Nlc3Mv QVBJL2VmbC9CYXR0ZXJ5UHJvdmlkZXIuY3BwCkBAIC01Myw2ICs1Myw3IEBAIHN0YXRpYyB2b2lk IHN0b3BVcGRhdGluZ0NhbGxiYWNrKFdLQmF0dGVyeU1hbmFnZXJSZWYsIGNvbnN0IHZvaWQqIGNs aWVudEluZm8pCiBCYXR0ZXJ5UHJvdmlkZXI6On5CYXR0ZXJ5UHJvdmlkZXIoKQogewogICAgIG1f cHJvdmlkZXIuc3RvcFVwZGF0aW5nKCk7CisgICAgV0tCYXR0ZXJ5TWFuYWdlclNldFByb3ZpZGVy KG1fd2tCYXR0ZXJ5TWFuYWdlci5nZXQoKSwgMCk7CiB9CiAKIFBhc3NSZWZQdHI8QmF0dGVyeVBy b3ZpZGVyPiBCYXR0ZXJ5UHJvdmlkZXI6OmNyZWF0ZShXS0JhdHRlcnlNYW5hZ2VyUmVmIHdrQmF0 dGVyeU1hbmFnZXIpCmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViS2l0Mi9VSVByb2Nlc3MvQVBJL2Vm bC9OZXR3b3JrSW5mb1Byb3ZpZGVyLmNwcCBiL1NvdXJjZS9XZWJLaXQyL1VJUHJvY2Vzcy9BUEkv ZWZsL05ldHdvcmtJbmZvUHJvdmlkZXIuY3BwCmluZGV4IDU0YTY5MjFkYTU1MTdjM2MxNDRmMmFj NTYwYjJlZTliMWNjYzhhODcuLjQxYWQ5YTE5MmU4YzE4ZWU3NDRhNzI4YzZkM2FiZDU2OWY4MGFk MGMgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9XZWJLaXQyL1VJUHJvY2Vzcy9BUEkvZWZsL05ldHdvcmtJ bmZvUHJvdmlkZXIuY3BwCisrKyBiL1NvdXJjZS9XZWJLaXQyL1VJUHJvY2Vzcy9BUEkvZWZsL05l dHdvcmtJbmZvUHJvdmlkZXIuY3BwCkBAIC03OSw2ICs3OSw3IEBAIE5ldHdvcmtJbmZvUHJvdmlk ZXI6Ok5ldHdvcmtJbmZvUHJvdmlkZXIoV0tOZXR3b3JrSW5mb01hbmFnZXJSZWYgd2tNYW5hZ2Vy KQogCiBOZXR3b3JrSW5mb1Byb3ZpZGVyOjp+TmV0d29ya0luZm9Qcm92aWRlcigpCiB7CisgICAg V0tOZXR3b3JrSW5mb01hbmFnZXJTZXRQcm92aWRlcihtX3drTmV0d29ya0luZm9NYW5hZ2VyLmdl dCgpLCAwKTsKIH0KIAogZG91YmxlIE5ldHdvcmtJbmZvUHJvdmlkZXI6OmJhbmR3aWR0aCgpIGNv bnN0CmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViS2l0Mi9VSVByb2Nlc3MvQVBJL2VmbC9WaWJyYXRp b25Qcm92aWRlci5jcHAgYi9Tb3VyY2UvV2ViS2l0Mi9VSVByb2Nlc3MvQVBJL2VmbC9WaWJyYXRp b25Qcm92aWRlci5jcHAKaW5kZXggMjlmYjZhNGZjMWM3MGQ5NzRkN2I4MjM1NzEzZjRlN2M2ZmIz MzhlZS4uZTcxMDY0ZGViNjVlYzg1NTY5YTE4MjY0YTliN2UxODllNzM0ZjE2NiAxMDA2NDQKLS0t IGEvU291cmNlL1dlYktpdDIvVUlQcm9jZXNzL0FQSS9lZmwvVmlicmF0aW9uUHJvdmlkZXIuY3Bw CisrKyBiL1NvdXJjZS9XZWJLaXQyL1VJUHJvY2Vzcy9BUEkvZWZsL1ZpYnJhdGlvblByb3ZpZGVy LmNwcApAQCAtODYsNiArODYsNyBAQCBWaWJyYXRpb25Qcm92aWRlcjo6VmlicmF0aW9uUHJvdmlk ZXIoV0tWaWJyYXRpb25SZWYgd2tWaWJyYXRpb25SZWYpCiAKIFZpYnJhdGlvblByb3ZpZGVyOjp+ VmlicmF0aW9uUHJvdmlkZXIoKQogeworICAgIFdLVmlicmF0aW9uU2V0UHJvdmlkZXIobV93a1Zp YnJhdGlvblJlZi5nZXQoKSwgMCk7CiB9CiAKIHZvaWQgVmlicmF0aW9uUHJvdmlkZXI6OnZpYnJh dGUodWludDY0X3QgdmlicmF0aW9uVGltZSkK 165947 2012-09-27 00:43:13 -0700 2012-09-27 21:55:23 -0700 Patch bug-97528-20120927164224.patch text/plain 4625 bw80.lee U3VidmVyc2lvbiBSZXZpc2lvbjogMTI5NzI4CmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViS2l0Mi9D aGFuZ2VMb2cgYi9Tb3VyY2UvV2ViS2l0Mi9DaGFuZ2VMb2cKaW5kZXggOGY1YTZmYTY2ZDFlNWVh YmZkOTRlNGFlZDE2OTc3NWUyZDFmYjBjYi4uNGIyN2FmMzY0ZTlhNGNkNzVlMTA4Y2Q1OTJmZWVm YmRhN2E5OGNlMyAxMDA2NDQKLS0tIGEvU291cmNlL1dlYktpdDIvQ2hhbmdlTG9nCisrKyBiL1Nv dXJjZS9XZWJLaXQyL0NoYW5nZUxvZwpAQCAtMSwzICsxLDQwIEBACisyMDEyLTA5LTI3ICBCeXVu Z3dvbyBMZWUgIDxidzgwLmxlZUBzYW1zdW5nLmNvbT4KKworICAgICAgICBbRUZMXVtXSzJdIFBy ZXZlbnQgYWNjZXNzaW5nIGRhbmdsaW5nIHBvaW50ZXIgd2hpbGUgZGVsZXRpbmcgRXdrX0NvbnRl eHQuCisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD05NzUy OAorCisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAgIFZpYnJh dGlvblByb3ZpZGVyIGFuZCBXZWJWaWJyYXRpb25Qcm94eSBib3RoIGhhcyBlYWNoIG90aGVyJ3Mg cG9pbnRlci4KKyAgICAgICAgQW5kIHRoZSBpbnN0YW5jZSBvZiBWaWJyYXRpb25Qcm92aWRlciBh bmQgV2ViVmlicmF0aW9uUHJveHkgaXMgZGVsZXRlZAorICAgICAgICBzZXBlcmF0ZWx5IHdoaWxl IGRlbGV0aW5nIEV3a19Db250ZXh0LgorCisgICAgICAgIER1cmluZyB0aGUgZGVsZXRpb24gb2Yg RXdrX0NvbnRleHQsIFdlYlZpYnJhdGlvblByb3h5IHBlcmZvcm1zIHNvbWUKKyAgICAgICAgY29k ZXMgdG8gYWNjZXNzIHRvIHRoZSBWaWJyYXRpb25Qcm92aWRlci4KKyAgICAgICAgSWYgdGhlIFZp YnJhdGlvblByb3ZpZGVyIGlzIGRlbGV0ZWQgYmVmb3JlIFdlYlZpYnJhdGlvblByb3h5LCB0aGVy ZQorICAgICAgICB3aWxsIGJlIGEgcHJvYmxlbSB0byBhY2Nlc3MgdGhlIGRhbmdsaW5nIHBvaW50 ZXIuCisKKyAgICAgICAgTW9yZW92ZXIsIHRoZXJlIGlzIG5vIHByb3ZpZGVyIGNsZWFyIGNvZGUg b24gdGhlIFZpYnJhdGlvblByb3ZpZGVyCisgICAgICAgIGRlc3RydWN0b3IuIEluIHRoZSBjb25z dHJ1Y3RvciBvZiBWaWJyYXRpb25Qcm92aWRlciwgaXQgcmVnaXN0ZXJzCisgICAgICAgIHZpYnJh dGlvbiBwcm92aWRlciB0byBXZWJWaWJyYXRpb25Qcm94eSB3aXRoIGl0J3MgdGhpcyBwb2ludGVy LgorICAgICAgICBJZiB0aGVyZSBpcyBubyBjb2RlIHRvIGNsZWFyIHRoYXQgaW4gdGhlIGRlc3Ry dWN0b3IsIHRoZXJlIGlzIGEgZGFuZ2VyCisgICAgICAgIHRvIGFjY2VzcyBkYW5nbGluZyBwb2lu dGVyLgorCisgICAgICAgIFRob3NlIGFyZSBzYW1lIHdpdGggQmF0dGVyeVByb3ZpZGVyIGFuZCBO ZXR3b3JrSW5mb1Byb3ZpZGVyLgorCisgICAgICAgIFRvIHByZXZlbnQgdGhpcywKKyAgICAgICAg YWRkZWQgcHJvdmlkZXIgY2xlYXIgY29kZSBpbiB0aGUgZGVzdHJ1Y3RvciBvZiBwcm92aWRlciBj bGFzcywKKyAgICAgICAgYW5kIGFkZGVkIGNvZGVzIHRvIGRlbGV0ZSBleHBsaWNpdGx5IGluIHRo ZSBkZXN0cnVjdG9yIG9mIEV3a19Db250ZXh0LgorCisgICAgICAgICogVUlQcm9jZXNzL0FQSS9l ZmwvQmF0dGVyeVByb3ZpZGVyLmNwcDoKKyAgICAgICAgKEJhdHRlcnlQcm92aWRlcjo6fkJhdHRl cnlQcm92aWRlcik6CisgICAgICAgICogVUlQcm9jZXNzL0FQSS9lZmwvTmV0d29ya0luZm9Qcm92 aWRlci5jcHA6CisgICAgICAgIChOZXR3b3JrSW5mb1Byb3ZpZGVyOjp+TmV0d29ya0luZm9Qcm92 aWRlcik6CisgICAgICAgICogVUlQcm9jZXNzL0FQSS9lZmwvVmlicmF0aW9uUHJvdmlkZXIuY3Bw OgorICAgICAgICAoVmlicmF0aW9uUHJvdmlkZXI6On5WaWJyYXRpb25Qcm92aWRlcik6CisgICAg ICAgICogVUlQcm9jZXNzL0FQSS9lZmwvZXdrX2NvbnRleHQuY3BwOgorICAgICAgICAoX0V3a19D b250ZXh0Ojp+X0V3a19Db250ZXh0KToKKwogMjAxMi0wOS0yNiAgU2FtIFdlaW5pZyAgPHNhbUB3 ZWJraXQub3JnPgogCiAgICAgICAgIEZpeCBYUENTZXJ2aWNlcyBzeW1saW5rIHRvIG5vdCBiZSB0 byBhbiBhYnNvbHV0ZSBwYXRoCmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViS2l0Mi9VSVByb2Nlc3Mv QVBJL2VmbC9CYXR0ZXJ5UHJvdmlkZXIuY3BwIGIvU291cmNlL1dlYktpdDIvVUlQcm9jZXNzL0FQ SS9lZmwvQmF0dGVyeVByb3ZpZGVyLmNwcAppbmRleCA4M2NjMzcxMTk0MTI3NmIwNTljMDcwZWM1 OTY2NmU2NWU5ZTRjZTg2Li45YmM2YmYzNTc1MjQ2N2UwOGU5ZDkxODA4ZDZhYTgwZjAzZWY5OGYw IDEwMDY0NAotLS0gYS9Tb3VyY2UvV2ViS2l0Mi9VSVByb2Nlc3MvQVBJL2VmbC9CYXR0ZXJ5UHJv dmlkZXIuY3BwCisrKyBiL1NvdXJjZS9XZWJLaXQyL1VJUHJvY2Vzcy9BUEkvZWZsL0JhdHRlcnlQ cm92aWRlci5jcHAKQEAgLTUzLDYgKzUzLDcgQEAgc3RhdGljIHZvaWQgc3RvcFVwZGF0aW5nQ2Fs bGJhY2soV0tCYXR0ZXJ5TWFuYWdlclJlZiwgY29uc3Qgdm9pZCogY2xpZW50SW5mbykKIEJhdHRl cnlQcm92aWRlcjo6fkJhdHRlcnlQcm92aWRlcigpCiB7CiAgICAgbV9wcm92aWRlci5zdG9wVXBk YXRpbmcoKTsKKyAgICBXS0JhdHRlcnlNYW5hZ2VyU2V0UHJvdmlkZXIobV93a0JhdHRlcnlNYW5h Z2VyLmdldCgpLCAwKTsKIH0KIAogUGFzc1JlZlB0cjxCYXR0ZXJ5UHJvdmlkZXI+IEJhdHRlcnlQ cm92aWRlcjo6Y3JlYXRlKFdLQmF0dGVyeU1hbmFnZXJSZWYgd2tCYXR0ZXJ5TWFuYWdlcikKZGlm ZiAtLWdpdCBhL1NvdXJjZS9XZWJLaXQyL1VJUHJvY2Vzcy9BUEkvZWZsL05ldHdvcmtJbmZvUHJv dmlkZXIuY3BwIGIvU291cmNlL1dlYktpdDIvVUlQcm9jZXNzL0FQSS9lZmwvTmV0d29ya0luZm9Q cm92aWRlci5jcHAKaW5kZXggNTRhNjkyMWRhNTUxN2MzYzE0NGYyYWM1NjBiMmVlOWIxY2NjOGE4 Ny4uNDFhZDlhMTkyZThjMThlZTc0NGE3MjhjNmQzYWJkNTY5ZjgwYWQwYyAxMDA2NDQKLS0tIGEv U291cmNlL1dlYktpdDIvVUlQcm9jZXNzL0FQSS9lZmwvTmV0d29ya0luZm9Qcm92aWRlci5jcHAK KysrIGIvU291cmNlL1dlYktpdDIvVUlQcm9jZXNzL0FQSS9lZmwvTmV0d29ya0luZm9Qcm92aWRl ci5jcHAKQEAgLTc5LDYgKzc5LDcgQEAgTmV0d29ya0luZm9Qcm92aWRlcjo6TmV0d29ya0luZm9Q cm92aWRlcihXS05ldHdvcmtJbmZvTWFuYWdlclJlZiB3a01hbmFnZXIpCiAKIE5ldHdvcmtJbmZv UHJvdmlkZXI6On5OZXR3b3JrSW5mb1Byb3ZpZGVyKCkKIHsKKyAgICBXS05ldHdvcmtJbmZvTWFu YWdlclNldFByb3ZpZGVyKG1fd2tOZXR3b3JrSW5mb01hbmFnZXIuZ2V0KCksIDApOwogfQogCiBk b3VibGUgTmV0d29ya0luZm9Qcm92aWRlcjo6YmFuZHdpZHRoKCkgY29uc3QKZGlmZiAtLWdpdCBh L1NvdXJjZS9XZWJLaXQyL1VJUHJvY2Vzcy9BUEkvZWZsL1ZpYnJhdGlvblByb3ZpZGVyLmNwcCBi L1NvdXJjZS9XZWJLaXQyL1VJUHJvY2Vzcy9BUEkvZWZsL1ZpYnJhdGlvblByb3ZpZGVyLmNwcApp bmRleCAyOWZiNmE0ZmMxYzcwZDk3NGQ3YjgyMzU3MTNmNGU3YzZmYjMzOGVlLi5lNzEwNjRkZWI2 NWVjODU1NjlhMTgyNjRhOWI3ZTE4OWU3MzRmMTY2IDEwMDY0NAotLS0gYS9Tb3VyY2UvV2ViS2l0 Mi9VSVByb2Nlc3MvQVBJL2VmbC9WaWJyYXRpb25Qcm92aWRlci5jcHAKKysrIGIvU291cmNlL1dl YktpdDIvVUlQcm9jZXNzL0FQSS9lZmwvVmlicmF0aW9uUHJvdmlkZXIuY3BwCkBAIC04Niw2ICs4 Niw3IEBAIFZpYnJhdGlvblByb3ZpZGVyOjpWaWJyYXRpb25Qcm92aWRlcihXS1ZpYnJhdGlvblJl ZiB3a1ZpYnJhdGlvblJlZikKIAogVmlicmF0aW9uUHJvdmlkZXI6On5WaWJyYXRpb25Qcm92aWRl cigpCiB7CisgICAgV0tWaWJyYXRpb25TZXRQcm92aWRlcihtX3drVmlicmF0aW9uUmVmLmdldCgp LCAwKTsKIH0KIAogdm9pZCBWaWJyYXRpb25Qcm92aWRlcjo6dmlicmF0ZSh1aW50NjRfdCB2aWJy YXRpb25UaW1lKQpkaWZmIC0tZ2l0IGEvU291cmNlL1dlYktpdDIvVUlQcm9jZXNzL0FQSS9lZmwv ZXdrX2NvbnRleHQuY3BwIGIvU291cmNlL1dlYktpdDIvVUlQcm9jZXNzL0FQSS9lZmwvZXdrX2Nv bnRleHQuY3BwCmluZGV4IGIzNGZmNzdkZjY5MTFjMjRhZDM1YTEyMzAwMDk3NDk2MjlhYzM5NmQu LmY2MzZjOTVmZmQ0OTE3YjBjMzU4NmM2ODZkYTVlN2UwMDBlYzczYTQgMTAwNjQ0Ci0tLSBhL1Nv dXJjZS9XZWJLaXQyL1VJUHJvY2Vzcy9BUEkvZWZsL2V3a19jb250ZXh0LmNwcAorKysgYi9Tb3Vy Y2UvV2ViS2l0Mi9VSVByb2Nlc3MvQVBJL2VmbC9ld2tfY29udGV4dC5jcHAKQEAgLTExNCw2ICsx MTQsMTQgQEAgc3RydWN0IF9Fd2tfQ29udGV4dCB7CiAgICAgICAgIEhhc2hNYXA8dWludDY0X3Qs IEV3a19Eb3dubG9hZF9Kb2IqPjo6aXRlcmF0b3IgZW5kID0gZG93bmxvYWRKb2JzLmVuZCgpOwog ICAgICAgICBmb3IgKCA7IGl0ICE9IGVuZDsgKytpdCkKICAgICAgICAgICAgIGV3a19kb3dubG9h ZF9qb2JfdW5yZWYoaXQtPnNlY29uZCk7CisKKyNpZiBFTkFCTEUoQkFUVEVSWV9TVEFUVVMpCisg ICAgICAgIGJhdHRlcnlQcm92aWRlci5jbGVhcigpOworI2VuZGlmCisKKyNpZiBFTkFCTEUoVklC UkFUSU9OKQorICAgICAgICB2aWJyYXRpb25Qcm92aWRlci5jbGVhcigpOworI2VuZGlmCiAgICAg fQogfTsKIAo=