Bonjour, j'ai eclipse 3.2, et quand je débug j'ai plusieurs threads.
J'ai une exception sur un accès concurrent à un moment donné sur le
parcours d'une HashMap... je voudrais savoir quels sont les threads qui
font des appels simultanés pour debugger , malheureusement la stacktrace
n'en donne qu'un ... et mes fenetres de debugging sont pas très locaces
sur les différents threads qui s'executent et leur état
Du coup :
- peut on demander dans le debugger de s'arreter à chaque exception non
capturée, avant la fin du programme
- comment peut on savoir quels sont les threads qui font accès
simultanés, les 2 stacktraces mises en cause en gros
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Hervé AGNOUX
Pif wrote:
Bonjour, j'ai eclipse 3.2, et quand je débug j'ai plusieurs threads.
J'ai une exception sur un accès concurrent à un moment donné sur le parcours d'une HashMap... je voudrais savoir quels sont les threads qui font des appels simultanés pour debugger , malheureusement la stacktrace n'en donne qu'un ... et mes fenetres de debugging sont pas très locaces sur les différents threads qui s'executent et leur état
Du coup : - peut on demander dans le debugger de s'arreter à chaque exception non capturée, avant la fin du programme - comment peut on savoir quels sont les threads qui font accès simultanés, les 2 stacktraces mises en cause en gros
merci !
Le déboguage en accés concurrent est un chemin de croix :-)
Première approche : essayer de reproduire le blême.
Dans ce cas tu vas essayer de débrouissailler le brouillard, de façon parfaitement classique : reproduire le bug. Tu essaies de trouver la situation qui produit à coup sûr l'accés concurent. Une fois que c'est fait, alors tout devient plus simple, et tu utilises la panoplie à dispo du programmeur.
Pour trouver, je ne connais que la reflexion et l'observation. Avec elle tu isoles la portion de code en cause, et tu essaies de faire une routine de test qui la met à l'épreuve. Tu as une hypothèse que dans telle config alors l'accés concurrent se provoque ? Alors tu testes ton hypothèse, --> une seule hypothèse à chaque fois <--, et tu recommences.
Deuxième approche : impossible de reproduire le blême.
C'est souvent le cas en accés concurrent :-)
En ce cas une solution consiste à essayer de placer des marqueurs, des logs, de façon à, lorsqu'il se produit, d'essayer de comprendre au moins ce qui se passe.
Par exemple une instruction pratique est Thread.dumpStack().
Malheureusement ces marqueurs perturbent souvent le phénomène, et il devient difficile à observer.
Une autre solution consiste à essayer de comprendre intellectuellement la situation, et de se placer dans le pire des cas.
Une autre solution encore consiste à ne plus essayer de résoudre du tout le blème, mais de simplifier ton code, de façon à limiter au maximum les accés concurrents. Plus le code est simple, plus il est facile de repérer les endroits à protéger. Ici tu ne fais que rechercher quels sont les endroits compliqués, et tu essaies de résoudre la complication, sans aucunement te préoccuper de savoir si elle provoque un accés concurrent ou pas.
En situation où la reproduction est aléatoire, il se peut qu'il soit utile de te faire un bout de code qui fait tourner un grand nombre de fois le code en examen. Mais ça marche pas toujours. Surtout qu'il faut, pour que ça marche, essayer que chaque passage ne soit pas strictement équivalent au précédent.
La programmation par "assert" peut être utile aussi. Elle te permet de découvrir un état anormal du système avant qu'il ne déraille.
Et pour répondre précisément à tes questions : je ne sais pas s'il est possible de placer un point d'arrêt sur émission d'exception avec éclipse ; avec netbean, oui. Donc je suppose qu'avec eclipse c'est possible.
Pour savoir quels sont les threads qui font accès simultanés... seul ton cerveau peut t'aider (et quelques fois l'instruction Thread.dumpStack() astucieusement négociée).
Etc.
-- Hervé AGNOUX http://www.diaam-informatique.com
Pif wrote:
Bonjour, j'ai eclipse 3.2, et quand je débug j'ai plusieurs threads.
J'ai une exception sur un accès concurrent à un moment donné sur le
parcours d'une HashMap... je voudrais savoir quels sont les threads qui
font des appels simultanés pour debugger , malheureusement la stacktrace
n'en donne qu'un ... et mes fenetres de debugging sont pas très locaces
sur les différents threads qui s'executent et leur état
Du coup :
- peut on demander dans le debugger de s'arreter à chaque exception non
capturée, avant la fin du programme
- comment peut on savoir quels sont les threads qui font accès
simultanés, les 2 stacktraces mises en cause en gros
merci !
Le déboguage en accés concurrent est un chemin de croix :-)
Première approche : essayer de reproduire le blême.
Dans ce cas tu vas essayer de débrouissailler le brouillard, de façon
parfaitement classique : reproduire le bug. Tu essaies de trouver la
situation qui produit à coup sûr l'accés concurent. Une fois que c'est
fait, alors tout devient plus simple, et tu utilises la panoplie à dispo du
programmeur.
Pour trouver, je ne connais que la reflexion et l'observation. Avec elle tu
isoles la portion de code en cause, et tu essaies de faire une routine de
test qui la met à l'épreuve. Tu as une hypothèse que dans telle config
alors l'accés concurrent se provoque ? Alors tu testes ton hypothèse, -->
une seule hypothèse à chaque fois <--, et tu recommences.
Deuxième approche : impossible de reproduire le blême.
C'est souvent le cas en accés concurrent :-)
En ce cas une solution consiste à essayer de placer des marqueurs, des logs,
de façon à, lorsqu'il se produit, d'essayer de comprendre au moins ce qui
se passe.
Par exemple une instruction pratique est Thread.dumpStack().
Malheureusement ces marqueurs perturbent souvent le phénomène, et il devient
difficile à observer.
Une autre solution consiste à essayer de comprendre intellectuellement la
situation, et de se placer dans le pire des cas.
Une autre solution encore consiste à ne plus essayer de résoudre du tout le
blème, mais de simplifier ton code, de façon à limiter au maximum les accés
concurrents. Plus le code est simple, plus il est facile de repérer les
endroits à protéger. Ici tu ne fais que rechercher quels sont les endroits
compliqués, et tu essaies de résoudre la complication, sans aucunement te
préoccuper de savoir si elle provoque un accés concurrent ou pas.
En situation où la reproduction est aléatoire, il se peut qu'il soit utile
de te faire un bout de code qui fait tourner un grand nombre de fois le
code en examen. Mais ça marche pas toujours. Surtout qu'il faut, pour que
ça marche, essayer que chaque passage ne soit pas strictement équivalent au
précédent.
La programmation par "assert" peut être utile aussi. Elle te permet de
découvrir un état anormal du système avant qu'il ne déraille.
Et pour répondre précisément à tes questions : je ne sais pas s'il est
possible de placer un point d'arrêt sur émission d'exception avec éclipse ;
avec netbean, oui. Donc je suppose qu'avec eclipse c'est possible.
Pour savoir quels sont les threads qui font accès simultanés... seul ton
cerveau peut t'aider (et quelques fois l'instruction Thread.dumpStack()
astucieusement négociée).
Bonjour, j'ai eclipse 3.2, et quand je débug j'ai plusieurs threads.
J'ai une exception sur un accès concurrent à un moment donné sur le parcours d'une HashMap... je voudrais savoir quels sont les threads qui font des appels simultanés pour debugger , malheureusement la stacktrace n'en donne qu'un ... et mes fenetres de debugging sont pas très locaces sur les différents threads qui s'executent et leur état
Du coup : - peut on demander dans le debugger de s'arreter à chaque exception non capturée, avant la fin du programme - comment peut on savoir quels sont les threads qui font accès simultanés, les 2 stacktraces mises en cause en gros
merci !
Le déboguage en accés concurrent est un chemin de croix :-)
Première approche : essayer de reproduire le blême.
Dans ce cas tu vas essayer de débrouissailler le brouillard, de façon parfaitement classique : reproduire le bug. Tu essaies de trouver la situation qui produit à coup sûr l'accés concurent. Une fois que c'est fait, alors tout devient plus simple, et tu utilises la panoplie à dispo du programmeur.
Pour trouver, je ne connais que la reflexion et l'observation. Avec elle tu isoles la portion de code en cause, et tu essaies de faire une routine de test qui la met à l'épreuve. Tu as une hypothèse que dans telle config alors l'accés concurrent se provoque ? Alors tu testes ton hypothèse, --> une seule hypothèse à chaque fois <--, et tu recommences.
Deuxième approche : impossible de reproduire le blême.
C'est souvent le cas en accés concurrent :-)
En ce cas une solution consiste à essayer de placer des marqueurs, des logs, de façon à, lorsqu'il se produit, d'essayer de comprendre au moins ce qui se passe.
Par exemple une instruction pratique est Thread.dumpStack().
Malheureusement ces marqueurs perturbent souvent le phénomène, et il devient difficile à observer.
Une autre solution consiste à essayer de comprendre intellectuellement la situation, et de se placer dans le pire des cas.
Une autre solution encore consiste à ne plus essayer de résoudre du tout le blème, mais de simplifier ton code, de façon à limiter au maximum les accés concurrents. Plus le code est simple, plus il est facile de repérer les endroits à protéger. Ici tu ne fais que rechercher quels sont les endroits compliqués, et tu essaies de résoudre la complication, sans aucunement te préoccuper de savoir si elle provoque un accés concurrent ou pas.
En situation où la reproduction est aléatoire, il se peut qu'il soit utile de te faire un bout de code qui fait tourner un grand nombre de fois le code en examen. Mais ça marche pas toujours. Surtout qu'il faut, pour que ça marche, essayer que chaque passage ne soit pas strictement équivalent au précédent.
La programmation par "assert" peut être utile aussi. Elle te permet de découvrir un état anormal du système avant qu'il ne déraille.
Et pour répondre précisément à tes questions : je ne sais pas s'il est possible de placer un point d'arrêt sur émission d'exception avec éclipse ; avec netbean, oui. Donc je suppose qu'avec eclipse c'est possible.
Pour savoir quels sont les threads qui font accès simultanés... seul ton cerveau peut t'aider (et quelques fois l'instruction Thread.dumpStack() astucieusement négociée).
Etc.
-- Hervé AGNOUX http://www.diaam-informatique.com
alexandre cartapanis
Bonjour, j'ai eclipse 3.2, et quand je débug j'ai plusieurs threads.
J'ai une exception sur un accès concurrent à un moment donné sur le parcours d'une HashMap... je voudrais savoir quels sont les threads qui font des appels simultanés pour debugger , malheureusement la stacktr ace n'en donne qu'un ... et mes fenetres de debugging sont pas très locac es sur les différents threads qui s'executent et leur état
Du coup : - peut on demander dans le debugger de s'arreter à chaque exception n on capturée, avant la fin du programme - comment peut on savoir quels sont les threads qui font accès simultanés, les 2 stacktraces mises en cause en gros
merci !
Bon ce n'est pas un réponse a ta question, mais plutôt une remarque concernant l'accès concurrentiel.
Voici un bout de code (java5):
Set<String> set = new HashSet<String>(); ... for (String str: set) { if (...) { set.remove(str); } }
Ce code produit une ConcurrentModificationException. Pourtant, il n'y a qu'un seul thread.
En fait, la nouvelle boucle récupère un iterator sur le set, et tant que cet iterator est utilisé (donc tant que l'on est dans la boucle) on ne peux plus faire un remove sur le set.
La solution:
Set<String> set = new HashSet<String>(); ... Iterator<String> iter = set.iterator(); while (iter.hasNext()) { String str = iter.next(); if (...) { iter.remove(str); } }
Notez bien le iter.remove(), qui remplace le set.remove().
Voila, je sais ça n'a rien a voir avec ta question, mais bon, comme on parle d'accès concurrent...
-- Alexandre CARTAPANIS - Responsable Système et Réseau Email Gsm. 06 72 07 51 55
Bonjour, j'ai eclipse 3.2, et quand je débug j'ai plusieurs threads.
J'ai une exception sur un accès concurrent à un moment donné sur le
parcours d'une HashMap... je voudrais savoir quels sont les threads qui
font des appels simultanés pour debugger , malheureusement la stacktr ace
n'en donne qu'un ... et mes fenetres de debugging sont pas très locac es
sur les différents threads qui s'executent et leur état
Du coup :
- peut on demander dans le debugger de s'arreter à chaque exception n on
capturée, avant la fin du programme
- comment peut on savoir quels sont les threads qui font accès
simultanés, les 2 stacktraces mises en cause en gros
merci !
Bon ce n'est pas un réponse a ta question, mais plutôt une remarque
concernant l'accès concurrentiel.
Voici un bout de code (java5):
Set<String> set = new HashSet<String>();
...
for (String str: set) {
if (...) {
set.remove(str);
}
}
Ce code produit une ConcurrentModificationException. Pourtant, il n'y a
qu'un seul thread.
En fait, la nouvelle boucle récupère un iterator sur le set, et tant que
cet iterator est utilisé (donc tant que l'on est dans la boucle) on ne
peux plus faire un remove sur le set.
La solution:
Set<String> set = new HashSet<String>();
...
Iterator<String> iter = set.iterator();
while (iter.hasNext()) {
String str = iter.next();
if (...) {
iter.remove(str);
}
}
Notez bien le iter.remove(), qui remplace le set.remove().
Voila, je sais ça n'a rien a voir avec ta question, mais bon, comme on
parle d'accès concurrent...
--
Alexandre CARTAPANIS - Responsable Système et Réseau
Email alexandre.cartapanis@macymed.fr
Gsm. 06 72 07 51 55
Bonjour, j'ai eclipse 3.2, et quand je débug j'ai plusieurs threads.
J'ai une exception sur un accès concurrent à un moment donné sur le parcours d'une HashMap... je voudrais savoir quels sont les threads qui font des appels simultanés pour debugger , malheureusement la stacktr ace n'en donne qu'un ... et mes fenetres de debugging sont pas très locac es sur les différents threads qui s'executent et leur état
Du coup : - peut on demander dans le debugger de s'arreter à chaque exception n on capturée, avant la fin du programme - comment peut on savoir quels sont les threads qui font accès simultanés, les 2 stacktraces mises en cause en gros
merci !
Bon ce n'est pas un réponse a ta question, mais plutôt une remarque concernant l'accès concurrentiel.
Voici un bout de code (java5):
Set<String> set = new HashSet<String>(); ... for (String str: set) { if (...) { set.remove(str); } }
Ce code produit une ConcurrentModificationException. Pourtant, il n'y a qu'un seul thread.
En fait, la nouvelle boucle récupère un iterator sur le set, et tant que cet iterator est utilisé (donc tant que l'on est dans la boucle) on ne peux plus faire un remove sur le set.
La solution:
Set<String> set = new HashSet<String>(); ... Iterator<String> iter = set.iterator(); while (iter.hasNext()) { String str = iter.next(); if (...) { iter.remove(str); } }
Notez bien le iter.remove(), qui remplace le set.remove().
Voila, je sais ça n'a rien a voir avec ta question, mais bon, comme on parle d'accès concurrent...
-- Alexandre CARTAPANIS - Responsable Système et Réseau Email Gsm. 06 72 07 51 55
Bonjour, j'ai eclipse 3.2, et quand je débug j'ai plusieurs threads.
J'ai une exception sur un accès concurrent à un moment donné sur le parcours d'une HashMap... je voudrais savoir quels sont les threads qui font des appels simultanés pour debugger , malheureusement la stacktrace n'en donne qu'un ... et mes fenetres de debugging sont pas très locaces sur les différents threads qui s'executent et leur état Les bugs de synchro, c'est que du bon...
Verifie surtout que c'est pas ton propre thread qui a fait directement ou indirectement une modification de liste pendant que tu utilise un iterator, c'est le plus classique...
Du coup : - peut on demander dans le debugger de s'arreter à chaque exception non capturée, avant la fin du programme Oui, ca c'est facile.
Dans le vue qui liste les points d'arrêt > Tu as un bouton en haut à droite (de tete, je crois que l'icone est un : '!') > Tu peux choisir le type d'exception (Tu peux prendre throwable)
- comment peut on savoir quels sont les threads qui font accès simultanés, les 2 stacktraces mises en cause en gros
1. Tu identifie le thread et l'itération qui pose problème. (Celui qui pete actuellement) et tu met un point d'arret dans la boucle.
2. Dans la class HashMap il y a un attribut qui est incrémenté a chaque modification de ta map. Tu met un point d'arret à chaques lignes qui l'incremente.
3. Tu execute ta boucle en pas à pas jusqu'à ce que quelqu'un soit arreté dans la classe HashMap.
4. Tu fait bosser le neurone pour comprendre pourquoi il y a modification de ta liste à se moment, et tu cherche comment gérer correctement ta synchro.
merci !
Courage, Myst
Bonjour, j'ai eclipse 3.2, et quand je débug j'ai plusieurs threads.
J'ai une exception sur un accès concurrent à un moment donné sur le
parcours d'une HashMap... je voudrais savoir quels sont les threads qui
font des appels simultanés pour debugger , malheureusement la stacktrace
n'en donne qu'un ... et mes fenetres de debugging sont pas très locaces
sur les différents threads qui s'executent et leur état
Les bugs de synchro, c'est que du bon...
Verifie surtout que c'est pas ton propre thread qui a fait directement
ou indirectement une modification de liste pendant que tu utilise un
iterator, c'est le plus classique...
Du coup :
- peut on demander dans le debugger de s'arreter à chaque exception non
capturée, avant la fin du programme
Oui, ca c'est facile.
Dans le vue qui liste les points d'arrêt > Tu as un bouton en haut à
droite (de tete, je crois que l'icone est un : '!') > Tu peux choisir le
type d'exception (Tu peux prendre throwable)
- comment peut on savoir quels sont les threads qui font accès
simultanés, les 2 stacktraces mises en cause en gros
1. Tu identifie le thread et l'itération qui pose problème.
(Celui qui pete actuellement) et tu met un point d'arret dans la boucle.
2. Dans la class HashMap il y a un attribut qui est incrémenté a chaque
modification de ta map. Tu met un point d'arret à chaques lignes qui
l'incremente.
3. Tu execute ta boucle en pas à pas jusqu'à ce que quelqu'un soit
arreté dans la classe HashMap.
4. Tu fait bosser le neurone pour comprendre pourquoi il y a
modification de ta liste à se moment, et tu cherche comment gérer
correctement ta synchro.
Bonjour, j'ai eclipse 3.2, et quand je débug j'ai plusieurs threads.
J'ai une exception sur un accès concurrent à un moment donné sur le parcours d'une HashMap... je voudrais savoir quels sont les threads qui font des appels simultanés pour debugger , malheureusement la stacktrace n'en donne qu'un ... et mes fenetres de debugging sont pas très locaces sur les différents threads qui s'executent et leur état Les bugs de synchro, c'est que du bon...
Verifie surtout que c'est pas ton propre thread qui a fait directement ou indirectement une modification de liste pendant que tu utilise un iterator, c'est le plus classique...
Du coup : - peut on demander dans le debugger de s'arreter à chaque exception non capturée, avant la fin du programme Oui, ca c'est facile.
Dans le vue qui liste les points d'arrêt > Tu as un bouton en haut à droite (de tete, je crois que l'icone est un : '!') > Tu peux choisir le type d'exception (Tu peux prendre throwable)
- comment peut on savoir quels sont les threads qui font accès simultanés, les 2 stacktraces mises en cause en gros
1. Tu identifie le thread et l'itération qui pose problème. (Celui qui pete actuellement) et tu met un point d'arret dans la boucle.
2. Dans la class HashMap il y a un attribut qui est incrémenté a chaque modification de ta map. Tu met un point d'arret à chaques lignes qui l'incremente.
3. Tu execute ta boucle en pas à pas jusqu'à ce que quelqu'un soit arreté dans la classe HashMap.
4. Tu fait bosser le neurone pour comprendre pourquoi il y a modification de ta liste à se moment, et tu cherche comment gérer correctement ta synchro.
