Le problème avec les bugs de type hotspot, c'est que vous devez atteindre le seuil de compilation (par exemple 10000) avant qu'ils ne vous atteignent : donc si vos tests unitaires sont "triviaux", vous ne l'attraperez probablement pas.
Par exemple, nous avons détecté le problème des résultats incorrects dans Lucene, car ce test particulier crée 20 000 index de documents.
Dans nos tests, nous rendons aléatoires différentes interfaces (par exemple, différentes implémentations de répertoire) et les paramètres d'indexation, etc., et le test n'échoue que dans 1 % des cas, bien sûr, il peut être reproduit avec la même graine aléatoire. Nous exécutons également checkindex sur chaque index créé par les tests, ce qui permet d'effectuer quelques tests de sanité pour s'assurer que l'index n'est pas corrompu.
Pour le test que nous avons trouvé, si vous avez une configuration particulière : par exemple RAMDirectory + PulsingCodec + charges utiles stockées pour le champ, alors après avoir atteint le seuil de compilation, la boucle d'énumération sur les écritures renvoie des calculs incorrects, dans ce cas le nombre de documents retournés pour un terme != le docFreq stocké pour le terme.
Nous avons un bon nombre de tests de stress, et il est important de noter que les assertions normales dans ce test passent, c'est la partie checkindex à la fin qui échoue.
Le gros problème est que l'indexation incrémentale de Lucene fonctionne fondamentalement en fusionnant plusieurs segments en un seul : de ce fait, si ces enums calculent des données invalides, ces données invalides sont alors stocké dans le nouvel index fusionné : c'est de la corruption.
Je dirais que ce bogue est beaucoup plus sournois que les précédents bogues de l'optimiseur de boucle que nous avons rencontrés (par exemple, le truc du retournement de signe), https://issues.apache.org/jira/browse/LUCENE-2975 ). Dans ce cas, nous avons obtenu des deltas de documents négatifs farfelus, ce qui permet de l'attraper facilement. Nous n'avons également dû dérouler manuellement qu'une seule méthode pour l'éviter. D'un autre côté, le seul "test" que nous avions initialement pour cela était un énorme index de 10GB de http://www.pangaea.de/ donc il a été douloureux de le réduire à ce bug.
Dans ce cas, j'ai passé une bonne partie du temps (par exemple, toutes les nuits de la semaine dernière) à essayer de dérouler/inclure manuellement diverses choses, en essayant de créer une solution de contournement pour que nous puissions éviter le bogue et ne pas avoir la possibilité de créer des index corrompus. J'ai pu éviter certains cas, mais je n'ai pas pu en éviter beaucoup d'autres... et je suis sûr que si nous pouvons déclencher ce genre de choses dans nos tests, il y aura d'autres cas...
