Discussion :

[_Eric_]

Bonjour,

j'ai une expression régulière qui lève une exception lorsque le texte source dépasse un certain nombre de caractère.
Il s'agit d'une StackOverflowError, sans numéro de ligne et sans explication claire.
Je ne comprend pas pourquoi cette erreur apparaît, peut-être avez vous une idée...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
		Pattern pattern = Pattern.compile("<BLOC>(\\s|.)*</BLOC>");
 
		StringBuffer txt = new StringBuffer();
		txt.append("<BLOC>");
		// exception avec i > 800
		for (int i=0; i<801; i++)
			txt.append("a");
		txt.append("</BLOC>");
 
		Matcher m = pattern.matcher(txt);
		if (m.find(0)) { // Exception in thread "main" java.lang.StackOverflowError
			System.out.println("find");
		}

pour l'exemple je remplis txt avec

<BLOC>aaaaaaaa...</BLOC>

L'exception est la suivante :

Exception in thread "main" java.lang.StackOverflowError
at java.util.regex.Pattern$Loop.match(Unknown Source)
at java.util.regex.Pattern$GroupTail.match(Unknown Source)
at java.util.regex.Pattern$Dot.match(Unknown Source)
at java.util.regex.Pattern$Branch.match(Unknown Source)
at java.util.regex.Pattern$GroupHead.match(Unknown Source)
at java.util.regex.Pattern$Loop.match(Unknown Source)
...ça recommence sur plusieurs dizaines de lignes

ça fonctionne avec 800 caratères mais pas plus.

Au passage cette expression n'est pas de moi et je connais pas la raison du (\\s|.)* dans le pattern plutôt que .*
Avec .* ça fonctionne sans problème, mais je voudrais tout de même bien comprendre cette l'origine de cette exception.

[adiGuba]

Salut,

Au passage cette expression n'est pas de moi et je connais pas la raison du (\\s|.)* dans le pattern plutôt que .*

J'allais justement te demander la même chose

Avec .* ça fonctionne sans problème, mais je voudrais tout de même bien comprendre cette l'origine de cette exception.

Moi aussi. Ou plutôt .*? qui permet de prendre la plus petite chaine correspondante (au lieu de la plus grande).

Par exemple avec la chaine d'entrée : "<BLOC>a</BLOC><BLOC>b</BLOC>" :

• <BLOC>.*</BLOC> te trouvera un résultat : "<BLOC>a</BLOC><BLOC>b</BLOC>"
• <BLOC>.*?</BLOC> te trouvera deux résultats : "<BLOC>a</BLOC>" et "<BLOC>b</BLOC>"

Au passage pour de simple caractère plutôt que le (a|b) j'utiliserais [ab].



Pour en revenir à ton erreur, il s'agit d'un problème de récursion infini (ou trop important en tout cas).
Si mes souvenirs sont bon il existe des regexps "foireuses" qui fonctionnent très bien avec de petites valeurs mais dont le coût est exponentielle, et qui peuvent rapidement consommer un max de ressource voir carrément exploser.

Il semblerait que ce soit le cas ici...



a++

[_Eric_]

Merci pour la précision

.*?

J'ai corrigé l'expression avec .* au lieu de (\\s|.)* (dans notre cas il n'y a qu'un seul groupe de balise possible) donc ça fonctionne pour mon appli, par contre c'est un peu frustrant de savoir que ça peux réapparaitre sans prévenir.
D'autant plus qu'on ne peut pas catcher l'erreur apparemment.

[adiGuba]

J'ai corrigé l'expression avec .* au lieu de (\\s|.)* (dans notre cas il n'y a qu'un seul groupe de balise possible) donc ça fonctionne pour mon appli,

Je te conseillerais quand même d'utiliser .*?, car elle s'arrêtera au premier </bloc> trouvé. Sinon la regexp analysera toutes la chaine jusqu'à la fin pour voir s'il n'y a pas un autre </bloc>...

par contre c'est un peu frustrant de savoir que ça peux réapparaitre sans prévenir.
D'autant plus qu'on ne peut pas catcher l'erreur apparemment.

On peut très bien catcher l'erreur... mais ce n'est pas très propre de faire cela

Pour moi c'est une erreur de développement : la regexp ne supporte pas de données "trop" importante.


a++

[_Eric_]

Effectivement ce doit être plus performant avec le "?"
Et en effet la catch fonctionne également, ne voyant pas ma classe dans la StackTrace j'ai cru que l'erreur passait outre.

Merci pour ces infos.

[adiGuba]

Et en effet la catch fonctionne également, ne voyant pas ma classe dans la StackTrace j'ai cru que l'erreur passait outre.

C'est juste qu'il doit y avoir plus de 10000 appels de méthodes donc le stacktrace est tronqué

a++