This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(166.4, 19%, 26%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EOT%3C/text%3E%3C/svg%3E)
I have a very simple program
int main(void)
{ double* myVect = new double[10000000];
wait(2); // wait for 2 seconds
delete[] myVect;
wait(2);
return 0;
}
I execute this program in Debug mode, put a breakpoint on "return 0" and look at the diagnostic tools (sorry I've a French version of Visual Studio 2022).
Why the memory isn't released?
Maybe this picture (and 147 Mo) does not correspond to the shown code.
@Viorel, Notwithstanding the memory amounts shown initially the diagnostics displayed to me looked very similar to the Questioner's image. I suspect its not indicative of a memory problem but relates to timing and presentation for the diagnostic session graph.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(262.40000000000003, 13%, 35%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EDR%3C/text%3E%3C/svg%3E)
10,000,000 doubles should only be around 87MiB, not 147. There is also the problem that not knowing the project type doesn't help, since Visual Studio can report interesting things in the memory that it shows.
To give one example, this is the memory shown for an almost blank WinUI 3 application compared to what is reported in Task Manager.
What is reported in Visual Studio seems to be a mix of the working set and dedicated GPU memory this means that the memory shown can be misleading.
But explicitly using the Sleep function, I don't really see any issue.
I increased the interval between allocation, free and termination to make memory changes more visible in the diagnostic session. I also took snapshots before allocation, before free and after free. This is what was displayed.
So the memory is being freed when delete is called but the display you are looking at doesn't clearly reflect the activity due to the short lag between free and program termination.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(211.20000000000002, 61%, 30%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EBS%3C/text%3E%3C/svg%3E)
when you ask for an allocation that is larger than the heap has free memory, it requests more process memory form the O/S, thus going the process memory size. when you release memory to the heap (delete), the deleted memory is marked as free, but not returned to the O/S, so the process memory size does not change. You do have lots of free heap memory.