Erreur DAbort 0xF50EFD7B in MemoryManager.cpp

[Michael87000]

Bonjour,

Je viens vers vous, car j'ai un souci récurrent lors de la compilation de mon application. Suite à la réalisation de la construction, labview me signale que tout s'est bien déroulé.

Toutefois dès que j'execute l'application ainsi généré, j'ai une erreur Crash Reporter qui apparait.

Quelqu'un a déjà connu ce genre de complication, et aurais une piste à m'apporter ?

J'ai déjà essayer les différents possibilités trouvées dans le support :

-Compilation de masse

-Suprresion du cache de compilation

-Reboot de la machine / de labview

-Nettoyage des dossiers temporaires.

Je joins en pièce jointe le screen shot de l'erreur et le rapport NI associé en espérant que quelqu'un est une solution à m'apporter.

Cordialement,

MC.

[TiTou]

jamais vu ça... il y a quoi de spécial dans ton appli?

essaie de déscativer/retirer différentes partiesm rebuild et tests ton EXE pour essayer de trouver de quelle partie du code vient le soucis...

Bon courage

[Desruelle_luc]

salut ton exe est MI_Acceptance_Tools?

il y a une erreur dans la gestion de la mémoire :

utilises-tu la structure DVR? ou autres structures "évoluées"?

tu flush des tableaux? des piles? registre à décalage?

tableau initialisés à une taille "dingue"?

buffer de graph?

tu fais quoi?

sinon  tu fais comme

---

TiTou a écrit :

essaie de déscativer/retirer différentes partiesm rebuild et tests ton EXE pour essayer de trouver de quelle partie du code vient le soucis...

---

[Michael87000]

---

Desruelle_luc a écrit :

salut ton exe est MI_Acceptance_Tools?

il y a une erreur dans la gestion de la mémoire :

utilises-tu la structure DVR? ou autres structures "évoluées"?

tu flush des tableaux? des piles? registre à décalage?

tableau initialisés à une taille "dingue"?

buffer de graph?

tu fais quoi?

---

Oui il s'agit bien du nom de mon application.

Il s'agit d'une application complexe permettant le pilotage et l'acquisition de données sous différents protocoles.
J'utilise quasiment tous les types de structures et de variables dans mon programme (cadencé, registre à décalage, boucle parallèle), et énormément de variable globale.

En quoi la gestion de la mémoire diffère entre le mode appliquatif (code compilé et utilisation du run time) et la version développeur ? En effet, ce n'est pas la première fois que des soucis apparaissent une fois le code compilé. Sachant que je suis le 3 ème développeur sur 5 ans à améliorer / maintenir ce code complexe, des précisions sur cette gestion pourrait me permettre d'identifier les points de faiblesses plus rapidement.

Je vais donc faire comme le signaler Titou du pas à pas, même si cela ne m'enchante pas car labview met environ 20 minutes à compiler mon programme....

Merci pour vos réponses en tout cas.

[Desruelle_luc]

---

Michael87000 a écrit :

ce n'est pas la première fois que des soucis apparaissent une fois le code compilé. Sachant que je suis le 3 ème développeur sur 5 ans à améliorer / maintenir ce code complexe, d

---

1) pas la première fois : les autres fois, le problème était causé par? Depuis quand as-tu le problème? sur un gros projet, tu dois compiler reguliérement ton code afin de ne pas avoir ce type de problème

2) vous utilisez un logiciel SCC, source code control? tu peux revenir sur d'autres versions? si oui, tu vas identifier rapidement le vi en erreur, si non passe au N°3

Mais sur un gros projet, mulit-développeurs : il faut un logiciel de gestion du code source!

cf la très belle présentation :Le logiciel ne se limite pas au code LabVIEW + Les outils qui Nous veulent du bien

3) si tu n'as pas de SCC, depuis quand le problème est-il apparu? qu'as-tu modifié? dans le journal du lisez-moi qu'elles sont les modifications? As-tu des backup? peux-tu identifier la version qui "bug" Tu prends le backup semaine N-1, N-X jusqu'à identification d'une version sans problème, et tu analyses.

[Desruelle_luc]

pour info, une recherche sur google retourne beaucoup de lien, par exemple

LabVIEW 2013 Bug Fixes

