Why is there a memory leak on SHGetFolderPath()? (C++)

Question

I am runing Intel Inspector for finding memory leaks in an application. Now, the case is this: assume there is a function called MyGetPath() which does the following:

_TCHAR szFolderPath[520] =_T("");
SHGetFolderPath(NULL,CSIDL_PROGRAM_FILES,NULL,NULL,szFolderPath);
return _T("MemLeak");

When I run the Intel Inspector it reports a leak by 40 bytes, and the allocation site is the SHGetFolderPath line. But why is there a leak, and how to avoid it?

Microsoft MSDN reports 'SHGetFolderPath' as deprecated. What about if you use 'SHGetKnownFolderPath'? — gugu69, May 12 '15 at 12:20
Even deprecated `SHGetFolderPath` should not leak. Are you sure that it's not a false positive ? What happens if you call the `MyGetPath()` function 100 times ? Does your application leak 4000 bytes? — Jabberwocky, May 12 '15 at 12:21
@MichaelWalz Of course it should not leak, but maybe the wrapper is bogus. The `SHGetKnownFolderPath` require the address of a pointer to a null-terminated string. If somebody who wrote the wrapper forgot to free the memory allocated by the function then you have the memory leak. And if this wrapper contains some static stuff maybe simply call the function again and again the memory leak does'nt grow. — gugu69, May 12 '15 at 12:32
@MichaelWalz I tried to call it a 100 times (optimization off, debug build), but it still only reports 40 bytes as leaked object size and as far as I can see there is only one occurence in the list of issues related to this code place. — 10100111001, May 12 '15 at 12:32
It's probably a false positive. These 40 bytes will certainly get cleaned up by the OS upon program exit. — Jabberwocky, May 12 '15 at 12:34
And don't forget to free the buffer returned by the function: `PWSTR path; HRESULT hr = SHGetKnownFolderPath(FOLDERID_ProgramFiles, 0, NULL, &path); CoTaskMemFree(path);` — gugu69, May 12 '15 at 12:58
@prompt I had a little trouble at first (had to increase WINVER to 0x600 etc to get that function working. I ran a test exactly as you just posted and now it complains about 40 bytes leaking from SHGetKnownFolderPath() instead. :/ I sure hope it is only a false positive or else something is strange... Thanks though for all the ideas so far! — 10100111001, May 12 '15 at 13:06

score 2 · Accepted Answer · edited May 13 '15 at 07:20

I wrote a very simple program to experiment with it and with Deleaker to find what leaks could happen here:

#include <tchar.h>
#include <windows.h>
#include <Shlobj.h>

int _tmain(int argc, _TCHAR* argv[])
{
    DebugBreak(); // I take snapshot here

    _TCHAR szFolderPath[520] = _T("");
    SHGetFolderPath(NULL, CSIDL_PROGRAM_FILES, NULL, NULL, szFolderPath);

    // Then I take snapshot here
    // and compare with previous one
    DebugBreak();

    SHGetFolderPath(NULL, CSIDL_PROGRAM_FILES, NULL, NULL, szFolderPath);

    // Finally I take snapshot here
    // and compare with previous one
    DebugBreak();

    return 0;
}

As you see I take 3 snapshots.

I take the first snapshot and got some allocations:

snapshot #1

Then I take the second snapshot and calculate difference between it and previous snapshot to view what was allocated by SHGetFolderPath. Indeed some allocations were made:

snapshot #2

In fact I suspected that this is one time allocations and that's true: I call SHGetFolderPath again, take new snapshot and compare it with previous one. No new allocations:

snapshot #3

I did another experiment to be absolutely sure. Just start infinite cycle and check memory usage in Task Manager:

while (true)
{
    _TCHAR szFolderPath[520] = _T("");
    SHGetFolderPath(NULL, CSIDL_PROGRAM_FILES, NULL, NULL, szFolderPath);
}

Memory usage seems to be stable.

So I think you don't need to care about this small leak.

Thank you for your time and commitment for my question! Yes, it sure seems like there is no leak to worry about at least. — 10100111001, May 13 '15 at 07:06

Why is there a memory leak on SHGetFolderPath()? (C++)

1 Answers1