Rilevamento dello stack pieno

Question

Durante la scrittura del codice C++ ho appreso che utilizzare lo stack per archiviare la memoria è una buona idea.

Ma di recente mi sono imbattuto in un problema:

ho avuto un esperimento che aveva il codice che si presentava così:

void fun(const unsigned int N) { 
    float data_1[N*N]; 
    float data_2[N*N]; 

    /* Do magic */ 
} 

Il codice exploted con un guasto seqmentation a caso, e non avevo idea perché.

Si è scoperto che il problema era che stavo cercando di memorizzare cose che erano grandi sul mio stack, c'è un modo per rilevarlo? O almeno a scoprire che è andato storto?

Answer 1

float data_1[N*N]; 
float data_2[N*N]; 

Questi sono array di lunghezza variabile (VLA), come N non è un'espressione costante. La constanza nel parametro garantisce solo che N sia di sola lettura. Non dice al compilatore che N è un'espressione costante.

VLA sono consentiti solo in C99; in altre versioni di C e tutte le versioni di C++ non sono consentite. Tuttavia, alcuni compilatori forniscono VLA come funzionalità di estensione del compilatore. Se stai compilando con GCC, quindi prova a usare l'opzione -pedantic, ti dirà che non è permesso.

Ora, perché il programma dà segfault, probabilmente a causa della stack-overflow a causa di grande valore N * N:

---

considerare l'utilizzo di std::vector come:

#include <vector> 

void fun(const unsigned int N) 
{ 
    std::vector<float> data_1(N*N); 
    std::vector<float> data_2(N*N); 

    //your code 
} 

Answer 2

Prova utilizzando invece funzioni come malloc. Restituirà null esplicitamente, se non è riuscito a trovare un blocco di memoria della dimensione richiesta.

Naturalmente, in tal caso, non dimenticare di liberare questa memoria alla fine della funzione, dopo aver terminato.

Inoltre, è possibile controllare le impostazioni del compilatore, con quale limite di memoria dello stack genera i file binari.

Answer 3

Uno dei motivi per cui le persone dicono che è meglio utilizzare lo stack anziché la memoria heap può essere dovuto al fatto che le variabili allocate in cima allo stack verranno estratte automaticamente quando si lascia il corpo della funzione. Per archiviare grandi blocchi di informazioni è usuale utilizzare la memoria heap e altre strutture dati come elenchi o alberi collegati. Anche i ricordi allocati nello stack sono limitati e molto meno di quanto è possibile allocare nello spazio heap. Penso che sia meglio gestire l'allocazione della memoria e rilasciarlo con più attenzione invece di provare a utilizzare lo stack per archiviare i big data.

È possibile utilizzare il framework che gestisce le allocazioni di memoria. Puoi anche usare VDL per controllare le perdite di memoria e i ricordi che non vengono rilasciati.

Answer 4

c'è un modo per rilevarlo?

No, in generale.

Le dimensioni dello stack dipendono dalla piattaforma.In genere, il sistema operativo decide la dimensione della pila. Quindi puoi controllare il tuo sistema operativo (ulimit -s su linux) per vedere quanta memoria di stack assegna al tuo programma.

Se il compilatore supporta stackavail(), è possibile verificarlo. È meglio utilizzare la memoria allocata su heap in situazioni in cui non si è certi di superare il limite di stack.

Answer 5

È estremamente difficile rilevare che lo stack è pieno e non è affatto portatile. Uno dei maggiori problemi è che i frame stack sono di dimensioni variabili (specialmente quando si usano array di lunghezza variabile, che sono in realtà solo un modo più standard di fare ciò che le persone facevano prima con alloca()) quindi non si possono usare semplici proxy come il numero di frame dello stack.

Uno dei metodi più semplici che è principalmente portatile è quello di mettere una variabile (probabilmente di tipo char modo che un puntatore ad essa è un char*) ad una profondità nota in pila e quindi misurare la distanza da tale puntare a una variabile (dello stesso tipo) nel frame dello stack corrente con l'aritmetica del puntatore semplice. Aggiungi una stima di quanto spazio stai per allocare, e puoi avere una buona idea se lo stack sta per esplodere su di te. I problemi con questo sono che non si conosce la direzione in cui cresce lo stack (no, non crescono tutti nella stessa direzione!) E l'elaborazione della dimensione dello spazio di stack è di per sé piuttosto disordinata (è possibile provare cose come i limiti del sistema, ma sono davvero piuttosto scomodi). Inoltre il fattore di hacking è molto alto.

L'altro trucco che ho visto usare a 32 bit solo per Windows è stato quello di cercare di alloca() sufficiente spazio e gestire l'eccezione sistema che si verificherebbe se ci fosse spazio sufficiente.

int have_enough_stack_space(void) { 
    int enough_space = 0; 

    __try {   /* Yes, that's got a double-underscore. */ 
     alloca(SOME_VALUE_THAT_MEANS_ENOUGH_SPACE); 
     enough_space = 1; 
    } __except (EXCEPTION_EXECUTE_HANDLER) {} 

    return enough_space; 
} 

Questo codice è molto non portabile (ad esempio, non contate su di esso a lavorare su Windows a 64 bit) e la costruzione con gcc anziani richiede qualche brutta assembler inline, invece! La gestione strutturata delle eccezioni (di cui questo è un uso) è tra le più nere delle arti nere su Windows. (E non return dall'interno del costrutto __try.)