{"id":111560,"date":"2025-09-05T07:00:00","date_gmt":"2025-09-05T14:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=111560"},"modified":"2025-09-08T08:46:22","modified_gmt":"2025-09-08T15:46:22","slug":"20250905-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20250905-00\/?p=111560","title":{"rendered":"The case of the crash on a null pointer even though we checked it for null"},"content":{"rendered":"

A colleague was investigating a crash. The stack at the point of the crash looks like this:<\/p>\n

contoso!winrt::impl::consume_Windows_Foundation_Collections_IVectorView<\r\n            winrt::Windows::Foundation::Collections::IVectorView<int>,\r\n            int>::Size+0x30\r\ncontoso!winrt::Contoso::implementation::Widget::\r\n            InitializeNodesAsync$_ResumeCoro$1+0x2bc\r\ncontoso!wil::details::coro::apartment_resumer::resume_apartment_callback+0x28\r\ncombase!CRemoteUnknown::DoCallback+0x34\r\ncombase!CRemoteUnknown::DoNonreentrantCallback+0x48\r\nrpcrt4!Invoke+0x64\r\nrpcrt4!InvokeHelper+0x130\r\nrpcrt4!Ndr64StubWorker+0x6cc\r\nrpcrt4!NdrStubCall3+0xdc\r\ncombase!CStdStubBuffer_Invoke+0x6c\r\ncombase!ObjectMethodExceptionHandlingAction<\u27e6...\u27e7>+0x48\r\ncombase!DefaultStubInvoke+0x2b8\r\ncombase!SyncServerCall::StubInvoke+0x40\r\ncombase!StubInvoke+0x170\r\ncombase!ServerCall::ContextInvoke+0x3c4\r\ncombase!ReentrantSTAInvokeInApartment+0x1fc\r\ncombase!ComInvokeWithLockAndIPID+0xcc4\r\ncombase!ThreadDispatch+0x514\r\ncombase!ThreadWndProc+0x1b4\r\nuser32!UserCallWinProcCheckWow+0x180\r\nuser32!DispatchMessageWorker+0x130\r\n<\/pre>\n
If we look at the point of the fault:<\/p>\n
0:001>  r\r\nLast set context:\r\n x0=0000000000000000   x1=00000053af4fdf78   x2=0000017b4f7e6380   x3=0000000000000000\r\n x4=6597e92abf947185   x5=857194bf2ae99765   x6=857194bf2ae99765   x7=0000017b4f700000\r\n x8=00007ff85b11ce40   x9=0000000000000001  x10=0000006700000000  x11=0000000000000000\r\nx12=fffffffffff00000  x13=0000000000000000  x14=0000000000000000  x15=000000000000000b\r\nx16=00007ff8d4fd44a0  x17=ffff68553f08a1c6  x18=00007ff8d0bc0000  x19=0000017b4c834de0\r\nx20=0000000000000000  x21=00007ff8d45cd188  x22=00007ff8d45cd188  x23=00007ff8d45cd150\r\nx24=0000017b31196930  x25=00000053af4fdfa0  x26=00000053af4fe580  x27=0000000000000010\r\nx28=0000000000000000   fp=00000053af4fdf90   lr=00007ff85af448cc   sp=00000053af4fdf60\r\n pc=00007ff85af448f0  psr=80001040 N--- EL0\r\ncontoso!winrt::impl::consume_Windows_Foundation_Collections_IVectorView<\r\n    winrt::Windows::Foundation::Collections::IVectorView<int>,\r\n    int>::Size+0x30:\r\n00007ff8`5af448f0 f9400008 ldr         x8,[x0]\r\n<\/pre>\n
we see that we are crashing on a null pointer (x0<\/tt>).<\/p>\n
The function is a C++\/WinRT consume_<\/code>, which is just a projection of the underlying COM call. The COM call is performed by reading the vtable pointer from the object, reading the function pointer from the vtable, and then calling the function.<\/p>\n
The fact that we are reading from x0<\/tt> (the inbound and outbound parameter slot) means that this is almost certainly reading the vtable pointer from the object: We want the COM pointer in x0<\/tt> for the outbound call, so the obvious thing to do is to leave it there while you read the vtable pointer from it.<\/p>\n
We can confirm this by reading the disassembly.<\/p>\n
0:001> u .-30 .\r\ncontoso!winrt::impl::consume_Windows_Foundation_Collections_IVectorView<\r\n    winrt::Windows::Foundation::Collections::IVectorView<int>,\r\n    int>::Size+0x30:\r\n00007ff8`5af448c0 stp         fp,lr,[sp,#-0x10]!   ; build stack frame\r\n00007ff8`5af448c4 mov         fp,sp\r\n00007ff8`5af448c8 bl          contoso!__security_push_cookie (00007ff8`5ab91050)\r\n00007ff8`5af448cc sub         sp,sp,#0x20\r\n00007ff8`5af448d0 mov         w8,#0x1E4\r\n00007ff8`5af448d4 ldr         x0,[x0]              ; fetch the COM pointer<\/span>\r\n00007ff8`5af448d8 str         wzr,[sp,#0x18]\r\n00007ff8`5af448dc str         w8,[sp]\r\n00007ff8`5af448e0 adrp        x8,contoso!`string'+0x10 (00007ff8`5b11c000)\r\n00007ff8`5af448e4 add         x8,x8,#0xE40\r\n00007ff8`5af448e8 stp         x8,xzr,[sp,#8]\r\n00007ff8`5af448ec add         x1,sp,#0x18\r\n00007ff8`5af448f0 ldr         x8,[x0]              ; read the vtable<\/span>\r\n<\/pre>\n
(The other code is recording the line number and file name for diagnostic purposes.)<\/p>\n
Okay, so we are calling IVectorView<T>::Size<\/code> on a null pointer.<\/p>\n
Let’s see whose idea that is.<\/p>\n
Here’s the caller:<\/p>\n
winrt::IAsyncAction Widget::InitializeNodesAsync()\r\n{\r\n    auto lifetime = get_strong();\r\n    std::optional<winrt::IVectorView<int32_t>> numbers;\r\n    co_await winrt::resume_background();\r\n    CallWithRetry([&] {\r\n        numbers = GetMagicNumbers();\r\n    });\r\n\r\n    if (numbers == nullptr)\r\n    {\r\n        co_return;\r\n    }\r\n\r\n    co_await winrt::resume_foreground(m_uithread);\r\n\r\n    std::vector<winrt::Node> nodes;\r\n    nodes.reserve((*numbers).Size()); \/\/ \u2190 CRASH HERE\r\n<\/pre>\n
The crash inside consume_<\/code> tells us that (*numbers)<\/code> is null. Let’s see if we can confirm that in the debugger.<\/p>\n
First, we have to find numbers<\/code>.<\/p>\n
0:001> dv \/V\r\n@x19              @x19        __coro_frame_ptr = 0x0000017b`4c834de0\r\n00000000`00000088 @x25+0x0590         lifetime = struct winrt::com_ptr<\r\n                                                     winrt::Contoso::implementation::Widget>\r\n00000000`000000e8 @x25+0x0590            nodes = class std::vector<int>\r\n00000000`000000d8 @x25+0x0590          numbers = class std::optional<winrt::Windows::Foundation::\r\n                                                     Collections::IVectorView<int> >\r\n\u27e6 ... \u27e7\r\n<\/pre>\n
The debugger says that numbers<\/code> is at @x25+0x0590<\/code>, and that this calculates out to 00000000`000000d8<\/code>, which is nonsense. So we can’t really trust that calculation.<\/p>\n
Let’s see what the code uses. We disassemble backward from the return address.<\/p>\n
0:001> k2\r\nChild-SP          RetAddr           Call Site\r\n00000053`af4fdf60 00007ff8`5b059c8c contoso!winrt::impl::consume_Windows_Foundation_Collections_IVectorView<\r\n                                        winrt::Windows::Foundation::Collections::IVectorView<int>,\r\n                                        int>::Size+0x30\r\n00000053`af4fdfa0 00007ff8`5abc5108 contoso!winrt::Contoso::implementation::Widget::\r\n                                        InitializeNodesAsync$_ResumeCoro$1+0x2bc\r\n<\/pre>\n
We read the return address from the function one deeper on the stack, giving us 00007ff8`5b059c8c<\/code>.<\/p>\n
00007ff8`5b059c84 add  x0,x19,#0xD8 \/\/ \u2190 setting up the call to consume_\r\n00007ff8`5b059c88 bl   contoso!winrt::impl::consume_Windows_Foundation_Collections_IVectorView<\r\n                           winrt::Windows::Foundation::Collections::IVectorView<int>,\r\n                           int>::Size\r\n00007ff8`5b059c8c uxtw x1,w0\r\n<\/pre>\n
From the disassembly, we see that the compiler stored the IVector<\/code> part of the numbers<\/code> at offset 0xD8<\/code> from the coroutine frame, which is in x19<\/code>.<\/p>\n
We can pluck the coroutine frame from the dv<\/code> output, or we can ask the debugger to restore the nonvolatile registers for us (which includes x19<\/code>):<\/p>\n
0:001> .frame \/c 2\r\n0:001> dps @x19+0xd8\r\n0000017b4c834eb8  0000000000000000 \/\/ <<<<< the stored IVector\r\n0000017b4c834ec0  0000017b4ff78400\r\n<\/pre>\n
We can ask the debugger for the layout of the std::optional<\/code> so we can see the full numbers<\/code>.<\/p>\n
I copied the type name from the earlier dv<\/code> output.<\/p>\n
0:001> dt contoso!std::optional<winrt::Windows::Foundation::Collections::IVectorView<int> >\r\n   +0x000 _Dummy           : std::_Nontrivial_dummy_type\r\n   +0x000 _Value           : winrt::Windows::Foundation::Collections::IVectorView<int>\r\n   +0x008 _Has_value       : Bool\r\n<\/pre>\n
Okay, so the value is kept at offset zero, and the _Has_value<\/code> is at offset 8.<\/p>\n
We can eyeball from the earlier dps<\/tt> command that the _Value<\/code> is nullptr, and the _Has_value<\/code> is false. (Little-endian means that the single bool<\/code> is in the least significant byte of the 8-byte value.)<\/p>\n
Or we can ask the debugger to interpret it for us.<\/p>\n
0:001> dt contoso!std::optional<winrt::Windows::Foundation::Collections::IVectorView<int> > @x19+0xd8\r\n   +0x000 _Dummy           : std::_Nontrivial_dummy_type\r\n   +0x000 _Value           : winrt::Windows::Foundation::Collections::IVectorView<int>\r\n   +0x008 _Has_value       : 0\r\n<\/pre>\n
Okay, so the numbers<\/code> has no value.<\/p>\n
But wait, our code checked for that!<\/p>\n
        if (numbers == nullptr)\r\n        {\r\n            co_return;\r\n        }\r\n<\/pre>\n
Why didn’t that work?<\/p>\n
Because that’s not how std::optional<\/code> works.<\/p>\n
The std::optional<\/code> is a sum type of T<\/code> with a special value called std::nullopt<\/code>. If you compare a std::optional<\/code> against anything that isn’t std::nullopt<\/code>, then you are checking if the std::optional<\/code> has a value that matches the value you are comparing against.<\/p>\n\n\n\n\n\n\n
std::optional holds<\/code><\/th>\ncompared with<\/th>\n<\/tr>\n
std::nullopt<\/code><\/th>\nY<\/code><\/th>\n<\/tr>\n
std::nullopt<\/code><\/td>\ntrue<\/td>\nfalse<\/td>\n<\/tr>\n
X<\/code><\/td>\nfalse<\/td>\nX == Y<\/code><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
For the purposes of comparison, an empty std::optional<\/code> is treated as if it had the value std::nullopt<\/code>, which is a value distinct from the value values of T<\/code>.<\/p>\n
Therefore, writing if (numbers == nullptr)<\/code> means “if numbers<\/code> has a value that is equal to nullptr<\/code>“.<\/p>\n
But in this case, numbers<\/code> has no value, so the comparison fails, and we fall through.<\/p>\n
Then we dereference the *numbers<\/code>, which is specified to retrieve the wrapped value, and it is undefined behavior if the numbers<\/code> has no value.<\/p>\n
In our case, the numbers<\/code> indeed has no value, so we have entered the world of undefined behavior. In practice, what happens is that we read whatever is in _Value<\/code>, and we saw in the debugger, that _Value<\/code> holds a null pointer. We then try to call Size()<\/code> on a null pointer and crash.<\/p>\n
One fix is to change the test from if (numbers == nullptr)<\/code> to if (!numbers.has_value())<\/code> to ask whether the numbers<\/code> is empty.<\/p>\n
But this is working too hard.<\/p>\n
The use of std::optional<T><\/code> was itself unnecessary. There is already a natural empty value for IVector<\/code>, namely nullptr<\/code>. So we can declare numbers<\/code> as an IVector<\/code>, which default-initializes to nullptr<\/code>, and then check whether it is still nullptr<\/code> after we try (and possibly fail) to get a value.<\/p>\n
winrt::IAsyncAction Widget::InitializeNodesAsync()\r\n{\r\n    auto lifetime = get_strong();\r\n    winrt::IVectorView<int32_t><\/span> numbers; \/\/ remove std::optional\r\n    co_await winrt::resume_background();\r\n    CallWithRetry([&] {\r\n        numbers = GetMagicNumbers();\r\n    });\r\n\r\n    if (numbers == nullptr)\r\n    {\r\n        co_return;\r\n    }\r\n\r\n    co_await winrt::resume_foreground(m_uithread);\r\n\r\n    std::vector<winrt::Node> nodes;\r\n    nodes.reserve(numbers<\/span>.Size()); \/\/ remove the *\r\n\r\n    \u27e6...\u27e7\r\n<\/pre>\n
This change also covers the case where GetMagicNumbers<\/code> succeeds but returns a null pointer.<\/p>\n
In practice, GetMagicNumbers<\/code> never returns a null pointer because it knows that  the empty set is not the same as no set at all<\/a>. The original code was testing against something that never happens.<\/p>\n","protected":false},"excerpt":{"rendered":"
Understanding what you’re checking.<\/p>\n","protected":false},"author":1069,"featured_media":110434,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[25],"class_list":["post-111560","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
Understanding what you’re checking.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/111560","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=111560"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/111560\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/110434"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=111560"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=111560"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=111560"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}