Verwendet Malloc den Heap nur, wenn der angeforderte Speicherplatz groß ist?

Wann immer Sie die Speicherzuweisung von Prozessen untersuchen, sehen Sie sie normalerweise so umrissen:

So weit, ist es gut.

Aber dann haben Sie den Systemaufruf sbrk(), der es dem Programm ermöglicht, die Obergrenze von its zu ändern Datenbereich, und es kann auch verwendet werden, um einfach mit sbrk(0) zu überprüfen, wo diese Grenze liegt. Mit dieser Funktion fand ich die folgenden Muster:

Muster 1 – Kleiner Malloc

Ich führe das folgende Programm auf meinem Linux-Rechner aus:

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

int globalVar;

int main(){
        int localVar;
        int *ptr;

        printf("localVar address (i.e., stack) = %p\n",&localVar);
        printf("globalVar address (i.e., data section) = %p\n",&globalVar);
        printf("Limit of data section = %p\n",sbrk(0));

        ptr = malloc(sizeof(int)*1000);

        printf("ptr address (should be on stack)= %p\n",&ptr);
        printf("ptr points to: %p\n",ptr);
        printf("Limit of data section after malloc= %p\n",sbrk(0));

        return 0;
}

Und die Ausgabe ist die folgende:

localVar address (i.e., stack) = 0xbfe34058
globalVar address (i.e., data section) = 0x804a024
Limit of data section = 0x91d9000
ptr address (should be on stack)= 0xbfe3405c
ptr points to: 0x91d9008
Limit of data section after malloc= 0x91fa000

Wie Sie sehen können, lag der zugewiesene Speicherbereich direkt über der alten Datenabschnittsgrenze, und nach dem Malloc wurde diese Grenze nach oben verschoben, sodass sich die zugewiesene Region tatsächlich innerhalb des neuen Datenabschnitts befindet.

Frage 1: Bedeutet dies, dass kleine Mallocs Speicher im Datenabschnitt zuweisen und den Heap überhaupt nicht verwenden?

Muster 2 – Großer Malloc

Wenn Sie die angeforderte Speichergröße in Zeile 15 erhöhen:

ptr = malloc(sizeof(int)*100000);

Sie erhalten nun die folgende Ausgabe:

localVar address (i.e., stack) = 0xbf93ba68
globalVar address (i.e., data section) = 0x804a024
Limit of data section = 0x8b16000
ptr address (should be on stack)= 0xbf93ba6c
ptr points to: 0xb750b008
Limit of data section after malloc= 0x8b16000

Wie Sie hier sehen können, hat sich die Grenze des Datenabschnitts nicht geändert, und stattdessen befindet sich der zugewiesene Speicherbereich in der Mitte des Lückenabschnitts zwischen dem Datenabschnitt und dem Stapel.

Frage 2: Nutzt der große Malloc tatsächlich den Heap?

Frage 3: Irgendeine Erklärung für dieses Verhalten? Ich finde es ein bisschen unsicher, denn beim ersten Beispiel (kleines Malloc) können Sie auch nach dem Freigeben des zugewiesenen Speichers den Zeiger verwenden und diesen Speicher verwenden, ohne einen Seg-Fehler zu erhalten, da er sich in Ihren Daten befindet Abschnitt, und dies könnte zu schwer zu erkennenden Fehlern führen.

Update mit Spezifikationen: Ubuntu 12.04, 32-Bit, gcc-Version 4.6.3, Linux-Kernel 3.2.0-54-generic-pae.

Update 2: Rodrigos Antwort unten löste dieses Rätsel. Dieser Wikipedia-Link hat auch geholfen.

Zunächst einmal ist die einzige Möglichkeit, absolut sicher zu sein, was passiert, den Quellcode von zu lesen malloc. Oder noch besser, gehen Sie es mit dem Debugger durch.

Aber wie auch immer, hier ist mein Verständnis dieser Dinge:

1. Der Systemaufruf sbrk() wird verwendet, um die Größe des Datenabschnitts zu erhöhen, in Ordnung. Normalerweise werden Sie es nicht direkt anrufen, aber es wird von der angerufen Implementierung von malloc() um den für den Heap verfügbaren Speicher zu erhöhen.
2. Die Funktion malloc() weist keinen Speicher vom Betriebssystem zu. Es teilt den Datenabschnitt einfach in Teile auf und weist diese Teile denjenigen zu, die sie benötigen. Sie nutzen free() um ein Stück als unbenutzt und für eine Neuzuweisung verfügbar zu markieren.
3. Punkt 2 ist eine zu starke Vereinfachung. Zumindest die GCC-Implementierung für große Blöcke, malloc() ordnet sie mit zu mmap() mit privaten, nicht dateigestützten Optionen. Somit liegen diese Blöcke außerhalb des Datensegments. Natürlich anrufen free() in einem solchen Block wird anrufen munmap().

