Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
[D7] - empêcher une appli de se fermer toute seule ?
Salut tous
J'ai une appli qui communique en permanence avec des machines sur des ports com, et de manière aléatoire, l'appli se ferme d'elle même, sans aucun message d'erreur ni avertissement, alors que j'ai blindé mon code de try...except et de logs.
Y a t'il un moyen d'empêcher l'appli de se fermer d'elle même, ou au moins de savoir où et pourquoi elle se ferme ?
Merci
Postes Dév : W7 SP1 / Windev 21 / Delphi 7 Entreprise
Serveur : W2k12 SP1 + SQL 2014 RC2
Connexion : OLE.DB
Malheureusement pas !
Tu n'as aucun log (d'ailleurs, tu as blindé la fonction log aussi ?)
Peut-être une trace dans l' Observateur d'Evènements de Window, tu as parfois des entrées pour des applications qui crash brutalement !
Tu as vérifié la mémoire, le nombre de handle utilisé ? est-ce que ça grimpe au fil du temps ?
Combien de temps, en moyenne, cela crash ?
Aide via F1 - FAQ - Guide du développeur Delphi devant un problème - Pensez-y !
Attention Troll Méchant !
"Quand un homme a faim, mieux vaut lui apprendre à pêcher que de lui donner un poisson" Confucius
Mieux vaut se taire et paraître idiot, Que l'ouvrir et de le confirmer !
L'ignorance n'excuse pas la médiocrité !
L'expérience, c'est le nom que chacun donne à ses erreurs. (Oscar Wilde)
Il faut avoir le courage de se tromper et d'apprendre de ses erreurs
Un crash comme ça, en Delphi, c'est quasiment exclusivement la faute d'une stack overflow.
En tous cas ce sont les seuls cas dans lesquels j'ai pu observer ces symptômes.
sjrd, ancien rédacteur/modérateur Delphi.
Auteur de Scala.js, le compilateur de Scala vers JavaScript, et directeur technique du Scala Center à l'EPFL.
Découvrez Mes tutoriels.
oui, je n'ai jamais autant écrit de try...Envoyé par ShaiLeTroll
Il y a des erreurs "module défaillant msvcrt.dll" et d'autres avec le nom de l'exe. Mais ça ne me parle pas.
Le probléme de cette appli, c'est qu'elle ne fonctionne que chez le client, car je n'ai pas les machines à mon bureau pour reproduire l'environnement de prod.
J'ai passé trois heures mardi sur site devant le PC, et il ne s'est rien passé. Et le prog a ensuite laché plusieurs fois pendant la nuit.
Les opérateurs ne savent pas utiliser un ordi, alors pas question de leur demander d'aller voir les handles ou les ressources en cas de crash.
Et comment puis-je gérer ou empêcher ça ?
J'ai trouvé l'outil madExcept sur le net, je vais l'intégrer à mon projet, et voir les logs qu'il génére.
Postes Dév : W7 SP1 / Windev 21 / Delphi 7 Entreprise
Serveur : W2k12 SP1 + SQL 2014 RC2
Connexion : OLE.DB
J'ai un vague souvenir d'avoir une fois modifié un paramètre dans l'IDE pour allouer plus de mémoire à un programme de traitement de fichiers vectoriels.
C'était en D3 sous W2K.
Est-ce encore d'actualité sous D7 avec XP ?
Postes Dév : W7 SP1 / Windev 21 / Delphi 7 Entreprise
Serveur : W2k12 SP1 + SQL 2014 RC2
Connexion : OLE.DB
Se pourrait-il que ce soit ma TStringlist globale qui sert pour les logs qui finisse par déborder de la pile ?
Postes Dév : W7 SP1 / Windev 21 / Delphi 7 Entreprise
Serveur : W2k12 SP1 + SQL 2014 RC2
Connexion : OLE.DB
ca peut être intéressant, autrement il y a memcheck également, moins complet mais indique clairement la mémoire non libérée.J'ai trouvé l'outil madExcept sur le net, je vais l'intégrer à mon projet, et voir les logs qu'il génére.
euh, une TStringList c'est pas sur le tas ?
la Pile ça serait plus des grosses variables locales genre un tableau fixe d'un bon 1Mo !
Ou alors une récursivité (en général ça se voit assez vite),
mais il en existe de vicieuse comme dans ce sujet Les exceptions feraient des fuites mémoire?
tu n'appelle pas Application.ProcessMessages dans un Timer, et ainsi les appeles à la méthode Timer s'empile ?
Aide via F1 - FAQ - Guide du développeur Delphi devant un problème - Pensez-y !
Attention Troll Méchant !
"Quand un homme a faim, mieux vaut lui apprendre à pêcher que de lui donner un poisson" Confucius
Mieux vaut se taire et paraître idiot, Que l'ouvrir et de le confirmer !
L'ignorance n'excuse pas la médiocrité !
L'expérience, c'est le nom que chacun donne à ses erreurs. (Oscar Wilde)
Il faut avoir le courage de se tromper et d'apprendre de ses erreurs
Je n'ai pas de tableau dans le prog.
La seule variable globale susceptible de contenir bcp de data, c'est la striglist des logs. Les autres sont des entiers qui changent rarement de valeur, et il n'y en a qu'une dizaine.
Je n'ai pas non plus d'application.processmessages nulle part.
Mais l'appli utilise pas mal de timers en effet.
il y en a un qui interroge une machine tous les 1/10 de sec.
un autre qui surveille les réponses emises de la machine en asynchrone, toutes les millisecondes (déclenché uniquement si une réponse est attendue)
un autre qui surveille qu'un dialogue ne tourne pas en rond, et le relance si nécessaire (toutes les 4 sec.)
et il y en a d'autres pour une autre machine, mais bcp moins sollicitée.
Postes Dév : W7 SP1 / Windev 21 / Delphi 7 Entreprise
Serveur : W2k12 SP1 + SQL 2014 RC2
Connexion : OLE.DB
Pourquoi une TStringList pour tes Logs ?
Tu devrais écrire dans un fichier texte directement, ou table de la base (si le bug ne vient pas de la base évidemment), ou encore Trace ETW
Inutile de laisser ça stocker en mémoire !
Tu peux aussi mettre des Niveaux à tes traces comme Debug, Hint, Warning, Error.
Tu n'actives l'écrire dans un fichier qu'à partir d'un certain niveau défini par un fichier de config
Error en prod
Warning lors d'une prod défectueuse que tu souhaites surveiller
Hint\Debug durant le Dev
Pour ce genre de chose, j'utilise des Threads (tant qu'il n'y a pas de visuel et que du traitement, c'est mieux)
Rien qu'afficher un PopupMenu ou un ShowModal, ça peut avoir un impact sur le comportement des TTimer !
Sinon c'est quoi ton histoire de "Dialogue en boucle" ?
Aide via F1 - FAQ - Guide du développeur Delphi devant un problème - Pensez-y !
Attention Troll Méchant !
"Quand un homme a faim, mieux vaut lui apprendre à pêcher que de lui donner un poisson" Confucius
Mieux vaut se taire et paraître idiot, Que l'ouvrir et de le confirmer !
L'ignorance n'excuse pas la médiocrité !
L'expérience, c'est le nom que chacun donne à ses erreurs. (Oscar Wilde)
Il faut avoir le courage de se tromper et d'apprendre de ses erreurs
Parce que le débit est tellement important, genre 1 log toutes les 2-3 ms, que l'accès mémoire me parait être ce qu'il y a de plus rapide, et que les premiers tests que j'ai effectué au début du dév avec des écritures fichiers ou bases ralentissaient l'ensemble du programme.
J'ai quand même un nb max de ligne dans la trace pour limiter la taille totale.
C'est déjà en place, mais avec tous les pbm actuels, je n'ai pas d'autre choix que d'activer toutes les traces possibles, et ça fait du monde.
Pour les threads, je n'ai jamais pratiqué, et ça ma parait être un trop gros truc à mettre en place dans l'état actuel du prog, j'ai peur d'avoir encore plus de points à régler qu'à l'heure actuelle.
Oui, je m'en suis rendu compte, et ça fait partie dse pbm à résoudre, mais je ne vois pas bien comment.
Si la fenêtre principale perd le focus trop logntemps, les timers s'arrêtent, et du coup l'appli ne fait plus rien et les communications avec les machines sont coupées.
Un dialogue avec une machine passe par 4 ou 5 étapes de question/réponse, les étapes sont regroupées en phases (demande d'état, demande de poids...)
Si une phase dure trop longtemps (plus de 600ms), c'est qu'une étape de dialogue ne s'est pas terminée proprement, donc je relance tout le dialogue de la phase depuis le début.
Sinon, j'en suis venu à me demander si effectivement je n'ai pas une recursivité infinie qqpart.
Faut que je réétudie les appels au traitement principal.
Postes Dév : W7 SP1 / Windev 21 / Delphi 7 Entreprise
Serveur : W2k12 SP1 + SQL 2014 RC2
Connexion : OLE.DB
C'est un bon volume, j'ai déjà eu des applis très gourmande en log aussi, je confirme, cela ralenti, j'avais plafonné à 10000 lignes dans un TRichEdit (avec de la couleur) qui afficher le debug, idem, en quelques minutes, c'était plein !
Mes logs étaient en DB, je devais bien logger 50 à 100 messages par secondes, un débit tout à fait ordinaire pour des batch critique !
Faut pas avoir Peur !
Thread !
Le mieux étant d'avoir une application server, autonome, sans fenêtre, qui se met dans les NotifyIcon et une application cliente qui permet de configurer et d'afficher des infos (communication par message ou TCP\IP, cela permet de déporter le client sur une autre machine)
Tu as un protocole tout à fait normal avec ACQ\NAK\TimeOut, c'est la bonne méthode !
Bonne Fouille !
Aide via F1 - FAQ - Guide du développeur Delphi devant un problème - Pensez-y !
Attention Troll Méchant !
"Quand un homme a faim, mieux vaut lui apprendre à pêcher que de lui donner un poisson" Confucius
Mieux vaut se taire et paraître idiot, Que l'ouvrir et de le confirmer !
L'ignorance n'excuse pas la médiocrité !
L'expérience, c'est le nom que chacun donne à ses erreurs. (Oscar Wilde)
Il faut avoir le courage de se tromper et d'apprendre de ses erreurs
Je viens de remplacer tous les appels directs à la procédure de traitement principal par un déclenchement de timer (un de plus). Celui appelle la procédure principale au bout de 2 ms. Cela devrait permettre de couper court à toute récursivité.
Je test en prod demain toute la journée. On verra ce que ça donne.
Sinon, le coup de faire une appli client-serveur est une bonne idée.
J'y songerai sérieusement si je ne m'en sors pas avec le code actuel.
Concernant les logs, le TString de 5000 lignes plein à craquer sauvé dans un fichier fait 250K max.
Postes Dév : W7 SP1 / Windev 21 / Delphi 7 Entreprise
Serveur : W2k12 SP1 + SQL 2014 RC2
Connexion : OLE.DB
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager