Cosa non può & # 8220; impossibile valutare l'espressione perché il codice del metodo corrente è ottimizzato. & # 8221; significare?

https://stackoverflow.com/questions/131628

02-07-2019
|

Domanda

Ho scritto del codice con molta ricorsione, che richiede parecchio tempo per essere completato. Ogni volta che "metto in pausa" la corsa per vedere cosa sta succedendo ottengo:

Impossibile valutare l'espressione perché il codice del metodo corrente è ottimizzato.

Penso di capire cosa significhi. Tuttavia, ciò che mi confonde è che dopo aver premuto step, il codice non è "ottimizzato". più, e posso guardare le mie variabili. Come succede? In che modo il codice può alternare tra codice ottimizzato e non ottimizzato?

Soluzione

Il debugger utilizza FuncEval per consentirti di " guardare " variabili. FuncEval richiede l'arresto dei thread nel codice gestito in un punto sicuro di GarbageCollector. Manualmente "mettere in pausa" l'esecuzione nell'IDE causa l'arresto di tutti i thread il prima possibile. Il tuo codice altamente ricorsivo tenderà a fermarsi in un punto non sicuro. Pertanto, il debugger non è in grado di valutare le espressioni.

Premendo F10 si passa al successivo punto Funceval Safe e si abilita la valutazione delle funzioni.

Per ulteriori informazioni, consultare le regole di FuncEval .

Altri suggerimenti

Mentre la linea Debug.Break () è in cima al callstack non puoi valutare le espressioni. Questo perché quella linea è ottimizzata. Premi F10 per passare alla riga successiva - una riga di codice valida - e l'orologio funzionerà.

Probabilmente stai provando a eseguire il debug dell'app in modalità di rilascio anziché in modalità di debug, oppure hai attivato le ottimizzazioni nelle impostazioni di compilazione.

Quando il codice viene compilato con ottimizzazioni, alcune variabili vengono eliminate una volta che non vengono più utilizzate nella funzione, motivo per cui viene visualizzato quel messaggio. In modalità debug con ottimizzazioni disabilitate, non dovresti ottenere questo errore.

Questo mi ha fatto impazzire. Ho provato a collegarmi con Managed e codice nativo - no go.

Questo ha funzionato per me e sono stato finalmente in grado di valutare tutte le espressioni:

Vai a Progetto / Proprietà
Seleziona la scheda Genera e fai clic Avanzate ...
Assicurati che le informazioni di debug siano impostate su " completo " (non solo pdb)
Debug del tuo progetto - voilà!

Il seguito ha funzionato per me, grazie @Vin.

Ho avuto questo problema quando stavo usando VS 2015. La mia soluzione: la configurazione ha (Debug) selezionato. Ho risolto questo deselezionando la proprietà Optimize Code nelle proprietà del progetto.

Progetto (clic destro) = > Proprietà = > Build (tab) = > deseleziona Ottimizza codice

Cerca una chiamata di funzione con molti parametri e prova a ridurre il numero fino a quando non viene restituito il debug.

Assicurati di non avere qualcosa del genere

[assembly: Debuggable(DebuggableAttribute.DebuggingModes.IgnoreSymbolStoreSequencePoints)]

nel tuo AssemblyInfo

L'amico di un amico di Microsoft ha inviato questo: http://blogs.msdn.com/rmbyers/archive/2008/08/16/Func_2D00_eval-can-fail-while-stopped-in -a-non_2D00_optimized gestiti metodo-che-spinge-256-argomenti-byte-aspx più del

Il problema più probabile è che lo stack di chiamate venga ottimizzato perché la firma del metodo è troppo grande.

Ha avuto lo stesso problema ma è stato in grado di risolverlo disattivando il trapping delle eccezioni nel debugger. Fai clic su [Debug] [Eccezioni] e imposta le eccezioni su " Non gestito dall'utente " ;.

Normalmente ho spento questo, ma è utile di tanto in tanto. Devo solo ricordare di spegnerlo quando ho finito.

Ho riscontrato questo problema quando stavo usando VS 2010. La mia soluzione di configurazione è stata selezionata (Debug). Ho risolto questo deselezionando la proprietà Ottimizza codice nelle proprietà del progetto. Progetto (clic destro) = > Proprietà = > Build (tab) = > deseleziona Ottimizza codice

Nel mio caso avevo 2 progetti nella mia soluzione e stavo eseguendo un progetto che non era il progetto di avvio. Quando l'ho modificato in un progetto di avvio, il debug ha ripreso a funzionare.

Spero che aiuti qualcuno.

Valutazione:

In .NET, "Valutazione funzioni (funceval)" è la capacità di CLR di iniettare alcune chiamate arbitrarie mentre il debuggee viene fermato da qualche parte. Funceval prende in carico il thread scelto dal debugger per eseguire il metodo richiesto. Al termine di funceval, genera un evento di debug. Tecnicamente, CLR ha definito i modi in cui il debugger può emettere un funceval.

