Dtruss ne montre pas les appels mmap/sbrk ?

Question

J'ai récemment décidé d'en apprendre davantage sur la programmation des systèmes, et j'ai pensé qu'il serait utile de voir ce que mon code est en fait sous le capot.

Pour ce faire, j'ai écrit une courte classe LinkedList en C++ et j'ai décidé de la tracer en utilisant dtruss (lire : dtrace).

Je m'attendais à ce que toutes les instructions qui étendent le tas (par exemple en utilisant la fonction new ou l'instanciation d'objets de type LinkedList) invoquerait la fonction mmap o sbrk / break les appels système. Ce n'était pas le cas !

En fait, courir dtruss avec l'interrupteur -s, je ne vois pas cualquier Les appels système sont invoqués à partir de mon LinkedList::Add fonction ! En testant, je suis certain que des éléments sont ajoutés.

Quelqu'un peut-il expliquer pourquoi je ne vois pas de références à mmap / sbrk dans ma sortie dtruss ?

Des points bonus si quelqu'un pouvait expliquer le but de mprotect y madvise .

J'ai inclus ma classe LinkedList, main.cpp, et le résultat de dtruss ci-dessous.

Merci !

sortie du dtruss

SYSCALL(args)        = return
Created new LinkedList
Created new LinkedList
Destroyed a LinkedList
open("/dev/dtracehelper\0", 0x2, 0xFFFFFFFFE3236D70)         = 3 0
ioctl(0x3, 0x80086804, 0x7FFEE3236CD0)       = 0 0
close(0x3)       = 0 0
access("/AppleInternal/XBS/.isChrooted\0", 0x0, 0x0)         = -1 Err#2
thread_selfid(0x0, 0x0, 0x0)         = 198178 0
bsdthread_register(0x7FFF5BAB5C50, 0x7FFF5BAB5C40, 0x2000)       = 1073742047 0
issetugid(0x0, 0x0, 0x0)         = 0 0
mprotect(0x10C9D0000, 0x1000, 0x0)       = 0 0
mprotect(0x10C9D5000, 0x1000, 0x0)       = 0 0
mprotect(0x10C9D6000, 0x1000, 0x0)       = 0 0
mprotect(0x10C9DB000, 0x1000, 0x0)       = 0 0
mprotect(0x10C9CE000, 0x88, 0x1)         = 0 0
mprotect(0x10C9DC000, 0x1000, 0x1)       = 0 0
mprotect(0x10C9CE000, 0x88, 0x3)         = 0 0
mprotect(0x10C9CE000, 0x88, 0x1)         = 0 0
getpid(0x0, 0x0, 0x0)        = 1698 0
stat64("/AppleInternal/XBS/.isChrooted\0", 0x7FFEE32362E8, 0x0)      = -1 Err#2
stat64("/AppleInternal\0", 0x7FFEE3236380, 0x0)      = -1 Err#2
csops(0x6A2, 0x7, 0x7FFEE3235E20)        = -1 Err#22
sysctl([CTL_KERN, 14, 1, 1698, 0, 0] (4), 0x7FFEE3235F68, 0x7FFEE3235F60, 0x0, 0x0)      = 0 0
csops(0x6A2, 0x7, 0x7FFEE3235710)        = -1 Err#22
getrlimit(0x1008, 0x7FFEE32374F0, 0x0)       = 0 0
fstat64(0x1, 0x7FFEE3237508, 0x0)        = 0 0
ioctl(0x1, 0x4004667A, 0x7FFEE3237554)       = 0 0
write_nocancel(0x1, "Created new LinkedList\n\0", 0x17)      = 23 0
write_nocancel(0x1, "Created new LinkedList\n\0", 0x17)      = 23 0
write_nocancel(0x1, "Destroyed a LinkedList\n\0", 0x17)      = 23 0

LinkedList.cpp

#include <iostream>
#include "LinkedList.h"

using namespace std;

LinkedList::LinkedList() {
    this->length = 0;
    this->head = NULL;
    this->tail = NULL;
    cout << "Created new LinkedList" << endl;
}

LinkedList::~LinkedList() {
    Node* curr;
    Node* temp;
    curr = this->head;

    while ( curr ) {
        temp = curr;
        curr = curr->next;
        delete temp;
    }

    cout << "Destroyed a LinkedList" << endl;
}

void LinkedList::Add(int v) {

    Node* n = new Node();
    n->val = v;
    n->next = NULL;

    if (!this->head) {
        this->head = n;
        this->tail = n;
    } else {
        this->tail->next = n;
        this->tail = n;
    }    
}

main.cpp

#include <iostream>
#include "LinkedList.h"

using namespace std;

int main() {

    LinkedList l; // You should require a heap increase, right?

    LinkedList* ll = new LinkedList(); // Surely you require more heap!

    for (int i=0; i<1000; i++) 
        l.Add(i);

    return 0;

}

Answer 1

J'ai découvert que Mac OS n'utilise pas sbrk/brk/break() pour la gestion de la mémoire comme la plupart des UNIX/Linux. Fondamentalement, il utilise le noyau Mach qu'Apple a hérité de NeXT, donc les appels à la mémoire vont être mpadvise(2) y mprotect(2) qui offrent un contrôle du grain plus fin que sbrk() .

Extrait de "Mac OS X and iOS Internals" de Jonathan Levin :

Donc, pour interpréter vos allocations de mémoire, vous devez connaître le mprotect(2) des arguments de la sys/mman.h en-tête.

#define PROT_NONE       0x00    /* [MC2] no permissions */
#define PROT_READ       0x01    /* [MC2] pages can be read */
#define PROT_WRITE      0x02    /* [MC2] pages can be written */
#define PROT_EXEC       0x04    /* [MC2] pages can be executed */
....

Et donc vos appels système impliqueraient :

mprotect(0x10C9D0000, 0x1000, 0x0)       = 0 0
mprotect(0x10C9D5000, 0x1000, 0x0)       = 0 0
mprotect(0x10C9D6000, 0x1000, 0x0)       = 0 0
mprotect(0x10C9DB000, 0x1000, 0x0)       = 0 0
mprotect(0x10C9CE000, 0x88, 0x1)         = 0 0  <-- Allow reads starting at 0x10C9CE000 for 136 bytes
mprotect(0x10C9DC000, 0x1000, 0x1)       = 0 0
mprotect(0x10C9CE000, 0x88, 0x3)         = 0 0  <-- Allow reads and writes starting at 0x10C9CE000 for 136 bytes
mprotect(0x10C9CE000, 0x88, 0x1)         = 0 0

Concernant mmap(2) Sur les systèmes Linux, il est utilisé pour mapper le code objet des bibliothèques partagées, mais pas pour les fonctions suivantes malloc/free o new/delete .

Références :

• Livre blanc Gestionnaire de tas extensible par l'utilisateur pour les mémoires hétérogènes et les politiques de mémoire mixte
• Internes de Mac OS X et iOS
• "Mac OS X Internals" : A Systems Approach" par Amit Singh.