Visual Studio, déboguez l'un des multiples threads


127

J'ai une application avec 4 threads travaillant le même code. Cependant, quand je marche, il saute entre les différents threads. Comment puis-je le verrouiller sur un thread afin que les autres threads soient ignorés pour le débogage?


quelle version de Visual Studio utilisez-vous? Express, Pro, Ultimate ..?
Mark

alors le lien de jeffamaphone vous aidera et peut-être aussi pour plus d'informations pour passer à un autre thread lors du débogage de msdn.microsoft.com/en-us/library/bb157786.aspx
Mark

Réponses:


107

Oui.

Dans la fenêtre Threads (Déboguer -> Windows -> Threads) cliquez avec le bouton droit sur le thread de votre choix et sélectionnez "basculer vers le thread".

Vous pouvez également choisir "geler" les threads que vous ne voulez pas déboguer afin de les empêcher de fonctionner. N'oubliez pas de les «décongeler» si vous vous attendez à ce qu'ils fonctionnent.

Lectures complémentaires .


24
Je suis confus. La réponse est-elle "Cela ne peut pas être fait?" La question demande comment rester verrouillé sur un thread particulier afin que le débogueur ne saute pas entre eux. Passer à un thread est très bien, mais dès qu'un autre thread fait quelque chose, le débogueur y saute. Si je ne peux pas figer l'autre thread parce qu'il a besoin de faire des choses, comment puis-je rester verrouillé uniquement sur le thread qui me concerne?
bubbleking

Incomeplete: | vous devez toujours cliquer sur passer à, chaque fois que quelque chose se passe
deadManN

16

Le passage unique à travers un seul thread semble être principalement corrigé dans VS 2012 (avec quelques mises en garde que vous pouvez voir dans mon lien ci-dessous). Les points d'arrêt sont une douleur.

Le gel et la décongélation des threads est la solution de contournement habituelle, comme l'ont indiqué les réponses précédentes, mais c'est fastidieux et cela peut provoquer des blocages lorsque votre thread attend un autre thread gelé. Ceux-ci peuvent être difficiles à récupérer sans perdre votre place dans votre fil de discussion.

Un autre flux de travail utile consiste à appliquer un filtre de thread sur vos points d'arrêt, également indiqué dans certaines des réponses:

Créez un point d'arrêt, cliquez avec le bouton droit sur le point d'arrêt, cliquez sur Filtre et entrez ThreadId = 7740 (votre identifiant de thread dans la fenêtre des threads).

Cela peut être très fastidieux.

Ma suggestion à Microsoft est de corriger la procédure pas à pas (et ses variantes) pour ne jamais changer de thread à moins qu'un point d'arrêt explicite ne soit atteint dans un autre thread. Ils devraient également ajouter un raccourci (peut-être Ctrl-F9) pour créer un point d'arrêt avec l'ID de thread actuel comme filtre. Cela rendrait le deuxième flux de travail beaucoup plus pratique.

Votez pour la suggestion si vous acceptez que cela soit utile, ou ajoutez vos propres suggestions:

https://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/8543248-make-the-debugger-stick-to-the-current-thread-inst


1
"Le passage unique à travers un seul thread semble être principalement corrigé dans VS 2012" - pas vraiment, il est toujours cassé dans VS2017.
user626528

10

Vous pouvez également mettre un point d'arrêt conditionnel dans votre code et mettre la condition thread.Id == [someValue] ou Thread.Name == "[Somename]"dans la condition de point d'arrêt ...


Merci Charles, cela a été utile (je ne savais pas que vous pouviez le faire). Cependant, le moyen le plus efficace de déboguer pour moi est celui que jeffamaphone a écrit car je ne connais pas le nom avant qu'il n'atteigne le point d'arrêt et ne voit des valeurs
Oskar Kjellin

3

Une solution de contournement beaucoup plus rapide existe pour les cas simples - voir les commentaires dans le lien de Steve.

