2010-05-13 20 views
6

Pourquoi une trace de pile afficherait-elle "ligne 0", mais seulement pour une image dans la trace de pile?Stack trace avec un numéro de ligne incorrect

par ex.

... 
at System.Data.SqlClient.SqlCommand.ExecuteDbDataReader(CommandBehavior behavior) 
at System.Data.Common.DbCommand.System.Data.IDbCommand.ExecuteReader() 
at My.LibraryA.Some.Method():line 16 
at My.LibraryB.Some.OtherMethod():line 0 
at My.LibraryB.Some.Method():line 22 
at My.LibraryA.Some.Method():line 10 

Contexte:

j'ai une application qui a échoué avec une exception, et se connecte une trace de pile dans son fichier journal. Lorsque l'applciation a été compilée, tous les assemblys ont été compilés avec des informations de débogage complètes (Propriétés du projet -> Build -> Advanced -> Informations de débogage -> Full), et ainsi les fichiers PDB ont été générés. Pour m'aider à diagnostiquer l'origine de l'erreur, j'ai supprimé les fichiers PDB dans le répertoire bin de l'application et reproduit l'exception. Tous les numéros de ligne pour chaque cadre de pile semblent corrects, à l'exception d'un qui affiche la ligne 0 comme source.

+0

A-t-il été compilé avec les optimisations activées? (Souvenez-vous, les optimisations on/off et debug info on/off sont des commutateurs orthogonaux.) Si c'est le cas, la gigue peut choisir de faire des optimisations inline ou autres qui peuvent rendre difficile le calcul du code original. –

+0

@Eric: oui c'était. Y a-t-il un moyen d'obtenir le numéro de ligne réel de? – adrianbanks

+1

Bien sûr. Compilez-le avec les optimisations désactivées. –

Répondre

3

C'était en effet le long de la méthode d'inlining comme le suggéra Eric.

J'ai réussi à reproduire l'erreur d'origine localement, mais uniquement lors de la compilation dans une version de publication. Comme j'avais les PDB, je pouvais parcourir le code et trouver le problème.