{"id":15963,"date":"2009-11-19T07:00:00","date_gmt":"2009-11-19T07:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/oldnewthing\/2009\/11\/19\/were-using-a-smart-pointer-so-we-cant-possibly-be-the-source-of-the-leak\/"},"modified":"2009-11-19T07:00:00","modified_gmt":"2009-11-19T07:00:00","slug":"were-using-a-smart-pointer-so-we-cant-possibly-be-the-source-of-the-leak","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20091119-00\/?p=15963","title":{"rendered":"We're using a smart pointer, so we can't possibly be the source of the leak"},"content":{"rendered":"

\nA customer reported that there was a leak in the shell,\nand they included the output from\n\nApplication Verifier<\/a>\nas proof.\nAnd yup, the memory that was leaked was in fact allocated\nby the shell:\n<\/p>\n

\nVERIFIER STOP 00000900 : pid 0x3A4: A heap allocation was leaked.\n        497D0FC0 : Address of the leaked allocation.\n        002DB580 : Adress to the allocation stack trace.\n        0D65CFE8 : Address of the owner dll name.\n        6F560000 : Base of the owner dll.\n1: kd> du 0D65CFE8\n0d65cfe8  \"SHLWAPI.dll\"\n1: kd> !heap -p -a 497D0FC0\n...\n    ntdll!RtlpAllocateHeap+0x0003f236\n    ntdll!RtlAllocateHeap+0x0000014f\n    Kernel32!LocalAlloc+0x0000007c\n    shlwapi!CreateMemStreamEx+0x00000043\n    shlwapi!CreateMemStream+0x00000012\n    <Unloaded_xyz.dll>+0x000642de\n    <Unloaded_xyz.dll>+0x0005e2af\n    <Unloaded_xyz.dll>+0x0002d49a\n    <Unloaded_xyz.dll>+0x0002a0fd\n    <Unloaded_xyz.dll>+0x000289cb\n    <Unloaded_xyz.dll>+0x0002a25c\n    <Unloaded_xyz.dll>+0x00027225\n    <Unloaded_xyz.dll>+0x0002252b\n    <Unloaded_xyz.dll>+0x00025394\n    <Unloaded_xyz.dll>+0x0004d70f\n    Kernel32!BaseThreadInitThunk+0x0000000d\n    ntdll!RtlUserThreadStart+0x0000001d\n1: kd> dps 002DB580\nshlwapi!CreateMemStreamEx+0x43\nshlwapi!CreateMemStream+0x12\n<Unloaded_xyz.dll>+0x642de\n<Unloaded_xyz.dll>+0x5e2af\n<Unloaded_xyz.dll>+0x2d49a\n<Unloaded_xyz.dll>+0x2a0fd\n<Unloaded_xyz.dll>+0x289cb\n<Unloaded_xyz.dll>+0x2a25c\n<Unloaded_xyz.dll>+0x27225\n<Unloaded_xyz.dll>+0x2252b\n<Unloaded_xyz.dll>+0x25394\n<Unloaded_xyz.dll>+0x4d70f\nKernel32!BaseThreadInitThunk+0xd\nntdll!RtlUserThreadStart+0x1d\n<\/pre>\n
\nOn the other hand, SHCreateMemStream<\/code> is\nan object creation function,\nso it’s natural that the function allocate some memory.\nThe responsibility for freeing the memory belongs to the caller.\n<\/p>\n
\nWe suggested that the customer appears to have leaked the\ninterface pointer.\nPerhaps there’s a hole where they called AddRef<\/code>\nand managed to avoid the matching Release<\/code>.\n<\/p>\n
\n“Oh no,” the customer replied,\n“that’s not possible.\nWe call this function in only one place,\nand we use a smart pointer,\nso a leak is impossible.”\nThe customer was kind enough to include a code snippet\nand even highlighted the lines that proved they weren’t\nleaking.\n<\/p>\n
\nCComPtr<IStream> pMemoryStream;<\/font>\nCComPtr<IXmlReader> pReader;\nUINT nDepth = 0;\n\/\/Open read-only input stream\npMemoryStream = ::SHCreateMemStream(utf8Xml, cbUtf8Xml);<\/font>\n<\/pre>\n
\nThe exercise for today is to identify the irony in the\nhighlighted lines.\n<\/p>\n
\n\nHint<\/a>.\nAnswers (and more discussion) tomorrow.<\/p>\n","protected":false},"excerpt":{"rendered":"
A customer reported that there was a leak in the shell, and they included the output from Application Verifier as proof. And yup, the memory that was leaked was in fact allocated by the shell: VERIFIER STOP 00000900 : pid 0x3A4: A heap allocation was leaked. 497D0FC0 : Address of the leaked allocation. 002DB580 : […]<\/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-15963","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
A customer reported that there was a leak in the shell, and they included the output from Application Verifier as proof. And yup, the memory that was leaked was in fact allocated by the shell: VERIFIER STOP 00000900 : pid 0x3A4: A heap allocation was leaked. 497D0FC0 : Address of the leaked allocation. 002DB580 : […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/15963","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=15963"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/15963\/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=15963"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=15963"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=15963"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}