Discussions au sujet de NI LabVIEW
Crash LV 2012 (demande confirmation)
Le code ci-joint (snippet) provoque le crash de LV 2012 (12.0f3)
OS : windows X¨P sp3
charger le snippet et "run"
quand l'indicateur "cpt_FOR" passe à 1 ... LV plante.
Quelqu'un peut-il tester et éventuellement confirmer (ou pas)
merci à tous.
Le rapport de bug m'indique un code 0x80000003 ( 0x80000003 = STATUS_BREAKPOINT)
j'ai placé un debugger en arrière plan (Syser) ... Syser prend automatiquement la main sur un INT3 (0xCC)
Et étonnement ... quand LV crash, Syser prend effectivement la main sur ... un INT3 !
Si je remplace cet INT3 par un NOP (0x90) et que je "continue" ensuite ... LV termine normalement son code.
Il semblerait donc (je dis bien il "semblerait") ... que les développeurs de LV2012 (12.0f3) ont "oublié" un breakpoint INT3 dans le code de LV
En tout cas, si c'est pas ça ... ça y ressemble. 
ouadji a écrit :
Le rapport de bug m'indique un code 0x80000003 ( 0x80000003 = STATUS_BREAKPOINT)
j'ai placé un debugger en arrière plan (Syser) ... Syser prend automatiquement la main sur un INT3 (0xCC)
Et étonnement ... quand LV crash, Syser prend effectivement la main sur ... un INT3 !
Si je remplace cet INT3 par un NOP (0x90) et que je "continue" ensuite ... LV termine normalement son code.
Il semblerait donc (je dis bien il "semblerait") ... que les développeurs de LV2012 (12.0f3) ont "oublié" un breakpoint INT3 dans le code de LV
En tout cas, si c'est pas ça ... ça y ressemble.
Ouadji est un grand malade 
De retour avec LabVIEW 2012 ? Ca faisait longtemps
Salut Helmut !
de retour ...
oui, j'ai déménagé ... donc pendant un bon moment, plus le temps de programmer.
"ouadji est un grand malade"
faut pas me faire des compliments comme ça
Bein ... avec un code 0x80000003, j'ai pas pu me retenir longtemps.
J'ai lancé Syser derrière ... et Bingo ... le code de LV comporte un INT3 (en tout cas, au moment du crash, c'est certain)
Et si je remplace (bêtement) cet INT3 par un NOP (pas pu me retenir non plus) ... LV termine ses itérations sans soucis.
De là à "penser" que les développeurs de LV ont "oublié" un breakpoint de test .. y'a pas loin.
Mais bon ... personne ne dira : "oui, c'est vrai, merde, on a oublié un breakpoint" 
En assembleur, cela m'est déjà arrivé plus d'une fois ... alors dans un code comme LV, pourquoi pas.
dommage, je pensais pouvoir décortiquer le fonctionnement des Timed Loop
mais avec ce bug, cela m'empèche de continuer. 
a+ Helmut, et merci pour les Kudos ... ça fait toujours plaisir.
J'ai trouvé quelque chose d'intéressant.
Labview 8.5.1 a également connu des soucis avec les "Timed Loop" ... tout pareil, crash de LV.
Le problème se présentait "uniquement" avec des µPs 4 coeurs ou plus et le fichier incriminé était "lvalarms.dll"
voir ici : http://digital.ni.com/public.nsf/allkb/AF9F8181F6082CFA86257442006D4833
Pour corriger le problème, NI a fourni un fichier lvalarms.dll modifié, ici : http://joule.ni.com/nidu/cds/view/p/lang/fr/id/1048
Avec Syser, j'ai intercepté le crash de LV2012 (code ci-dessous) ... et le fichier incriminé est aussi "lvalarms.dll"
De plus, j'ai un µP 4 coeurs. Cela fait beaucoup de ressemblances !
J'ai donc risqué le coup ...
J'ai remplacé le fichier lvalarms.dll-LV2012 par ce fichier lvalarms.dll corrigé (lien ci-dessus)
Ce fichier "corrigé" n'est en principe pas prévu pour LV 2012, mais pour LV 8.5.1 (qui ne risque rien, n'a rien )
et ... ?
LV 2012 ne crashe plus !
Le Timed Loop semble fonctionner correctement et l'update de l'offset semble lui aussi se faire correctement.
alors ? ... problème déjà connu par NI ? ... mais non répercuté ? (car LV 2011 crashe aussi avec le code ci-dessous)
Dans ce monde de fous, totalement à la dérive, être malade est un plus !
Bonjour Luc, j'espère que tu vas bien 
re-Salut, je vais très bien, comme toujours, actuellement pas trop le temps d'aider sur le forum, mais bon... t'as vu ma signature!? CLA.... lalala
T'as déménagé, mais dans quel monde? surtout dans quel pays?
Je suis content de te lire, t'es en forme
A+
