Fork nach Malloc im Elternteil … muss der Kindprozess es befreien?

Antworten auf Fragen im Kopf: Ja, das ist für die Schule. Nein, ich kann dafür keine Threads verwenden. Und ja, ich suchte nach einer Antwort und einige Leute sagten “ja” und andere sagten “nein”. Ich überprüfe auch die Fakten meines Professors, weil ich nicht unfairerweise Punkte verlieren möchte, wenn jemand anderes es benoten würde und sie verlangen, dass dies “korrigiert” wird.

Betrachten Sie dieses einfache Programm für c auf dem Linux-System. Ich mallociere etwas und forke dann. Ich habe mein Projekt auf das genaue Problem reduziert:

#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include <sys/wait.h>
#include <sys/types.h>

int main( void )
{
    char * args [] = { "someinvalidcommand", NULL };

    // malloc before the fork (happens in parent process)
    char * something = (char *)malloc(sizeof(char));

    pid_t child_pid = fork();

    // are there now two things that need to be freed:
    // one for each process?

    if(child_pid == 0) // child process
    {
        //free(something); // is this needed?

        // execvp (it won't return if succeeded)
        if(execvp(args[0], args) < 0)
        {
            // or do I only need to free it here?
            printf("%s: No such file or directory\n", args[0]);
            /*
             * EDIT: Calling it here seems to fix the issue.  It turns out
             * that the system calls were the ones with the "still reachable"
             * errors, so I guess it's not all that important that the
             * memory be freed.
             *
             * free(something)
             */
            _exit(1);
        }
    }
    else // parent process
    {
        int status;
        while(wait(&status) != child_pid);
        if(status != 0)
        {
            printf("command status: %i\n", WEXITSTATUS(status));
        }
    }

    free(something);
    return 0;
}

Hier ist es jetzt etwas verwirrend. Meines Wissens erstellt Fork eine exakte Kopie des übergeordneten Prozesses in diesem bestimmten Zustand (einschließlich Text, Daten usw.). Ich habe irgendwo gelesen, dass dies alles enthält, was malloc’d ist (also den Haufen). Ich habe jedoch an anderer Stelle gelesen, dass dies aufgrund von etwas namens “Copy-on-Write” nicht der Fall ist, aber dann habe ich an anderer Stelle gelesen, dass “Copy-on-Write” einfach eine Optimierung ist, die transparent und irrelevant ist. Aber was ich dann am sinnvollsten gelesen habe, war, dass es, da es sich um eine KOPIE handelt, sein eigenes, na ja … alles hat.

Aber dann erinnere ich mich, dass bei Verwendung von fork() alles, was mallociert wurde, dieselbe Speicheradresse enthält, also zeigen Eltern und Kind auf dasselbe? Muss ich auch beim Kind Ressourcen freisetzen? Werden nur die Pointer kopiert oder werden auch die Daten kopiert, auf die die Pointer zeigen?

Ich habe valgrind verwendet und wenn der untergeordnete Prozess beendet wird, beschwert er sich einfach, dass der gesamte Speicher noch erreichbar ist. Wie genau ist es “noch erreichbar”? Beantwortet die Tatsache, dass es “immer noch erreichbar” ist, meine Frage und sagt es, dass Elternteil und Kind auf dasselbe zeigen und der Elternteil der einzige ist, der für die Freigabe des Speichers verantwortlich ist?

In Ermangelung der Anrufe an die exec Familie, du musst free() es. Parent und Child zeigen nicht auf dasselbe, da sie separate Prozesse sind und nicht denselben Adressraum teilen. Stellen Sie sich vor, was unter der Alternative passieren würde, wenn der Elternteil free()d es zum Beispiel, und dann versuchte das Kind, darauf zuzugreifen.

Wenn Sie so etwas anrufen execvp()dann wird, wie tmyklebu erwähnt, Ihr Prozess einfach gelöscht, und Sie müssen nichts tun.

“Noch erreichbar” bedeutet, dass Sie immer noch einen Verweis darauf haben, aber Sie haben keinen free()d es noch. Da bekommt Ihr ganzes Gedächtnis free()d bei der Beendigung sowieso, ist dies manchmal kein so großes Problem, verglichen mit einem tatsächlichen Speicherleck, bei dem Sie dauerhaft den Überblick über den zugewiesenen Speicher verlieren. Valgrinds FAQ selbst sagt, dass “Ihr Programm wahrscheinlich in Ordnung ist – es hat keinen Speicher freigegeben, den es haben könnte. Dies ist ziemlich üblich und oft vernünftig.” Die Meinungen zu diesem Thema gehen auseinander – einige Leute sagen, es sei eine gute Form, alles explizit free() zu machen, andere sagen, es sei eine sinnlose Verschwendung von Ressourcen, das zu tun, was die Programmbeendigung von selbst für Sie tun wird.

execvp löscht Ihren Adressraum, sodass der zugewiesene Speicher weg ist.

_exit beendet Ihr Programm, was bedeutet, dass der zugewiesene Speicher weg ist.

Sie müssen dies nicht explizit tun free irgendetwas im untergeordneten Prozess; Tatsächlich ist es (wegen der COW-Sache) keine gute Idee, dies zu tun.

Berufung free Vor execvp ist sinnlos, und es macht Ihren Code tatsächlich weniger wiederverwendbar/portabel, da es nicht gültig ist, ihn aufzurufen free beim Kind danach fork wenn der aufrufende Prozess multithreaded ist.