C++/Windows: come segnalare un'eccezione di memoria esaurita (bad_alloc)?

Question

Attualmente sto lavorando su un sistema di segnalazione degli errori basato su eccezioni per le app MSVC++ (9.0) di Windows (ad esempio strutture & di tipo ereditarietà, stack di chiamate, segnalazione errori & registrazione e così via).

La mia domanda ora è: come segnalare correttamente & registrare un errore di memoria insufficiente?

Quando si verifica questo errore, ad es. come bad_alloc lanciato dall'opzione new, potrebbero non esserci molte "funzioni" non disponibili, principalmente per quanto riguarda l'ulteriore allocazione di memoria. Normalmente, passerei l'eccezione all'applicazione se è stata lanciata in una lib, quindi utilizzando le finestre di messaggio e i file di log degli errori per segnalare e loggare. Un altro modo (principalmente per i servizi) è utilizzare il registro eventi di Windows.
Il problema principale che ho è quello di assemblare un messaggio di errore. Per fornire alcune informazioni di errore, vorrei definire un messaggio di errore statico (potrebbe essere una stringa letterale, una voce migliore in un file di messaggio, quindi utilizzare FormatMessage) e includere alcune informazioni di runtime come uno stack di chiamate.
Le funzioni/metodi necessari per tale uso sia

• STL (std::string, std::stringstream, std::ofstream)
• CRT (swprintf_s, fwrite)
• o Win32 API (StackWalk64, MessageBox, FormatMessage, ReportEvent, WriteFile)

Oltre ad essere documentata sul MSDN, tutti hanno più (Win32) o meno (STL) closed source in Windows, quindi non so come si comportano in caso di problemi di memoria insufficiente.

solo per dimostrare ci potrebbero essere dei problemi, ho scritto una piccola applicazione banale provocando una bad_alloc:

int main() 
{ 
    InitErrorReporter(); 

    try 
    { 
     for(int i = 0; i < 0xFFFFFFFF; i++) 
     { 
      for(int j = 0; j < 0xFFFFFFFF; j++) 
      { 
       char* p = new char; 
      } 
     } 
    }catch(bad_alloc& e_b) 
    { 
     ReportError(e_b); 
    } 

    DeinitErrorReporter(); 

    return 0; 
} 

Ran due istanze w/o debugger (in config di uscita, VS 2008), ma "non è successo niente ", ovvero nessun codice di errore da ReportEvent o WriteFile utilizzato internamente nella segnalazione degli errori. Quindi, ha lanciato un'istanza con e un debugger e gli ha consentito di provare a segnalare gli errori uno dopo l'altro utilizzando un punto di interruzione nella riga ReportError. Questo ha funzionato bene per l'istanza con il debugger allegato (riportato correttamente & ha registrato l'errore, anche utilizzando LocalAlloc senza problemi)! Ma il taskman ha mostrato uno strano comportamento, in cui c'è molta memoria liberata prima che l'app esca, suppongo quando viene lanciata l'eccezione.

Si prega di prendere in considerazione ci possono essere più di un processo [modifica] e più di un thread [/ modifica] consumano molta memoria, così liberando spazio pre-assegnati heap non è una soluzione sicura per evitare un ambiente di memoria insufficiente per il processo che vuole segnalare l'errore.

Grazie in anticipo!

Answer 1

• pre-allocare il buffer (s) è necessario
• collegamento staticamente e utilizzare _beginthreadex invece di CreateThread (in caso contrario, funzioni CRT possono fallire) - OPPURE - attuare la stringa concat/i2a te
• Usa MessageBox (MB_SYSTEMMODAL | MB_OK) MSDN menziona questo per la segnalazione di condizioni di OOM (e alcuni SM blogger ha descritto questo comportamento come previsto: la finestra di messaggio non allocare la memoria.)

registrazione è più difficile, per lo meno, il il file di registro deve essere già aperto.

Probabilmente il migliore con FILE_FLAG_NO_BUFFERING e FILE_FLAG_WRITE_THROUGH, per evitare qualsiasi tentativo di buffering. Il primo richiede che le scritture ei buffer di memoria siano allineati al settore (ovvero è necessario interrogare GetDiskFreeSpace, allineare il buffer con quello e scrivere solo su offset di file "multipli di dimensione settore" e in blocchi multipli di dimensioni di settore. Non sono sicuro se sia necessario o utile, ma una OOM a livello di sistema in cui l'allocazione non riesce a effettuare l'allocazione.

Answer 2

"Liberare spazio heap pre-allocato ...". Questo era esattamente quello che pensavo leggendo la tua domanda. Ma penso che tu possa provarlo. Ogni processo ha il proprio spazio di memoria virtuale. Con altri processi che consumano molta memoria, questo potrebbe funzionare anche se tutto il computer funziona.

Answer 3

Considerare che potrebbe esserci più di un processo che consuma molta memoria, quindi liberare lo spazio di heap preassegnato non è una soluzione sicura per evitare un ambiente di memoria insufficiente per il processo che desidera segnalare l'errore.

In Windows (e in altri sistemi operativi moderni), ogni processo ha il proprio spazio indirizzo (noto anche come memoria) separato da ogni altro processo in esecuzione. E tutto ciò è separato dalla RAM letterale nella macchina. Il sistema operativo ha virtualizzato lo spazio di indirizzamento del processo lontano dalla RAM fisica.

In questo modo Windows è in grado di trasferire la memoria utilizzata dai processi nel file di paging sul disco rigido senza che questi processi abbiano alcuna conoscenza di ciò che è accaduto.

Questo è anche il modo in cui un singolo processo può allocare più memoria rispetto alla RAM fisica della macchina e ancora funzionare. Ad esempio, un programma in esecuzione su una macchina con 512 MB di RAM potrebbe comunque allocare 1 GB di memoria. Windows non riusciva a mantenere tutto nella RAM contemporaneamente e parte del file di paging. Ma il programma non lo saprebbe.

Quindi, di conseguenza, se un processo alloca memoria, non causa un altro processo con meno memoria su cui lavorare. Ogni processo è separato.

Ogni processo deve solo preoccuparsi di se stesso. E quindi l'idea di liberare una porzione di memoria pre-allocata è in realtà molto valida.

Answer 4

Non è possibile utilizzare le funzioni CRT o MessageBox per gestire OOM poiché potrebbero richiedere memoria, come descritto. L'unica cosa veramente sicura che puoi fare è allocare un blocco di memoria all'avvio in cui puoi scrivere informazioni e aprire un handle in un file o in una pipe, quindi scrivere WriteFile quando esci da OOM.