usare fclose to pipe of popen è un bug serio?

Question

Alcuni mesi fa scrivo un'applicazione CGI per Linux che utilizza popen() per leggere l'output di un comando, quindi chiudo la pipa con fclose().

Ora, ho letto che per tubi stretti è necessario utilizzare pclose().

Il manuale dice:

Il valore restituito da popen() è un flusso normale standard di I/O in tutti gli aspetti salvo che esso deve essere chiuso con pclose() piuttosto che fclose(3).

Il mio codice è simile a questo:

if ((NULL != (f = popen(command.value, "r")))) { 
    //do something 
    fclose(f); 
} 

La mia domanda è:

Il mio errore ha un problema di sicurezza? Il programma è attualmente in produzione. Nei test non fa niente. E 'davvero necessario, patch usando invece fclose()? Nota: apro il PIPE solo una volta nel programma.

Oggi, nella mia casa locale faccio un po 'di test e fclose() e pclose() non tornare EOF che indica il fallimento.

Answer 1

Se si utilizza fclose sulla pipe, si avranno perdite di descrittori di file, poiché fclose non libererà il puntatore del file nel kernel (che viene creato quando si crea la pipe dal momento che è un file).

Mentre i test finora non hanno mostrato problemi, esegui il tuo programma 3000 volte (o come mai molti descrittori di file sono consentiti, verso l'alto di un int credo) e guarda quando non sarai più in grado di creare pipe .

Answer 2

Secondo this thread, utilizzando fclose anziché pclose significa che il processo all'altra estremità del tubo non viene raccolto, così rimane zombied.

Answer 3

Ho appena scoperto (dopo 10 anni) che stavo usando erroneamente fclose per alcune chiamate popen, in esecuzione sul server Windows 2008. Ha funzionato (cioè non si è bloccato), e non mi importava del codice di ritorno su quelle chiamate comunque.

Ma avevo bisogno del codice di ritorno dell'ultimo flusso popen e la chiusura è stata eseguita correttamente con pclose.

Ha lo strano effetto di restituire un codice di 0 errore (forse raccogliendo il codice di ritorno della prima non pclosed processo), anche se il comando non è riuscito, creando uno strano bug nel codice, che avrebbero potuto portare a errori catastrofici perché il chiamante pensa che il comando ha funzionato.

Quindi non è solo una questione di descrittori perdite, si può introdurre bug funzionali nel codice, (anche se l'applicazione viene eseguita per alcuni secondi e non si preoccupano di descrittori perdite)