L'indirizzo 0000000C è un indirizzo speciale?

Durante la programmazione a volte le cose si rompono. Hai fatto un errore e il tuo programma tenta di leggere da un indirizzo errato.

Una cosa che mi colpisce che spesso quelle eccezioni sono simili:

Access violation at address 012D37BC in module 'myprog.exe'. Read of address 0000000C.

Ora vedo molti log degli errori e ciò che mi colpisce è il: 0000000C. È un indirizzo "speciale"? Vedo altre violazioni dell'accesso con letture errate ma gli indirizzi sembrano casuali, ma questo continua a tornare in situazioni totalmente diverse.

00000000è un indirizzo speciale (il puntatore null). 0000000Cè proprio quello che ottieni quando aggiungi un offset di 12 al puntatore nullo, molto probabilmente perché qualcuno ha cercato di ottenere il zmembro di una struttura come quella sotto attraverso un puntatore che era effettivamente nullo.

struct Foo {
    int w, x, y; // or anything else that takes 12 bytes including padding
    // such as: uint64_t w; char x;
    // or: void *w; char padding[8];
    // all assuming an ordinary 32 bit x86 system
    int z;
}

In Windows è illegale dedurre l' intera prima e l'ultima pagina , in altre parole il primo o l'ultimo 64 KiB della memoria di processo (gli intervalli 0x00000000da 0x0000ffffe 0xffff0000verso 0xffffffffin un'applicazione a 32 bit).

Questo per intrappolare il comportamento indefinito di dereferenziare un puntatore o un indice null in un array null. E la dimensione della pagina è di 64 KiB, quindi Windows deve solo evitare che alla prima o all'ultima pagina venga assegnato un intervallo valido.

Ciò non protegge da puntatori non inizializzati che potrebbero avere qualsiasi valore (inclusi indirizzi validi).

Per quanto riguarda il motivo per cui 0x0Csembra più comune di 0x08(è davvero? Non lo so; e in quali tipi di applicazioni?), Ciò potrebbe avere a che fare con i puntatori della tabella dei metodi virtuali. Questo è davvero più di un commento (ipotesi di massa selvaggia :), ma è un po 'più grande, quindi ecco qui ... Se hai una classe con metodi virtuali, i suoi campi verranno spostati 0x04. Ad esempio, una classe che eredita da un'altra classe virtuale potrebbe avere un layout di memoria come questo:

0x00 - VMT pointer for parent
0x04 - Field 1 in parent
0x08 - VMT pointer for child
0x0C - Field 1 in child

È uno scenario comune o addirittura vicino? Non ne sono sicuro. Tuttavia, si noti che in un'applicazione a 64 bit, questo potrebbe spostarsi ancora più interessante verso il 0x0Cvalore:

0x00 - VMT parent
0x08 - Field 1 parent
0x0C - VMT child
0x14 - Field 2 child

Quindi in realtà ci sono molti casi in cui le applicazioni potrebbero avere una significativa sovrapposizione negli offset del puntatore null. Potrebbe essere il primo campo in una classe figlio o il suo puntatore alla tabella dei metodi virtuali, necessario ogni volta che si chiama un metodo virtuale su un'istanza, quindi se si chiama un metodo virtuale su un nullpuntatore, si otterrà una violazione di accesso sul relativo Offset VMT. La prevalenza di questo particolare valore potrebbe quindi avere a che fare con alcune API comuni che forniscono una classe che ha un modello di eredità simile o, più probabilmente, un'interfaccia particolare (abbastanza possibile per alcune classi di applicazioni, come i giochi DirectX). Potrebbe essere possibile tenere traccia di una semplice causa comune come questa, ma tendo a sbarazzarmi di applicazioni che fanno il dereferenziamento nullo abbastanza rapidamente, quindi ...