The following items are the IDs and titles of a subset of issues fixed between LabVIEW 2012 SP1 and LabVIEW 2013. If you have a CAR ID, you can search this list to validate that the issue has

been fixed.

403235 — DAbort 0xF50EFD7B in MemoryManager.cpp when auto-indexing a 2D waveform.

[Desruelle_luc]

sinon il y a LabVIEW Internal Errors (Failure in XXX.c / XXX.cpp at line YYY)

Problem:
I received a LabVIEW Failure in XXX.c / XXX.cpp at line YYY message. What happened and how do I fix it?

Solution:
You can find specific information about your error by visiting the LabVIEW Internal Error Support Page.

[Desruelle_luc]

DAbort : A LabVIEW internal error provides an indication that a condition exists that prevents LabVIEW from continuing execution. Generally, LabVIEW reaches points in its internal code where it checks to determine if certain conditions are valid. Under normal circumstances, these conditions are indeed met, and LabVIEW is equipped to handle them. If they are not valid, LabVIEW reports an internal error 

LabVIEW reports the internal error and shuts down because to do otherwise would be to risk corrupting any VIs in memory. There are many causes of internal errors. For this reason, it is helpful to know the steps that lead to the error so that LabVIEW can be modified to account for this condition in future releases. In LabVIEW 7.0 or later, when LabVIEW is restarted you will be prompted to investigate the internal error. By doing so you send National Instruments the error along with the error log. This simplifies the process of reporting errors so that any problems found can be studied and resolved in future releases. To enable or disable the prompt to investigate errors, select Tools»Options»Debugging»Prompt to investigate internal errors on startup.

[Michael87000]

Bonjour,

---

Michael87000 a écrit :

ce n'est pas la première fois que des soucis apparaissent une fois le code compilé. Sachant que je suis le 3 ème développeur sur 5 ans à améliorer / maintenir ce code complexe, d

---

1) pas la première fois : les autres fois, le problème était causé par? Depuis quand as-tu le problème? sur un gros projet, tu dois compiler reguliérement ton code afin de ne pas avoir ce type de problème

Une des premières apparitions d'erreurs étaient dû à un noeud de Raz des valeurs par défaut au démarrage de mon application, ce qui a été corrigé en enlevant tout simplement le noeud de propriétés car au démarrage, il va de soit que la face avant se trouve aux valeurs par défaut.

2)

En effet, je suis d'accord avec toi, il faut qu'en environnement multi développeur le programme soit géré en contrôle source, mais faut il encore que l'on te donne les moyens de faire cela.

A ce jour, j'ai souhaité mettre en place un contrôle de source avec Clear Case, malheureusement, la stratégie de départ de ce projet ne me permet pas de faire le transfert aisément (gestion par appel à vi dynamique incompatible avec la séparation du code compilé et du code source).

Ne t'inquiète pas, la méthodologie de travail me permet aisément d'isoler les bouts de code pouvant poser problème, ce qui me permettra à coup sur d'enlever le code malencontreux.

Il était juste intéressant pour moi d'apprendre si cela existe une méthode pouvant me permettre de détecter les points de faiblesse présents dans les vis réalisés par mes prédécesseurs, afin de corriger ceux-ci avant que ça lache....

 3)

 Si j'ai posté sur le forum, c'est que j'avais déjà fait la totalité des liens renvoyés par le moteur de recherche et que ceux-ci ne répondait pas à mon problème.

 En, complément d'information, je travaille sous labview 2011 ce qui ne me permet malheureusement pas de profiter des dernières corrections de bug et amélioration du compilateur labview.

4) Question toujours en suspend, si quelqu'un à la réponse :

En quoi la gestion de la mémoire est différente entre une application en mode run time et en mode développeur ?

Pourquoi un code peut s'exécuter correctement en mode développeur sans aucune mise en garde et erreur, et faire un échec critique dès le démarrage en run time ?

Merci en tout cas d'avoir pris le temps de me lire, et de participer au sujet.

[Desruelle_luc]

---

Michael87000 a écrit :

Une des premières apparitions d'erreurs étaient dû à un noeud de Raz des valeurs par défaut au démarrage de mon application, ce qui a été corrigé en enlevant tout simplement le noeud de propriétés car au démarrage

---

très étrange. Je pense qu'il provoque le problème, mais n'est pas le problème.