Was genau ist ein großer Block hängt von vielen Details ab. Sehen man mallopt für die blutigen Details.

Daraus können Sie erraten, was passiert, wenn Sie auf den freien Speicher zugreifen:

1. Wenn der Block war klein, der Speicher ist immer noch da, wenn Sie also lesen, passiert nichts. Wenn Sie darauf schreiben, können Sie die internen Heap-Strukturen beschädigen, oder es wurde möglicherweise wiederverwendet, und Sie können jede zufällige Struktur beschädigen.
2. Wenn der Block groß war, wurde der Speicher nicht zugeordnet, sodass jeder Zugriff zu einem Segmentierungsfehler führt. Es sei denn, die unwahrscheinliche Situation, dass in der Zwischenzeit ein weiterer großer Block zugewiesen wird (oder ein anderer Thread aufruft mmap() und der gleiche Adressbereich verwendet werden.

Klärung

Der Begriff Datenbereich wird je nach Kontext mit zwei verschiedenen Bedeutungen verwendet.

1. Das .data Abschnitt der ausführbaren Datei (Linker-Sicht). Es kann auch beinhalten .bss oder auch .rdata. Für das Betriebssystem bedeutet das nichts, es bildet nur Teile des Programms im Speicher ab, ohne Rücksicht darauf, was es außer den Flags enthält (schreibgeschützt, ausführbar …).
2. Das Haufendieser Speicherblock, den jeder Prozess hat, der nicht aus der ausführbaren Datei gelesen wird und der mit erweitert werden kann sbrk().

Sie können das mit dem folgenden Befehl sehen, der das Speicherlayout eines einfachen Programms ausgibt (cat):

$ cat /proc/self/maps
08048000-08053000 r-xp 00000000 00:0f 1821106    /usr/bin/cat
08053000-08054000 r--p 0000a000 00:0f 1821106    /usr/bin/cat
08054000-08055000 rw-p 0000b000 00:0f 1821106    /usr/bin/cat
09152000-09173000 rw-p 00000000 00:00 0          [heap]
b73df000-b75a5000 r--p 00000000 00:0f 2241249    /usr/lib/locale/locale-archive
b75a5000-b75a6000 rw-p 00000000 00:00 0 
b75a6000-b774f000 r-xp 00000000 00:0f 2240939    /usr/lib/libc-2.18.so
b774f000-b7750000 ---p 001a9000 00:0f 2240939    /usr/lib/libc-2.18.so
b7750000-b7752000 r--p 001a9000 00:0f 2240939    /usr/lib/libc-2.18.so
b7752000-b7753000 rw-p 001ab000 00:0f 2240939    /usr/lib/libc-2.18.so
b7753000-b7756000 rw-p 00000000 00:00 0 
b7781000-b7782000 rw-p 00000000 00:00 0 
b7782000-b7783000 r-xp 00000000 00:00 0          [vdso]
b7783000-b77a3000 r-xp 00000000 00:0f 2240927    /usr/lib/ld-2.18.so
b77a3000-b77a4000 r--p 0001f000 00:0f 2240927    /usr/lib/ld-2.18.so
b77a4000-b77a5000 rw-p 00020000 00:0f 2240927    /usr/lib/ld-2.18.so
bfba0000-bfbc1000 rw-p 00000000 00:00 0          [stack]

Die erste Zeile ist der ausführbare Code (.text Sektion).

Die zweite Zeile sind die schreibgeschützten Daten (.rdata Abschnitt) und einige andere schreibgeschützte Abschnitte.

Die dritte Zeile ist die .data + .bss und einige andere beschreibbare Abschnitte.

Die vierte Zeile ist der Haufen!

Die nächsten Zeilen, die mit einem Namen, sind speicherabgebildete Dateien oder gemeinsam genutzte Objekte. Diejenigen ohne Namen sind wahrscheinlich große Speicherblöcke (oder vielleicht private anonyme mmaps, sie sind unmöglich zu unterscheiden).

Die letzte Zeile ist der Stack!