Microsoft nie zwalnia pamięci

Proszę Państwa, Microsoft udostępniając API do sprawdzani stanu pamięci alokuje coś w RAM za pierwszym razem i tego nie zwalnia

Pierwszy wynik jest różny od następnych.

Za pomocą tego API możesz sprawdzić, co się wydarzyło podczas wywołania GetProcessMemoryInfo.
System — z tego, co widać — dodał 10 stron pamięci 4096‐bajtowych. Może na stosie.

To jest nieistotny duperel. Nie ma co się tym przejmować.

Prawda, co to za problem wyciek pamięci, najwyżej się system zrestartuje raz albo codziennie

aoeuidhtn napisał(a):

Prawda, co to za problem wyciek pamięci, najwyżej się system zrestartuje raz albo codziennie

To zależy. Jeżeli to jest jeden raz w całkowitym czasie trwania procesu (np. kolejne uzycie tej samej funkcji nie generuje nowych wycieków), to żaden problem, ale jeżeli co jakiś czas jest nowy wyciek (np. powstający każdorazowo przy wywołaniu określonej funkcji WinAPI), to warto się tym zająć.

Możliwe, że ta pamięć jest potrzebna do wyświetlenia tekstu w konsoli.

Mi to wygląda na przejaw lazy evaluation.
Pierwszy call po jakiejś funkcji prostu oddaje stan pamięci przed stworzeniem jakiś danych, czegoś co sama funkcja rezerwuje sobie na przyszłość.
Drugi call oddaje stan już po zakończeniu pierwszego wywołania, ale nic nowego nie jest rezerwowane.
Przy kolejnych wywołaniach nic się już nie zmienia.
Przykładowo sama funkcja printf może mieć zaimplementowane coś takiego i to by wyjaśniało to zachowanie najlepiej.

BTW chciałem to przetestować na swojej maszynie, ale nie chce mis ie przepisywać z obrazka, a johnny_Be_good zignorował napomnienie, żeby nie wstawiać kodu i logów jako obrazki.
Po rocznej obecności na forum johnny_Be_good powinien już wiedzieć takie rzeczy.
Swoją drogą nie rozumiem tej plagi. Skopiowanie tekstu jest łatwiejsze i szybsze dla wszystkich.

Czuje jakbym nagradzał złe zachowanie, ale niech będzie:

#include <stdio.h>
#include <stdlib.h>
#include <Windows.h>
#include <psapi.h>

PROCESS_MEMORY_COUNTERS_EX get_mem_data()
{
    PROCESS_MEMORY_COUNTERS_EX pmc;
    GetProcessMemoryInfo(GetCurrentProcess(), (PROCESS_MEMORY_COUNTERS*)&pmc, sizeof(pmc));
    return pmc;
}

void print_mem_data(PROCESS_MEMORY_COUNTERS_EX pmc)
{
    printf("PeakWorkingSetSize: %10zu bytes   WorkingSetSize: %10zu bytes\n", 
        pmc.PeakWorkingSetSize, pmc.WorkingSetSize
    );
}

#define N 4
int main() {
    PROCESS_MEMORY_COUNTERS_EX pmcs[N] = {};
    
    for (int i=0; i < N ; ++i) {
        pmcs[i] = get_mem_data();
    }
    
    for (int i=0; i < N ; ++i) {
        print_mem_data(pmcs[i]);
        pmcs[i] = get_mem_data();
    }
    printf("-----\n");
    
    for (int i=0; i < N ; ++i) {
        print_mem_data(pmcs[i]);
    }
}

C:\Users\marekR22\Downloads>cl memObserve.c /W4 /WX
Microsoft (R) C/C++ Optimizing Compiler Version 19.39.33523 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

memObserve.c
Microsoft (R) Incremental Linker Version 14.39.33523.0
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:memObserve.exe
memObserve.obj

C:\Users\marekR22\Downloads>memObserve.exe
PeakWorkingSetSize:    3129344 bytes   WorkingSetSize:    3125248 bytes
PeakWorkingSetSize:    3129344 bytes   WorkingSetSize:    3125248 bytes
PeakWorkingSetSize:    3129344 bytes   WorkingSetSize:    3125248 bytes
PeakWorkingSetSize:    3129344 bytes   WorkingSetSize:    3125248 bytes
-----
PeakWorkingSetSize:    3149824 bytes   WorkingSetSize:    3145728 bytes
PeakWorkingSetSize:    3149824 bytes   WorkingSetSize:    3145728 bytes
PeakWorkingSetSize:    3149824 bytes   WorkingSetSize:    3145728 bytes
PeakWorkingSetSize:    3149824 bytes   WorkingSetSize:    3145728 bytes

Czyli widać, że to printf robi jakieś lazy evaluation (pewnie rezerwuje bufor strumienia).

Marek się postarał.

Kiedyś miałem podobny przypadek.
Dosyć pieczołowicie przeszukiwałem alerty valgrinda i wyszło, ze xlib przy pierwszym podstawowej inizjalizacji, a następnie uwolnieniu "pod koniec" - "leakowało" jednorazowo jakieś małe ilości bajtów.

duperel.