Dans un projet Delphi 7, nous avons installé FastMM. Peu de temps après, nous avons remarqué que l'une des formes commençait à émettre un message d'erreur abstrait à proximité. J'ai débogué cela largement et je ne trouve pas la raison jusqu'à présent. La raison habituelle de ce message d'erreur ne semble pas s'appliquer ici. L'application ne définit pas les classes abstraites. J'ai également cherché le formulaire pour une éventuelle utilisation de TStrings ou quelque chose comme ça. Plus important encore, nous n'avons pas (Eh bien, nous pensons que nous n'avons pas changé) apporter des modifications à ce formulaire. Cela vient de cassé.
Si la réponse à ces questions n'est pas non plus, je vais continuer à rechercher un appel de méthode non immenté, soulagé que je ne manque pas quelque chose d'autre.
5 Réponses :
S'il y a une corruption de mémoire, toutes sortes d'erreurs peuvent être soulevées et il est très difficile de trouver la cause.
Pour répondre à vos questions: 1) Oui, une erreur abstraite peut également être provoquée par la corruption de la mémoire, et 2) Oui, l'activation de FastMM peut rendre les bugs visibles qui ne passaient normalement pas inaperçus (mais doivent toujours être fixes).
Quelques conseils généraux pour trouver des erreurs de mémoire:
+1. J'ajouterais 5. Allumez des astuces et des avertissements (et fixez-les quand ils se produisent)
@Kenwhite: Absolument. Et je ferais que 1. Allumez les astuces et avertissements ... , mettez l'accent sur 1. :-)
@Kenwhite a ajouté :-) Seul problème est que, dans le code hérité, il pourrait y avoir des centaines d'avertissements et les fixer (incorrectement) risquer d'introduire de nouveaux bugs. Donc, il doit être fait avec soin.
Relatif au numéro 2. Cela "seulement" provoquera une fuite de mémoire, pas d'accès aux violations.
Pour résoudre le problème de l'Escapevelocity, je me concentrerais sur 4.
Dans ce cas particulier, je remplacerais également tout. Gratuit avec FreeandDnil ().
Je me concentrerais sur # 4. Il doit également réparer tous les avertissements! Le compilateur est sérieux à ce sujet. Cela ne poserait pas un avertissement sans raison valable. Corrigez cela et vous allez probablement résoudre votre problème.
"Cela vient de briser" - c'était probablement toujours brisé mais maintenant vous savez.
J'ai vu des problèmes lors de la fermeture d'un formulaire dans le cadre d'un événement de bouton. Le formulaire est détruit puis le reste des messages du bouton est expédié à un bouton non plus long. La méthode de sortie évite cela par (à partir de la mémoire) en affectant un message WM_Close Retour au formulaire
Votre réponse m'a juste aidé. J'ai eu un bouton qui s'est supprimé et ajouté de nouveaux boutons. Truc était de définir un sémaphore pour recharger une sortie de code de bouton après.
Vous pouvez essayer d'ajouter u_dzabstracthandler à votre projet. Il devrait augmenter l'erreur abstraite où la méthode a été appelée, il est donc plus facile de le déboguer. Bien sûr, cela ne vous aide que lorsque l'erreur se produit lors de l'exécution du débogueur.
https: / /osdn.net/projects/dzlib-tools/scm/svn/blobs/head/dzlib/trunk/src/u_dzabstracthandler.pas
Comment l'installer? Vous venez de mettre l'unité dans la liste des utilisations du projet?
Oui, aussi simple que cela.
Réponse à la question 1 "Y a-t-il d'autres causes possibles pour cette erreur en plus d'essayer d'appeler une méthode non implémentée?"
Oui. C'est ce qui a causé dans mon cas une erreur abstraite: Ceci a fonctionné lorsque l'expéditeur était un tbutton mais a soulevé l'erreur (bien sûr) lorsque l'expéditeur était autre chose (comme Taction ). C'était évidemment ma faute. J'aurais dû utiliser "comme" au lieu d'une typaste dure. Réponse à la question 2: Oui. J'ai vu cela se produire aussi. Nous devrions être très clairs que cela ne signifie pas que Fastmm est buggy. Le bug était "dormant". Fastmm ne déclencha que. Assurez-vous qu'un objet n'est pas utilisé après avoir été libéré (ou avant
a été créé)
En outre, dans quelques cas, tout le projet a été foutu et j'ai eu l'erreur abstraite. Rien n'a fonctionné tant que j'ai supprimé le fichier DPROJ. Il suffit de faire un comparateur entre votre fichier dproj actuel et celui de votre dos et vous verrez comment l'IDE F **** up the Fichier. Vous devez également corriger tous les avertissements que les spectacles du compilateur! Le compilateur est sérieux à ce sujet. Cela ne poserait pas un avertissement sans raison valable. Correction de cela et vous allez probablement résoudre votre problème. Dans ce cas particulier, je remplacerais également tout
En fait, vous devriez vous fier à FastMM encore plus pour trouver votre problème. Switch Fastmm en mode de débogage complet pour cela. Cela vous aidera avec:
gratuit avec freeandnil () .
Pourrait être que l'une de vos fonctions / procédures abstraites dans la classe de base n'est pas implémentée;
Essayez ceci: p>
EG P>
type
TBaseClass = class (TObject)
public
procedure DoSomething; virtual; abstract; //not implemented procedure
end;
type
TInheritedClass = class (TBaseClass)
public
procedure DoSomething; override;
end;
//Implementation
procedure TInheritedClass.DoSomething;
begin
//your code
end;
J'ai eu une "erreur abstraite" lorsqu'un formulaire a été créé, il arrive généralement lorsque vous créez un formulaire (formulaire1), ajoutez des composants, etc., puis créez un autre formulaire (form2) qui hérite de former 1, sauvegarde tout, tout va bien, Maintenant, si vous modifiez Form1 (Ajouter un composant, modifier la propriété composante ...) Enregistrer et reconstruire, lorsque le formulaire2 est créé -> BAM, erreur abstraite, depuis lors, j'ai toujours évité de former le héritage dans la conception.