J'ai un problème de débogage des sessions. Mon programme s'exécute très bien dans une session de débogage, mais si je commence une course normale, elle se comporte complètement différente.
Le problème est que je ne peux pas dire pourquoi cela agit différent.
Une raison possible est l'heure d'exécution plus lente parce que vous devez toujours appuyer sur F6 . Alors: Quels sont les astuces, les meilleures pratiques pour faire savoir pourquoi il agit si différent dans les sessions de débogage?
J'ai essayé d'insérer thread.sleep (1000); mais je n'ai pas l'instruction causer le comportement différent.
7 Réponses :
Vous pouvez observer une condition de course qui ne se produit que lorsqu'il n'y a pas de déclarations de débogage qui ralentissent l'exécution. Il pourrait être utile de commencer par examiner votre modèle de threading et surveiller les éventuels serrures.
Pour les blocages, voir JavaSpecialists.eu/archive/issue093.html
Il est vraiment difficile de déboguer des applications multi-filetées.
Vous pouvez essayer de débogage en utilisant l'ancien Technic System.out.println au lieu d'utiliser le débogueur ... peut-être cela vous permettra de déboguer tout en ayant le comportement différent que vous avez mentionné.
Manu
Deux solutions:
a) Utilisez le débogueur de l'homme pauvre (imprimé à la console) ou utilisez un cadre de journalisation. Une fois que l'erreur se produit, analysez la sortie.
B) Écrivez un cas de test qui essaie de reproduire le problème. Même si vous ne pouvez pas le trouver de cette façon, cela va nettoyer votre code et résoudre parfois le problème.
Si le problème est vraiment causé par des conditions de race, le débogage de style de journalisation ne fera que rendre la situation plus confuse. Si le problème n'est pas, votre chemin est probablement le meilleur.
Java.IO.PrintStream.println (String) Invoque la synchronisation, qui provoque des retards entre autres (par exemple, une course sur la ressource même que vous déboguez?). Donc, même le débogueur d'un homme pauvre aura probablement des effets secondaires inattendus. Voir:
J'ai essayé de vérifier mon hypothèse que j'ai faite et de les vérifier une fois de plus.
Une journalisation excessive pourrait être utile dans certaines situations, mais pas toujours. Dans mon cas, cela n'a pas beaucoup aidé.
Avec la journalisation, vous pouvez voir, où vos hypothèses sont correctes et lesquelles d'entre eux échouent.
Ma solution personnelle était spécifique à Java. Le chargeur de classe Java ne charge pas complètement les cours depuis JDK 1.5. Dans une séance de débogage, elle doit être chargée complètement. Donc, certaines variables n'ont pas été bien initialisées et la sortie différait de la course normale.
Cette raison est très difficile à trouver.
Pourquoi répondez-vous à vous-tu comme si vous étiez deux personnes différentes?
Comment pourrais-je y répondre d'une autre manière? Comme j'imagine Stackoverflow, il peut également être utile pour les autres utilisateurs.
Non, je ne le fais pas. Je cherche des conseils qui peuvent aider dans une telle situation. Et toutes ces réponses pourraient (!) Aide.
Je pense que vos propres conseils devraient plutôt être énumérés dans la question. Pas ajouté comme une réponse
Ce sont des stratégies très fondamentales, qui doivent être énumérées dans votre réponse, telles que "J'ai déjà essayé ...". Sinon, cela ressemble un peu à un concours.
Vérifiez d'abord des choses faciles. La version de crash obtient-elle les mêmes arguments de la ligne de commande? Ou variables d'environnement spéciales? Ou ID utilisateur? Ou un autre facteur que vous savez être important. En d'autres termes, l'exécutez-vous vraiment avec la même contribution, telle qu'elle était. Est-ce qu'il fait tomber tout le temps? Est-ce que ça tombe au même endroit? Si vous pouvez connecter un débogueur après le crash où il s'est cassé peut fournir des indices. Quelqu'un change récent est-il un coupable possible? Si oui, essayez de le retirer et voyez ce qui se passe.
Ne soyez pas trop suspendu à ces tentatives. Ils sont juste des suppositions qui sont formidables s'ils paient rapidement mais ils sont finalement improductifs car il y a des millions de différences possibles entre «courir sous un débogage» et «exécutant sauvage et libre».
Sinon, coupez l'analyse différentielle et travaillez le problème. C'est-à-dire que c'est directement sur ce qui ne va pas dans l'accident au lieu de itération des causes possibles.
Voici quelques exceptions de livres qui peuvent vous aider "déboguer sans le débogueur".
Chapitre 5, "Débogage" de "la pratique de la programmation"
bonne chance!
NB: Non nécessaire de multithreading.
Pour moi, cela a aidé parfois à définir différents points d'arrêt.
Évaluer parfois les valeurs les modifient (par exemple, les valeurs d'itérateur de lecture).
Deuxièmement, vos points d'arrêt «Faux» peuvent inhiber le parallélisme et les conditions de course.
Je rencontrais quelque chose de similaire.
Mon problème:
Bien sûr, mon code avait un bug qui comptait indirectement sur l'ordre des éléments définis. set.itéator produisait des résultats différents dans déboges et dans exécutez .
Comment pouvez-vous avoir une balise langue-agnostique et java, c'est un peu d'oxymoron
J'ai envisagé [Java] parce que je pensais avoir besoin de dire plus sur mon programme et d'être spécifique Java. Ce n'est pas nécessaire, alors j'ai supprimé la balise.
La langue est d'une certaine pertinence dans cette question. J'écrangerais la langue-agnostique pour des questions de conception, des exigences, etc.
Totalement hors sujets, mais merci d'avoir montré la balise , je ne le savais pas aussi soutenu. Joli!