D'où viennent les crashs de "pur appel de fonction virtuelle" ?

Question

Je remarque parfois des programmes qui plantent sur mon ordinateur avec l'erreur : "appel de fonction virtuelle pure".

Comment ces programmes peuvent-ils même compiler lorsqu'il est impossible de créer un objet d'une classe abstraite ?

Answer 1

Ils peuvent se produire si vous essayez de faire un appel de fonction virtuelle à partir d'un constructeur ou d'un destructeur. Puisque vous ne pouvez pas faire un appel de fonction virtuelle à partir d'un constructeur ou d'un destructeur (l'objet de la classe dérivée n'a pas été construit ou a déjà été détruit), il appelle la version de la classe de base, qui dans le cas d'une fonction virtuelle pure, n'existe pas.

(Voir la démo en direct aquí )

class Base
{
public:
    Base() { doIt(); }  // DON'T DO THIS
    virtual void doIt() = 0;
};

void Base::doIt()
{
    std::cout<<"Is it fine to call pure virtual function from constructor?";
}

class Derived : public Base
{
    void doIt() {}
};

int main(void)
{
    Derived d;  // This will cause "pure virtual function call" error
}

Answer 2

En plus du cas standard d'appel d'une fonction virtuelle depuis le constructeur ou le destructeur d'un objet avec des fonctions virtuelles pures, vous pouvez également obtenir un appel de fonction virtuelle pure (sur MSVC au moins) si vous appelez une fonction virtuelle après que l'objet ait été détruit. Évidemment, c'est une très mauvaise chose à essayer de faire, mais si vous travaillez avec des classes abstraites comme des interfaces et que vous vous trompez, c'est quelque chose que vous pourriez voir. C'est probablement plus probable si vous utilisez des interfaces référencées et comptées et que vous avez un bug de comptage des références ou si vous avez une condition de course entre l'utilisation et la destruction d'un objet dans un programme multithread... Le problème avec ces types d'appels purs est qu'il est souvent moins facile de comprendre ce qui se passe car une vérification des "suspects habituels" d'appels virtuels dans le ctor et le dtor ne donnera rien.

Pour faciliter le débogage de ce type de problèmes, vous pouvez, dans diverses versions de MSVC, remplacer le gestionnaire d'appel pur de la bibliothèque d'exécution. Pour ce faire, vous devez fournir votre propre fonction avec cette signature :

int __cdecl _purecall(void)

et de le lier avant de lier la bibliothèque d'exécution. Cela VOUS permet de contrôler ce qui se passe lorsqu'un appel pur est détecté. Une fois que vous avez le contrôle, vous pouvez faire quelque chose de plus utile que le gestionnaire standard. J'ai un handler qui peut fournir une trace de la pile où le purecall s'est produit ; voir ici : http://www.lenholgate.com/blog/2006/01/purecall.html pour plus de détails.

(Notez que vous pouvez également appeler _set_purecall_handler() pour installer votre gestionnaire dans certaines versions de MSVC).

Answer 3

Voici une excellente explication des causes possibles de ce phénomène :

http://www.artima.com/cppsource/pure_virtual.html

Answer 4

En général, lorsque vous appelez une fonction virtuelle par le biais d'un pointeur suspendu, il est fort probable que l'instance ait déjà été détruite.

Il peut aussi y avoir des raisons plus "créatives" : peut-être avez-vous réussi à couper la partie de votre objet où la fonction virtuelle était implémentée. Mais généralement, c'est simplement que l'instance a déjà été détruite.

Answer 5

Je suppose qu'une vtbl a été créée pour la classe abstraite pour une raison interne (elle pourrait être nécessaire pour une sorte d'information sur le type d'exécution) et quelque chose se passe mal et un objet réel l'obtient. C'est un bogue. Ce seul fait devrait indiquer que quelque chose qui ne peut pas se produire l'est.

Pure spéculation

éditer : Il semble que j'aie tort dans le cas en question. Par contre, certains langages autorisent les appels de vtbl en dehors du constructeur et du destructeur.