CLR consente di avviare funceval solo su quei thread che si trovano nel punto sicuro GC (ovvero quando il thread non bloccherà GC) e Funceval Safe (punto FESafe) (ovvero dove CLR può effettivamente fare il dirottamento per il funceval.) . Pertanto, possibili scenari per CLR, un thread deve essere:

arrestato nel codice gestito (e in un punto sicuro GC): ciò implica che non è possibile eseguire un funceval nel codice nativo. Poiché il codice nativo è al di fuori del controllo del CLR, non è in grado di impostare il funceval.
fermato alla prima possibilità o eccezione gestita non gestita (e in un punto sicuro GC): vale a dire al momento dell'eccezione, per ispezionare il più possibile per determinare il motivo per cui si è verificata tale eccezione. (ad esempio: il debugger può provare a valutare e visualizzare la proprietà Message sull'eccezione sollevata.)

Complessivamente, i metodi più comuni per arrestare il codice gestito includono l'arresto a un punto di interruzione, passaggio, chiamata Debugger.Break, intercettazione di un'eccezione o all'inizio di un thread. Questo aiuta a valutare il metodo e le espressioni.

Possibili risoluzioni: Sulla base della valutazione, se il thread non si trova in punti FESafe e GCSafe, CLR non sarà in grado di dirottare il thread per avviare il funceval. Generalmente, il seguito aiuta ad assicurarsi che funceval inizi quando previsto:

Passaggio 1:

Assicurati di non provare a eseguire il debug di una build "Release". Il rilascio è completamente ottimizzato e quindi porterà all'errore nella discussione. Usando la barra degli strumenti Standard o Configuration Manager, puoi passare da Debug & amp; Rilascio.

Passaggio 2:

Se l'errore persiste, è possibile che l'opzione di debug sia impostata per l'ottimizzazione. Verifica & amp; Deseleziona la proprietà "Ottimizza codice" in Progetto "Proprietà":

Fai clic con il pulsante destro del mouse sul Progetto Seleziona l'opzione "Proprietà" Vai alla scheda "Costruisci" Deseleziona la casella di controllo "Ottimizza codice"

Passaggio n. 3:

Se l'errore persiste, la modalità Informazioni di debug potrebbe non essere corretta. Verifica & amp; impostalo su "completo" in "Impostazioni avanzate di costruzione":

Fai clic con il pulsante destro del mouse sul Progetto Seleziona l'opzione "Proprietà" Vai alla scheda "Costruisci" Fai clic sul pulsante "Avanzate" Impostare "Informazioni debug" su "completo"

Passaggio n. 4:

Se il problema persiste, prova quanto segue:

Esegui un "Clean" & amp; quindi una "Ricostruzione" del file della soluzione Durante il debug: Vai alla finestra dei moduli (Menu VS - > Debug - > Windows - > Modules) Trova il tuo gruppo nell'elenco dei moduli caricati. Verificare che il percorso elencato nell'assieme caricato sia quello che ci si aspetta che sia Controllare il timestamp modificato del file per confermare che l'assembly è stato effettivamente ricostruito Verifica se il modulo caricato è ottimizzato o meno

Conclusione:

Non si tratta di un errore ma di informazioni basate su determinate impostazioni e progettate in base al funzionamento di .NET runtime.

nel mio caso ero in modalità di rilascio che ho modificato per eseguire il debug di tutto ha funzionato

Ho avuto un problema simile e si è risolto quando ho creato la soluzione in modalità debug e ho sostituito il file pdb nel percorso di esecuzione.

Credo che ciò che stai vedendo sia il risultato delle ottimizzazioni - a volte una variabile verrà riutilizzata - in particolare quelle create nello stack. Ad esempio, supponiamo di avere un metodo che utilizza due numeri interi (locali). Il primo numero intero viene dichiarato all'inizio del metodo e viene utilizzato esclusivamente come contatore per un ciclo. Il secondo numero intero viene utilizzato dopo che il ciclo è stato completato e memorizza il risultato di un calcolo che verrà successivamente scritto su file. In questo caso, l'ottimizzatore PUO 'decidere di riutilizzare il tuo primo numero intero, salvando il codice necessario per il secondo numero intero. Quando provi a guardare il secondo numero intero all'inizio, ricevi il messaggio che stai chiedendo a proposito di " Impossibile valutare l'espressione " ;. Anche se non riesco a spiegare le circostanze esatte, è possibile che l'ottimizzatore trasferisca il valore del secondo numero intero in un oggetto stack separato in un secondo momento, risultando quindi in grado di accedere al valore dal debugger.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow