Debugger in-memory per .NET? [chiuso]

Question

Debugger in-memory per .NET? [chiuso]

#1 da (1 voti)
#2 da (1 voti)
#3 da (1 voti)
#4 da (0 voti)

0

Non so se "In-Memory debugger" è davvero ciò che intendo, o se è anche possibile produrre, ma è il nome migliore che potrei trovare ... Ecco lo strumento che sto cercando :

Dato un nome di variabile, risolvi quel nome in un riferimento
Dato questo riferimento, puoi guardare l'oggetto di riferimento
Dato l'orologio, essere in grado di visualizzarlo in un modo utile, ad es.
- sfoglia le proprietà dell'oggetto come in Visual Studio
- essere avvisati quando l'oggetto di riferimento è cambiato.

Ecco un caso d'uso per questo strumento ipotetico. Ho passato tutto il tempo oggi cercando di rintracciare una ObjectDisposedException nella mia app web C #. L'oggetto che si sta eliminando è WindowsIdentity dell'utente corrente e sembra che ci sia una condizione di competizione che determina la disposizione di WindowsIdentity prima che venga utilizzato. Se potessi guardare un particolare riferimento di memoria in modo intelligente, piuttosto che una variabile in un determinato ambito, penso che mi aiuterebbe a individuare più facilmente la fonte di questo tipo di bug.

Esiste uno strumento simile per .NET?

debugging c# .net tools

posta alastairs 22.11.2010 - 18:54

fonte

4 risposte

Leggi altre domande sui tag debugging c# .net tools

Il modo giusto di manipolare le immagini in un'applicazione senza server Servizi di marcatura per la gestione sicura; Annotazione o eredità?

score 1 · Answer 1

Se capisco correttamente, vuoi sapere quando un riferimento è cambiato. Bene, basta aggiungere un punto di interruzione sulle linee in cui il riferimento potrebbe essere cambiato e si interrompe l'esecuzione quando ciò accade (o prima, a seconda di dove si inserisce il punto di interruzione).

Informazioni sulla visualizzazione di variabili in altri contesti: puoi vedere qualsiasi variabile fintanto che esiste in un contesto. Utilizza il menu a discesa dei thread per selezionare diversi thread e lo stack di chiamate per navigare tra diversi frame.

score 1 · Answer 2

NLog, Log4Net, ecc ... qualsiasi buon framework di registrazione. Forse non così glamour ma altrettanto buono ... con il bonus in più per non interferire troppo con il processo che stai tentando di eseguire il debug, soprattutto per problemi di concorrenza. Hanno la fastidiosa tendenza a girare in Eisenbugs dove il solo fatto di osservare il codice in esecuzione lo farà comportare correttamente.

Non sottovalutare mai il potere della tecnologia low-tech!

score 1 · Answer 3

I debugger sono ottimi strumenti di apprendimento, ma sono fondamentalmente inferiori all'uso dei log di debug. Uno dei principali svantaggi dei debugger è che cambiano il modo in cui il programma viene eseguito, in particolare per quanto riguarda i tempi. Questo li rende particolarmente scarsi nel debug di problemi multi-threading. Scrivere registri è generalmente meno invasivo (scrivere in un file, scrivere nella console è più lento nella mia esperienza.) Poiché si parla di una potenziale "condizione di competizione", penso che si dovrebbe saltare il debugger. Osservando questa eccezione, sembra essere lanciata se si accede all'oggetto dopo aver chiamato Dispose o Close. Se questa è una classe personalizzata, hai provato ad aggiungere istruzioni di debug nei metodi Dispose o Chiudi? Se non lo è, puoi provare a completarlo con un proxy in modo da poter "vedere" ciò che chiama questi metodi nel registro di debug.

Una tecnica che ho trovato utile è scaricare una traccia di stack in un log quando non sono sicuro da dove provenga la chiamata. Una volta che sai cosa chiama Dispose o Close e lo hai verificato è troppo presto, dovresti avere abbastanza informazioni per risolvere il problema.

score 0 · Answer 4

Gli oggetti in C # non occupano una posizione di memoria specifica che puoi guardare. Vengono spostati per migliorare l'utilizzo della memoria da parte del garbage collector.

var obj = new MyObject();

Né obj come riferimento all'istanza MyObject appena creata né l'istanza MyObject stessa ha una posizione fissa in memoria.

Gli oggetti longevi potrebbero avere una posizione stabile, ma non è stato risolto.

L'unico modo per seguire ciò che accade all'istanza MyObject è di guardare ogni riferimento ad esso tramite i breakpoint come @VictorHurdugaci spiega nella sua risposta.