le débogueur ne terminera jamais qu'une étape sur le thread à partir duquel l'étape a été créée. Donc, si vous atteignez un point d'arrêt, désactivez-le, puis commencez à avancer, vous ne devez pas vous arrêter sur un thread différent. Si vous avez d'autres points d'arrêt dans votre application et qu'un autre thread en atteint un, vous déboguerez dans l'état de thread mixte comme décrit

Donc, dans mon cas, une fois que les différents threads ont commencé à atteindre mon point d'arrêt, j'ai simplement appuyé sur Continuer plusieurs fois jusqu'à ce que j'identifie l'appel que je recherchais - puis j'ai supprimé le point d'arrêt et parcouru le reste du code tout en restant sur le même thread sans interférence de le reste d'entre eux.

Cela devient évidemment un problème si vous avez plusieurs points d'arrêt que vous souhaitez conserver, etc. - mais encore une fois pour les cas simples, c'est beaucoup plus facile à faire.


2

Cela ressemble fortement à un problème très similaire dans Visual Studio 2008 SP1. Il a été corrigé avec un correctif post-SP. Mais il y a d'autres preuves que le correctif n'a pas été incorporé dans la base de code, cet élément de rétroaction était également un problème. Il n'est pas si inhabituel que les correctifs ne soient pas intégrés.

Il n'y a pas d'élément de commentaire qui décrit exactement votre problème, du moins que je puisse trouver. Je vous recommande d'en déposer un. Étant donné le problème habituel avec la reproduction de bogues comme celui-ci, je vous recommande fortement d'inclure un projet de reproduction qui présente ce problème avec des instructions sur la façon de reproduire le problème.

Il existe une sorte de solution de contournement pour votre problème, vous pouvez accéder à Debug + Windows + Threads, cliquez avec le bouton droit sur les threads que vous ne souhaitez pas déboguer et sélectionnez Figer. N'oubliez pas de les décongeler plus tard.

Ces bogues ont été à nouveau corrigés dans Visual Studio 2010 Service Pack 1.


1

J'utilise Visual Studio Professional 2017 et j'utilise la fenêtre Threads pour figer et dégeler de manière sélective les threads. Habituellement, j'ai plusieurs threads du même code et je veux seulement les figer, pas les autres. J'aime vraiment la fenêtre MS Threads car je peux sélectionner un sous-ensemble de threads à figer. Je groupe les threads par nom et je peux ensuite geler tous ceux exécutant le même code que je débogue tout en laissant les threads restants s'exécuter. J'ai essayé d'utiliser l'extension Erwin Mayer, et cela a très bien fonctionné, mais cela gèle tous les threads sauf celui que je suis en cours d'exécution, et je me retrouve parfois dans une situation où le débogage n'atteint pas le point d'arrêt, je pense qu'il devrait, alors parce que tout le les autres threads sont arrêtés et l'application semble arrêtée. Le fait d'appuyer sur le bouton de pause et de débloquer les threads dans la fenêtre des threads résout ce problème.


0

5. Passez à travers un seul fil sans sauter

À quelle fréquence déboguez-vous du code multithread, lorsque vous atteignez votre premier point d'arrêt, faites un pas, puis soudainement vous êtes arrêté avec la flèche jaune sur un autre thread? Le comportement inattendu provient du fait que le point d'arrêt est toujours défini et par conséquent atteint. Par défaut, le débogueur s'arrête sur un point d'arrêt à chaque fois qu'il est touché. Cela signifie que lorsque vous effectuez une étape, tous les threads sont autorisés à s'exécuter, et l'un de vos threads en cours d'exécution atteint ce point d'arrêt avant la fin de l'étape sur votre thread actuel. La prochaine fois que vous vous retrouverez dans cette situation, essayez ceci:

  1. Désactivez ou supprimez le point d'arrêt qui a été atteint par le nouveau thread vers lequel le débogueur est passé.
  2. Appuyez sur Continuer (F5)
  3. Observez comment votre première étape initiale sur ce premier thread se termine et est maintenant le contexte de débogage actif.
  4. Étant donné que vos points d'arrêt sont supprimés ou désactivés, vous pouvez continuer à marcher sur ce thread unique sans interruption.

7 hacks moins connus pour le débogage dans Visual Studio

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.