Discussion :

[Grool]

Bonjour

Je vous fais part d'un bug que je pensais, naïvement, impossible à obtenir.
Terminaison brutale d'un programme avec l'erreur Appel à une fonction virtuelle pure.

Première réaction d'étonnement : Comment appeler une fonction virtuelle pure d'un objet qu'on a même pas pu instancier ?
Après analyse, il s'agit bien d'une instance d'objet dérivé et la backtrace m'indique que le problème survient dans le destructeur de la classe mère.

Là effectivement, c'est plus clair. La couche de la classe dérivée vient d'être détruite et la vtable m'oriente vers une impasse.

Dans mon cas, il ne s'agissait pas d'un appel explicite à la fonction virtuelle depuis le destructeur. C'eût été trop simple.
Cette hiérarchie de classes contient des éléments d'IHM et la classe mère possède un conteneur de widgets.
Or, ces widgets lèvent des événements lorsqu'ils sont sélectionnés, connectés à cette foutue fonction virtuelle.

Lors de la destruction de la classe mère, la destruction des membres entraîne la destruction du conteneur de widgets… qui entraîne la destruction des widgets un par un.
Lors de la destruction du widget sélectionné, il y a sélection automatique du widget suivant, levée d'événement, appel de fonction virtuelle pure => Crack Boom.

[dalfab]

Bonjour,

Il y a quelque part un défaut structurel.

Je comprends le problème comme:
- l'objet est détruit
- le destructeur de l'objet est déroulé
- qui provoque la destruction ou l'appel de fonctions d'autres objets
- un de ces objets détruit ou utilisé appelle une fonction virtuelle pure de l'objet initial (c'est là l'erreur, accéder à un mort). Et comme l'objet est en cours de destruction, la fonction est devenue pure!
Si la fonction n'était pas pure on aurait une utilisation d'un objet en cours de destruction (donc encore en mémoire) qui souvent n'a aucun effet visible, la fonction pure ne fait que mettre en évidence un problème latent.

[Grool]

Je dois vérifier s'il est vraiment pertinent que la fonction liée à l'événement de sélection d'un widget soit virtuelle.
Après tout, si c'est la classe mère qui possède les widgets, il y a de fortes chances que les actions à réaliser lors d'une sélection soient suffisamment communes pour être gérées par la classe mère.

Mais je crains qu'in fine, il y ait un appel à un comportement spécifique à chaque classe dérivée. Ce qui fait que le problème d'appel polymorphique arrivera malgré tout.
Pour l'instant, j'ai circonscrit le problème en déconnectant les événements avant la destruction.

[Bousk]

C'est pour ça que les moteurs de jeu, sdk UI etc un peu gros finissent (quasi) tous par avoir des fonction OnPostInit, OnPreDelete etc qui sont appelés directement après le constructeur / avant le destructeur et le constructeur / destructeur ont des exécutions minimales qui génèrent que peu voire pas de side-effects
OnPreDelete tu déconnectes tout, et dans le destructeur tu réinitialises / nettoies uniquement.