{"id":106213,"date":"2022-02-02T07:00:00","date_gmt":"2022-02-02T15:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=106213"},"modified":"2022-02-02T07:23:59","modified_gmt":"2022-02-02T15:23:59","slug":"20220202-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20220202-00\/?p=106213","title":{"rendered":"Gotcha: C++\/WinRT weak_ref.get() doesn’t get the weak reference; it gets the strong reference"},"content":{"rendered":"

If you have a winrt::com_ptr<T><\/code>, you can call the get()<\/code> method to obtain the raw COM pointer inside it. This is handy if you need to pass that raw pointer along to another method that wants raw pointers.<\/p>\n

The winrt::weak_ref<T><\/code> also has a get()<\/code> method, but its behavior is different: It tries to resolve the weak reference to a strong reference and returns that strong reference as a com_ptr<T><\/code>. If it fails to resolve the weak reference to a strong reference, then it returns an empty com_ptr<T><\/code>. (If T<\/code> is a projected type, then the returned object is a T<\/code> rather than com_ptr<T><\/code>, since com_ptr<T><\/code> is redundant.)<\/p>\n

I’ve seen this gotcha bite people who are familiar with com_ptr<\/code>s, but haven’t worked much with weak_ref<\/code>. They have a weak_ref<\/code> in their hand and they want to look at the pointer inside it. They’ll call weak_ref.get()<\/code> (because that’s what works for com_ptr<\/code>), and not only is that not what they want, the result can be downright dangerous.<\/p>\n

weak_ref<T> saved_weak;\r\n\r\nbool IsTheSavedWeakRef(weak_ref<T> const& ref)\r\n{\r\n    return saved_weak.get() == ref.get();\r\n}\r\n<\/pre>\n
The idea here is that we want to compare the IWeak\u00adReference<\/code> pointers hiding inside the weak_ref<\/code> to see if the weak reference passed in is the same one we had saved earlier. Unfortunately, what actually happens is that we resolve both weak references to strong T<\/code> references, and then see if the strong references match.<\/p>\n
The first bug is that this treats all broken weak references as equal, even if they aren’t the same<\/i> weak reference. Indeed, they may even have been obtained from different objects entirely!<\/p>\n
The second bug is that the temporary materialization of a strong reference means that when the function returns, those strong references are released, and that can result in object destruction at a time you weren’t expecting. Suppose we initially have a strong reference to a T<\/code> in a variable called saved_strong<\/code> and a weak reference to the same T<\/code> in a variable called saved_weak<\/code>.<\/p>\n\n\n\n\n\n\n\n
Thread 1<\/td>\nThread 2<\/td>\n\u00a0<\/td>\nRefcount on T<\/code><\/td>\n<\/tr>\n
IsTheSavedWeakRef()<\/code><\/td>\n <\/td>\n\u00a0<\/td>\n1<\/td>\n<\/tr>\n
saved_weak.get()<\/code><\/td>\n <\/td>\n\u00a0<\/td>\n2<\/td>\n<\/tr>\n
 <\/td>\nsaved_strong.reset()<\/code><\/td>\n\u00a0<\/td>\n1<\/td>\n<\/tr>\n
temporary com_ptr<\/code> destructs<\/td>\n <\/td>\n\u00a0<\/td>\n0<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Initially, there is one strong reference to the object, held in saved_strong<\/code>. The Is\u00adThe\u00adSaved\u00adWeak\u00adRef()<\/code> function tries to promote the saved_weak<\/code> to a strong reference in the form of a com_ptr<\/code> (say), and it succeeds. The number of strong references is now two.<\/p>\n
Meanwhile, another thread resets the saved_strong<\/code> strong reference, which would have destructed the object if Is\u00adThe\u00adSaved\u00adWeak\u00adRef()<\/code> hadn’t created a temporary strong reference. Instead, the reset of saved_strong<\/code> causes the reference count to drop to one.<\/p>\n
Back on Thread\u00a01, the Is\u00adThe\u00adSaved\u00adWeak\u00adRef()<\/code> function finishes its comparison and destructs the temporary shared_ptr<\/code>, which drops the reference count to zero and destroys the object.<\/p>\n
The Is\u00adThe\u00adSaved\u00adWeak\u00adRef()<\/code> function is destroying an object!<\/p>\n
This can be quite a surprise to the authors of Is\u00adThe\u00adSaved\u00adWeak\u00adRef()<\/code>, who thought they were doing completely non-intrusive lightweight operations. In particular, the caller of Is\u00adThe\u00adSaved\u00adWeak\u00adRef()<\/code> might be holding a lock, such as one that is designed to protect access to saved_weak<\/code>.<\/p>\n
Now you are in the world of  destroying an object under a lock<\/a>, and depending on how those objects are structured, this could be harmless or create a potential deadlock or trigger memory corruption due to unexpected reentrancy.<\/p>\n
Bonus chatter<\/b>: With  PR#608<\/a>, you can now compare weak references directly for equality, so you aren’t tempted to try the get()<\/code> trick.<\/p>\n
Nevertheless, if you want to get the raw pointer inside a winrt::weak_ref<\/code>, you can use get_abi<\/code>.<\/p>\n
Bonus bonus chatter<\/b>: The WIL library has its own quirk related to COM weak references and COM agile references. The wil::com_weak_ref<\/code> and wil::com_agile_ref<\/code> act like a wil::com_ptr<\/code> in most respects, but the query<\/code> and copy<\/code> methods operate on the underlying object, not the weak reference or agile reference itself.<\/p>\n
For weak references, this is normally what you want, since there isn’t much you can query from a weak reference. However, if you have a weak reference to a remote object, you may want to query the weak reference for interfaces like IMarshal<\/code> or IClientSecurity<\/code>, and those queries will go not to the weak reference but to the underlying object.<\/p>\n
If you want to perform the query against the weak reference itself, you will have to use a Jedi mind trick to make WIL forget that the pointer was ever a weak pointer: Decay it back to the IUnknown<\/code>, and then operate on that.<\/p>\n
\/\/ marshal = saved_weak.query<IMarshal>(); \/\/ doesn't work, do this instead\r\nauto marshal = wil::com_query<IMarshal>(static_cast<IUnknown*>(saved_weak.get()));\r\n<\/pre>\n
Here, we use the free com_query<\/code> function which does the equivalent of a com_ptr.query<\/code>, but as a free function instead of requiring a com_ptr<\/code> in hand.<\/p>\n
(Personally, I think this magic behavior of weak and agile references is a pit of failure. I think the methods should have been called lock<\/code> or resolve<\/code>. Reserve get<\/code> for extracting the raw ABI pointer.)<\/p>\n","protected":false},"excerpt":{"rendered":"
What traditionally goes by the name lock()<\/CODE>.<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[25],"class_list":["post-106213","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
What traditionally goes by the name lock()<\/CODE>.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/106213","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=106213"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/106213\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=106213"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=106213"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=106213"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}