#525 Launch creates multiple instances which increases doubling each time - locking system

[Trebly]

Hi,

I had several times problems with the crashes of system or stopping with closing TaskCoach files (problem solved by manual unlock process of the current data file since version ?).
something happens on my system : I suppose several restart without validation.
Then on windows 10 the current windows linked to the main process (the launch confirmation, the main panels - empty - the unlock process) are displayed into the taskbar (see joined screencopy).
This appear near 02/20/2020 (last launch test on 03/05/2020)

Each time I try to launch taskcoach, the number of windows increases - then number seems multiplied by a 2 factor. This leads to lock the system and I have not found any solution to stop this. It seems that because they are linked if the logical process for closing them is not exactly followed (which is impossible) the windows reapper. There are near 50 instances.

To stop this destructive process, I had to rename the tackcoach directory to disallow autotart (no more valid path to access software).

How to clean, to turn around and farther to avoid this problem.

Best regards

Trebly

Joined : screencopy of effects and the taskcoachlog.txt

[Aaron Wolf]

Does removing / renaming the .ini file fix it?

https://answers.launchpad.net/taskcoach/+faq/1061

[Trebly]

Hi,

Thanks, It does.

Two details :
1- TaskCoach launched empty while the soft cannot be accessed
I first forgot to rename the tascoach soft directory to unlock it (the dir renamed previously ""taskcoach.locked").
This have produced when launching taskcoach from Win10 panel, the apparition of the icon into the taskbar and the main Taskcoach panel but empty. I didn't understood immediately, then clicking right I got the list of the files tsk previously used and tried to open the current. I got the circumstances of a no existing any application for the file... After that I have renamed the directory of the soft, I could open normally the file "by using taskcoach". But because I got two instances I had to close the taskcoach panel instance which was, for me, coming from nowhere. What can be the explanation ?

2- The problem of the validation of the application by Security "Bitdefender" : When I launched TaskCoach Bitdefender ask to validate the application to write in my system zone (the level protection that I have defined), the go on lead to a panel with the manually validated applications and validate it. But I could see that previously the application had been listed as destroyed, this because probably I had not validated it (not seen the message or ?). I don't know when this occured (no date of the security event), I am quite sure that it happens after an update of the soft. May be there is a solution so that the application should be automatically allowed.

Best regards

Bernard TREMBLAY (alias Trebly)

[Trebly]

Hi,

Sorry, I got a part of the explanation of the point 2 :
When you rename the directory the corresponding application is marked "deleted" and remains into the list.
When it is renamed again it as to be validated as new while the ancien remains marked "deleted" until not sent to trash. So it seems that there is nothing wrong in this behaviour.
Nevertheless many others applications are not submitted to this validation process.
I have to look more in details into the BitDefender documentation.

Best regards

Trebly

[Aaron Wolf]

I'm sorry, I'm not familiar enough with Windows issues to answer these other questions. Perhaps Jerome knows something, I hope he notices that I'm reassigning this to him. I hope you can get it worked out.

[Jérome Laheurte]

D'après vos captures d'écran vous parlez français, on va peut-être la refaire comme ça parce que je ne comprend pas tout de votre description :)

D'après la capture d'écran "conflicts detected", le fichier .tsk est sur un répertoire partagé du style dropbox non ?

[Trebly]

bonjour,

