I have been looking at the following piece of code:
#include <memory>
using namespace std;
unique_ptr<int> uptr;
int main()
{
uptr = make_unique<int>();
return 0;
}
I used two tools to test it: Valgrind (running on WSL with Ubuntu) and Visual Studio's Memory Usage diagnostic tool. (The purpose was to see how the latter works, already having some (limited) practical experience with Valgrind.) The intention was to make sure that the globally-scoped unique pointer gets released as I expect it to.
Valgrind reports no leaks, errors, or warnings of any kind – indeed, as expected.
As for the Microsoft tool: I set one breakpoint in the opening curly bracket, and one in the ending curly bracket; I then take a snapshot at each. The breakpoint at the second curly bracket is reached after the execution of the return statement. The result of this is bamboozling: there is one more allocation documented in the second snapshot when compared to the first, and that allocation is that of the integer pointed at by uptr from my code.
I had also attempted to walk step-by-step with F11 (Step Into) into the post-main() parts of the code, all the way to the exit call that terminates the program (tried stepping into that one too but F11 just caused the end of execution), and take snapshots at each step: that leftover allocation remains in each of them.
I had lastly attempted to add the following line right before return 0;:
delete uptr.release();
This made no difference on the Valgrind front (still no leaks/errors/warnings), but solved the extra allocation "issue" (maybe just a misunderstanding on my part) on the VS front.
Now to my actual question:
Why is this happening? Is this actually an issue, or am I just misunderstanding something?
To rephrase: does this extra allocation (I'll add a picture below to demonstrate) imply unreleased dynamically-allocated memory, of the kind that would occur if I used new without deleteing? And if so, then is it because of something I did wrong?
Depicted here are the diagnostic tool snapshots:

And clicking on the "+1" to reveal more information shows that it is indeed the integer allocated within the make_unique call.