Utilizzo Visual Studio 2005 in Windows XP Pro 64-bit per progetti C e C++ per un po 'di tempo. Uno dei trucchi più diffusi che ho utilizzato di tanto in tanto nel debugger è stato quello di ricordare un valore numerico del puntatore della precedente esecuzione di debug del programma (ad esempio 0x00000000FFAB8938), aggiungerlo alla finestra di controllo con un typecast appropriato (ad esempio, ((MyObject *) 0x00000000FFAB8938)->data_field) e quindi guarda la memoria occupata dall'oggetto durante la successiva esecuzione di debug. In molti casi questa è una cosa abbastanza comoda e utile da fare, poiché finché il codice rimane invariato, è ragionevole aspettarsi che anche il layout della memoria allocata rimanga invariato. In breve, funziona.Stabilità del puntatore in Windows Vista
Tuttavia, relativamente di recente ho iniziato a utilizzare la stessa versione di Visual Studio su un laptop con Windows Vista (Home Premium) a 64 bit. Stranamente, è molto più difficile usare questo trucco in quella configurazione. L'effettivo indirizzo di memoria sembra cambiare piuttosto spesso da esecuzione a esecuzione senza una ragione apparente, vale a dire anche quando il codice del programma non è stato modificato affatto. Sembra che l'indirizzo effettivo non cambi completamente in modo casuale, ma seleziona un valore da un set fisso di valori più o meno stabile, ma in ogni caso rende molto più difficile fare questo tipo di visione della memoria.
Qualcuno conosce il motivo di questo comportamento in Windows Vista? Qual è la causa del cambiamento nel layout della memoria? È un'intrusione esterna nello spazio di indirizzamento del processo da altri processi [di sistema]? O è qualche stranezza/funzionalità di implementazione dell'API di Heap in Vista? C'è un modo per evitare che ciò accada?
Sotto Linux esiste da molto tempo un randomizzatore di heap che mira a evitare attacchi di overflow del buffer. Forse è stato finalmente implementato anche dalla MS? – jdehaan
Beh, lo so, ma AFAIK funziona solo quando * si riavvia * il copmputer. Più precisamente, ho sentito che MS ha implementato la loro versione per randomizzare cose ad ogni avvio (non so come funzioni su Linux). Quindi, il comportamento che osservo in Vista non sembra essere correlato. – AnT
Anche se questo potrebbe essere qualcosa. Sono in esecuzione VS 2005, che è un'applicazione a 32 bit in grado di eseguire il debug di applicazioni a 64 bit. AFAIK, funziona tramite il meccanismo di debug remoto di MS. Potrebbe essere che Vista "stia" essenzialmente un nuovo ambiente a 64 bit ogni volta che avvierò un'applicazione a 64 bit da VS 2005 (causando così il randomizzazione delle cose)? – AnT