Non j'ai créé un répertoire « data système \tsk» qui comprend plusieurs fichiers TSK différents.
il y a eu un incident, je pense un arrêt système brutal de sécurité du à un problème de température.
À la suite il y a eu des phénomènes bizarres dans l'interface Windows. Ils m'ont conduit à désactiver taskcoach en attente de solution (mais cela m'a pris du temps postule juger eu beaucoup de choses à faire).
La solution de la suppression du fichier .ini a fonctionné donc je n'ai plus aucun souci.

Cependant peut-être il y a-t-il à faire quelque chose pour éviter que l'incident d'origine ne se produise de nouveau sur ma machine et ailleurs.

3 problèmes distincts semblent s'être manifestés :

• la possibilité de démarrage de taskcoach avec uniquement le fond d'écran et l'impossibilité de charger le moindre fichier *.tsk (à partir de la barre des tâches ou à partir de fichiers dans le navigateur Windows), et ceci alors que l'application était devenue normalement inaccessible par ce que j'avais renommé le répertoire programme. Ceci ne se produisant qu'en lançant manuellement taskcoach à partir de l'écran de démarrage Windows. Le démarrage automatique paramétré dans l'application cachée ne se produisant pas.
• alors que cette première « pseudo instance » est lancée un 2e lancement va ouvrir une 2e icône dans la barre des tâches qui là a va se comporter normalement. Il me faudra quitter (lcette option du menu principal fonctionne) pour revenir un état normal
• alors que le problème est la solution de l'absolu suppression du .ini produisait à la place de l'image réduite de fenêtres courantes une longue liste des 2 mots"Task Coach" (voir la copie d'écran ou la liste occupe toute la hauteur des page). il y a donc là une anomalie qui s'est initiée lors de l'incident et qui n'a pu être réparé qu'avec la suppression du fichier .ini.

C'est évidemment pas immédiat à expliquer en anglais quand on utilise un anglais un peu littéraire. Comme de plus j'ai tendance a m'exprimer parfois en style télégraphique en omettant des articles ; ce n'est pas toujours évident. Pourtant j'écris toujours directement en anglais puis en général j'utilise la traduction automatique inverse qui me permet de me corriger.si

Nota : le clic droit sur l'icône de taskcoach dans la part de tâches fait apparaître la liste des fichiers récents et le clic sur le nom de l'un de ces fichiers ouvre tout à fait normalement une 2e instance.

Le « conflicts detected" est apparu avant que le .ini ait été supprimé. Il me semble qu'il y avait un chargement multiple répétitif d'une défaillance. Il n'y a pas de duplicata de fichiers dans le système et je ne l'utilise pas encore avec one drive.
J'ai pourtant prévu de le faire coupler avec la version Android. Mais je ne m'y suis pas encore attaqué.

Cordialement

Bernard Tremblay (alias Trebly)

nota : mes textes français sont dictés en utilisant Dragon : il s'ensuit parfois des coquilles très bizarres que je ne vois pas à la relecture, d'un autre côté mon expression en français et celle du langage parlé, et son parfois très long quand les choses sont compliquées.

Nota 2 : un moyen plus pratique pour expliquer des problèmes de ce type est l'enregistrement vidéo d'écran avec un partage cloud (en général 4à5Mo la minute et on explique tout en 10 minutes). le problème est la confidentialité de certaines informations qui peuvent figurer et donc que comme sur certains sites (i.e. mozilla) les pièces jointes (un fichier texte donnant l'URL de téléchargement) soient mises en mode confidentiel. Sinon c'est toujours plus compliqué en passant par des mails.

[Jérome Laheurte]

Tout à fait, donner des explications techniques dans une seconde langue peut être lourd; ça n'était pas un reproche :)

Du coup il semblerait que le shutdown ait eu lieu pendant que TaskCoach sauvait un fichier, d'où la présence du .locked je pense; ensuite comme dit l'autre les emmerdes volent en escadrille. Peut-être que la bibliothèque que nous utilisons pour le verrouillage a des problèmes sous Windows 10, il faudra que j'essaye de reproduire ça à l'occasion. Ça va être compliqué vu que je n'ai pas de Windows 10 sous la main...

[Trebly]

Bonjour,

Le problème rebondit. Le phénomène réapparait, je l'explique ci-dessous avec un peu plus de données qui permetront d'avancer à moyen terme et de définir une solution à court terme, j'espère.

Phénomène

Si l'on démarre la machine avec l'application inactivée ("répertoire taskcoach renommé en taskcoach.locked" en fin de session précédente).
Si l'on supprime le .ini et que l'on lance l'application tout se passe bien tant que l'on ne" redémarre pas la machine.
Mais lors d'un "redémarrage" normal du système le problème réapparait (voir mes copies d'écran ou j'ai dépilé les fenêtres), à savoir :
Si on laisse la machine tourner (log et je m'en vais, accidentellement...) je suis arrivé à ce que soient lancées 162 instances (objets fenêtres...) Evidemment on arrive à un épuisement temporaire de ressources (avec un coreI7 2700K et 32Go de mémoire) et des opérations croisées à cause des processus lancés en parallèle lancés sur les mêmes ressources fichiers (le fichier à ouvrir qui est verrouillé) ou les ressources système pures comme la gestion de fenêtres windows.

Les copies d'écran (parfois mes deux écrans joints) fournies montrent :

• une idée des fenêtres ouvertes et au moins 1 exemplaire par type (messages de démarrage, fenêtre principale (vide), message de confirmation pour un "unlock" de fichier, messages d'erreurs), fenêtres que j'ai pour une part dépilées manuellement - (il en reste empilées dans la zone de notification vers laquelle elles convergent très vite)
• L'apparition normale lorsque l'on clique sur l'icône principale "taskcoach" des fenêtres dans la barre de tâche qui correspondent aux 162 runs (process principal et sous process) avec leur titre associé (les principaux font apparaitre le nom de ficher)
• la liste partielle des "taskcoach" ouverts dans le gestionnaire de tâches (162 au total)
• le log correspondant que je pense bien plus parlant que le précédent (ko).

Origine du phénomène ? , suppositions

Une hypothèse serait donc une boucle qui s'installe lorsque après le redémarrage la première instance bute sur la question du fichier resté à l'état verrouillé (y compris redémarrage windows commandé). Il semblerait que s'il n'y a pas de réponse une pile se forme.

Une autre hypothèse est que chaque fermeture sans utiliser le "close application" principal soit mémorisée quelque part comme une "session" en cours interrompue et que toutes les sessions soient relancées automatiquement au redémarrage (qu'elles opèrent sur le même fichier ou non).

Un problème semble se poser avec la mise en veille "semi-profonde" avec arrêt des disques. Une nouvelle instance s'ouvre (mais sans fichier tsk déja ouvert...) et qu'il convient de fermer.

Fonctions en cause, il me semble

• Le problème de la fermeture par windows : Il faudrait que si windows notifie une fermeture imminente que l'application finesse d'écrire ses fichiers et ferme les fenêtres ouvertes, puis ferme le fichier principal avant de rendre la main. Actuellement manifestement si l'on ferme windows le fichier principal tsk conserve sa situation locked par l'instance principale de taskcoach ce qui nécessite, si l'on n'a pas fermé manuellement l'application (très souvent impossible) à la réouverture de confirmer le déverrouillage.

• Le problème de l'arrêt système sans fermeture orthodoxe : dans ce cas la confirmation manuelle du déverouillage est tout à fait justifiée, mais il faudrait pouvoir reprendre la session en cours au lieu d'en ouvrir une nouvelle.

• Le redémarrage avec des instances multiples : On retrouve la même chose dans un très grand nombre d'applications et en particulier multifichiers cf. i.e. les appli MS Office, Libre Office etc. Seule la question du déverouillage fichier est posée mais je suis quasi certain que l'instance ancienne (sur le même fichier tsk) n'est pas éliminée de la pile des "en cours", quand on confirme le déverouillage (ce n'est pas le même sens) il manquerait alors une question " à l'utilisateur "repartir où nous en étions" sur le fichier "x". Dès lors on n'ajoute pas d'instance à la pile, on met simplement à jour. Ceci respecte le multitâche. Evidemment on pose la question s'il y a lieu pour chaque instance différente.

• Les instances en cours sont relancées automatiquement et comme elles concernent le même fichier tsk et qu'il n'y a pas un fichier temporaire par instance semble-t-il (peut-être groupé) c'est automatiquement la pagaille. Voir ci-dessous l'exemple que je cite de MSOffice et libreOffice.

• Evidemment la question se pose de la bibiothèque que vous utilisez pour gérer ces processus car évidemment vous n'avez pas tout réécrit.

• Aujourd'hui je ne trouve aucun moyen pour accéder à ces instances qui correspondent probablement à une soixantaine de relances système exécutées (depuis une réinstallation) et de les désactiver (comme on le fait avec MS Office par exemple qui fait réapparaitre dans la liste des fichiers "en cours" tous les redémarrages où le(s) fichier(s) n'a(n'ont) pas été sauvé(s) avant la fermeture (même si les contenus sont identiques). Ceci d'ailleurs fait perdre beaucoup de temps parce qu'il est nécessaire de comparer les fichiers pour valider avec certitude quel est le bon. Le processus de récupération mis en place dans libreOffice est sur ce plan bien plus ergonomique.

• Pourtant le phénomène des instances multiples ( > 2) n'est apparu que récemment, il y a donc quelque chose qui a bougé pour venir déstabiliser le processus en place qui gérait cette question. Il faudrait trouver la cause pour éviter que cela ne se reproduise même si une solution de dépannage applicable quand l'anomalie se produit peut être trouvée (moins lourde qu'une réinstallation).

Ma question très pratique

Si ce que je suppose est exact, en attendant que le soft soit à niveau pour gérer ce problème, la question est : où et comment supprimer ces instances qui sont restées en cours et se relancent à chaque redémarrage en créant cette gigantesque pagaille (je peux intervenir directement sur un grand nombre de types de fichiers et bases de données) ?

Cordialement

Bernard TREMBLAY (Trebly)

---

Quatre commentaires annexes :

• le "taskcoach.locked" provient d'un rename que j'ai effectué manuellement pour empêcher le lancement de taskcoach au démarrage sans toucher au contenu du répertoire.
• La question de l'expression des problèmes dans une langue étrangère, même si on l'utilise de manière courante est triple parce que il ya
• • le problème de base de l'expression idiomatique et le fait que l'on soit attiré naturellement par les tournures "classiques" scolaires ou littéraires et par celles qui se rapprochent du français tout en étant intelligibles et parfaitement correctes en Anglais (traduction inverse via google trad sans dérive).
• • le problème du vocabulaire et des expression idiomatiques du domaine technique spécifique pour lequel le seul moyen serait de travailler lors des debug sur la version anglaise (c'est parfois possible mais pas toujours) parce que l'on a pas toujours accès aux dictionnaires de l'application et/ou que le changement de langue n'est pas dynamique.
• • Le problème qui s'applique aussi à la langue natale qui est que lorsque l'explication concerne des descriptifs d'écrans et de séquences de manipulations seuls les copies d'écran et même la video sont le secours avant d'appliquer celui au travail interactif (Prise de contrôle et/ou visu à distance)
• Pour ce qui est du test avec Windows10 la solution c'est virtualBox, après l'installation d'un système windows10pro pour test se fait très rapidement.

[Trebly]

Hi,
i have sent a long message five days ago to Jerome.
Here I summarize the content in English.

Actions done recently
1- After performing these operations :

 - rename the taskcoach directory ( to "taskcoach.locked")
 - reboot
 - Delete the .ini file
 - Rename to "taskcoach"
 - Launch of taskcoach

Everything seems to come back in a normal behavior

2- Reboot
Many things get again an erratic behaviour : see the screenshots

Hypothesis on the behavior
An hypothesis is that all sessions which have been stopped without closing the application manually are stored somewhere. Then after a restart they are all reopened (this lead to currently 162 windows opened (near 40 main launches, then system resources exhausted, multiple errors due to percutions of processes, naturally there are multiples "file locked" - t-his while one unique main instance should be running on one unique tsk file) .

Note that I had often previously by automatic system start 2 main windows launched (so two main instances and their sub windows) opened (two main instances) with one of the two empty. I was closing the empty one.

My questions are :
1- How to reset this without if possible to not have to reinstall the whole application ?
2- A way to access to this list of "pending" sessions and to delete the not useful instances ? -- if this happens again
2- How to avoid to this incident to occur again ?

Best regards

Trebly

note : For now the application and my planning are stopped since two week.

Attachments : see previous message.

[Jérome Laheurte]

Yep désolé pour le retard, je bosse sur un autre projet très prenant en ce moment. Merci pour l'analyse détaillée. En ce qui concerne VirtualBox je connais bien entendu mais je n'ai pas de license Windows sous la main, c'est pas gratuit ces trucs-là :)

La piste d'un problème avec la gestion de session me semble pas mal, d'autant que c'est quelque chose qui a toujours été assez gore à gérer sous Windows. Un test intéressant serait de désactiver carrément cette fonctionnalité pour voir si ça arrange les choses, mais du coup il faudrait que je recompile TC, il n'y a aucun setting de prévu pour ça. Je vais fouiller dans les vieux backups, à une époque j'avais une VM Windows pour ce genre de choses, si ça se trouve elle a survécu à mon dernier crash de disque dur.

[Trebly]

Jérome,

Pour windows, il n'y a pas besoin de license pour faire des tests, simplement après quelques lancements il y aura un message (zone notification). Il faut lorque le système demande la clef répondre "plus tard" c'est tout. En revanche bien sur pas de mise à jour. Mais ca suffit pour tester taskcoach et télécharger quelques utilitaires.

Si l'on veut une license pour une VM la licence unique (EOM unique) se trouve a uenviron 20€.
On peut trouver à télécharger une image iso à "graver" qui permet l'installation soit sur une partition soit directement en créant une VM avec virtual box.
Lorsque l'on achete une clef le vendeur donne une url de téléchargement.

Avec vitualbox il suffit de demander de créer une VM à partir de l'iso.
Pour créer une partition bootable on grave sur un media clefs boutable ou SDCard, il faut quelques dizaines de minutes de machine.
En fait rien de vraiment différent par rapport à d'autres systèmes de l'environnement linux.
Je peux te donner une url de téléchargement de l'image, je préfère pour ça passer en mode privé.

Ceci étant en attendant je pense renommer mes répertoires taskcoach courants, reinstaller pour pouvoir utiliser taskcoach qui me manque pour travailler. Je pourrais ensuite rebasculer si des test complémentaires étaient utiles, ceci parce que rien n'est écrit en bdr (je n'ai pas vérifié, mais je peux modifier temporairement des clefs si nécessaire).

Cordialement
Bernard TREMBLAY (trebly)

[Jérome Laheurte]

J'ai retrouvé la VM Windows avec tout l'environnement de dev installé (rien que ça ça m'aurait pris des jours je pense), donc le temps de trouver comment désactiver la gestion de session et j'aurais une version de test. On croise les doigts.

[Trebly]

Bonjour Jérome,

Il y a cepdendant à définir la démarche et des testst préalables :

Choix de la démarche de résolution, il y a deux démarches possibles :
1- A partir de la piste, rechercher dans le code ce qui génére le problème et passer la correction (après les vérifications utiles bien sur).
2- Procéder par test : exemple voir si le problème que je rencontre se reproduit une fois le code relatif à la gestion de sessions modifié. Il me semble que c'est sur cela que tu t'orientes. Si c'est la cas, il faudrait alors :

- vérifier le contenu de la base qui correspond sur ma machine à cette gestion de sessions, retrouver la trace physique des sessions restées ouvertes qui sont relancées.

En effet le problème de l'apparition de phénomène n'est pas je pense facilement reproductible, du moins les conditions sont encore floues. Alors que le redémarrage se déroulait avec souvent deux instances lancées, une valide et l'autre sans fichier tsk ouvert, la pile de ce qui semble être des instances non closes normalement ne générait pas des lancements automatiques au redémarrage, si elles existaient elles restaient muettes ad-vitam. Puis d'un seul coup le phénomène s'est déclenché.
Il faudrait soit suivre la méthode 1 soit qaue je réinstalle et vérifie si le problème réapparait.. Mais évidemment pendant cette phase de test conserver les logs après chaque redémarrage de la machine.

Je pense donc nécessaire :
1- que je te tranmette les données concernées (donc que tu me dises lesquelles)
2- que je réinstalle le produit à fin de pouvoir travailler (c'est une appli opérationnelle qui est arrêtée ce qui gêne mon travail) et de voir si le problème se déclenche en étant particulièrement attentif aux conditions. Mais là tu ne m'a pas dédouané (i.e. si un produit écrit dans la BdR on peut détruire les traces permettant la débogage en réinstallant. Il faut savoir ce qui doit être récupéré pour pouvoir recrééer (reproduire) le phénomène.

Cordialement

Bernard TREMBLAY (Trebly)

---

Note1 : Pour la petite histoire mais aussi des principes de résolution de cas de bugs diffcilles, je possédais un logiciel grands systèmes que je louais. Un "bug" en son temps m'avait couté l'équivalent de 300 000€, ce qui avait à terme été la cause de ma faillite, le bug était un débordement de tableau non testé alors que sa dimension dépendait de données utilisateur (usage imprévisible du logiciel "hors normes"). La limitation était absente des spécifications et du manuel utilisateur. C'est en relisant tout à fait par hasard 15ans plus tard (dans une partie de code que je n'avais pas écrit) que je l'ai trouvé. La question était qu'il n'était pas possible d'effectuer les test et compilations qui auraient été nécessaires (recompiler sur le site d'exploitation - grands systèmes - avec l'option de compil testant tous les indices de tableau et donnant l'adresse du débordement provoquant alors un stop et non un crash).

[Aaron Wolf]

Hi, it's some years later but I'm excited to tell you that https://github.com/taskcoach/taskcoach now has Task Coach updated to Python3! I'm using it myself, and things are working better than ever. Packages are available for some common Linux systems and for Windows (note that it isn't recognized by Windows Smartscreen but can be installed by accepting the warning anyway)

We'd love to have you test the updated program, and post any issues that arise there at GitHub

We won't be continuing with SourceForge, just clearing out old issues and letting people know about the move

Cheers