Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!
erstmal noch nachträglich Frohes Neues! Ich hab euch noch nicht vergessen. Wir haben hier nur gerade die letzten Wochen in unserem Projekt laufen und deshalb mehr als nur Stress. Wochenend-Arbeit inklusive
Ich will nur mal einen schweren Bug melden, weil man dazu gar nichts im Netz findet... Er tritt nur bei LV 8.5 in Kombination mit Realtime 8.5 auf. Aus bisher noch ungeklärter Ursache (wohl irgendeine bestimmte Kombination von Funktionen im Blockdiagramm) gibt es einen "fatalen internen Error" in der protocolsupp.cpp line 3244, der zum kompletten Absturz von LV führt. Er tritt immer dann auf, wenn man ein VI debuggen will, also Breakpoints, Pause-Knopf, Conditional Probes usw. verwendet.
NI weiß von diesem Fehler und wird ihn mit LV 9.0 beheben. Es ist aber bisher kein Bugfix für 8.5 geplant. Leider wissen sie auch nicht, welche Ursache zu dem Fehler führt, so dass man ihn vermeiden könnte. Nach ein bisschen "rumweinen" ist es mir gelungen, NI soweit zu bringen, 10 Leute des Core-Development-Teams mit diesem Problem zu beschäftigen. Sie haben gestern abend bis um 10 gearbeitet und werden heute wieder ausschließlich daran sitzen... (Wenn also die neue LV-Version etwas später kommt, dann liegt es an mir)
Falls es Neuigkeiten diesbezüglich gibt, melde ich mich wieder. Ansonsten bleibt mir nur abzuwarten, weiterhin das Debuggen mit Indicators und temporären Wait-Schleifen durchzuführen, und ein bisschen hoffen. Und natürlich euch zu wünschen, dass ihr davon verschont bleibt!
' schrieb:NI weiß von diesem Fehler und wird ihn mit LV 9.0 beheben.
Zitat:Leider wissen sie auch nicht, welche Ursache zu dem Fehler führt, so dass man ihn vermeiden könnte.
"keine Ursache bekannt" und "beheben" - widerspricht sich das nicht?
Zitat:Nach ein bisschen "rumweinen" ist es mir gelungen, NI soweit zu bringen, 10 Leute des Core-Development-Teams mit diesem Problem zu beschäftigen. Sie haben gestern abend bis um 10 gearbeitet und werden heute wieder ausschließlich daran sitzen... (Wenn also die neue LV-Version etwas später kommt, dann liegt es an mir)
Oder an den Zehntausend anderen, die sich mit genau solchen "Features" rumschlagen müssen.
Zwei Features von meiner Seite. Ein seit gestern neues Feature (ohne LV-Absturz): Bei einem XY-Graph auf strict-typisierter Registerkarte kann man die Größe des Felder für die Achsbeschriftung in der Achslegende nicht ändern. Die Schrift selbst kann man ändern, nicht aber das Feld, in dem der Name steht => Nur die obere Hälfte des Namens sichtbar. Lösung: XY-Graph raus auf FP schieben - Größe anpassen - wieder reinschieben und funktioniert.
Zweites Feature, jetzt mit LV-Absturz - aber ohne jedwede Meldung etc: der DLL-Knoten an sich funktioniert bei Rückgabe eines Pointers auf Array-Handle nicht - oder nicht richtig. Jedenfalls hab ich damit auch schon Bluescreens, wenn auch nur wenige, erlebt.
Von mir aus kann sich NI noch zwei Jahre Zeit lassen mit einer neues Version - wenn die denn dann endlich mal weniger Fehler hat. Es müssen ja nicht keine sein, wenige statt viele wäre ja schon ein Fortschritt.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
' schrieb:"keine Ursache bekannt" und "beheben" - widerspricht sich das nicht?
Ok, da gab ich dir Recht. Hab das etwas schlecht formuliert. Zweiter Versuch: Sie wissen nicht, was der Auslöser für diesen Error ist. Sie wollen aber ab 9.0 die Wirkung beseitigen. Das kann man ja machen, indem man einfach diesen Error abfängt und LV eben nicht abstürzen lässt...
' schrieb:Von mir aus kann sich NI noch zwei Jahre Zeit lassen mit einer neues Version - wenn die denn dann endlich mal weniger Fehler hat. Es müssen ja nicht keine sein, wenige statt viele wäre ja schon ein Fortschritt.
Jetzt bist du aber ein bisschen hart, wie ich finde. Schwere Fehler sind nicht akzeptabel und sollten schnellsmöglichst mit Bugfixes behoben werden. Da hat NI noch Nachholebedarf... Aber kleinere Bedienfehler, die die Weiterarbeit nicht wirklich behindern, wie das von dir beschriebene Achsen-Label-Problemchen, sehe ich nun auch als allerunterste Priorität an. Ich kann jedenfalls damit leben, wenn man ab und zu mal so paar kleine Kniffe anwenden muss, und ich dafür schnell eine neue Version mit tollen neuen Features bekomme...
Also ich bin momentan froh, dass ich meine Projekte noch nicht auf 8.5 umgestellt habe. Wenn ich hier und in anderen Foren so lese, was da für Bugs mit teils heftigen Abstürzen so drin sind, da gehört die 8.5er Version mal wieder zu den Versionen, von denen man bis zum Update auf 8.5.1 (hoffentlich kommt es...) wohl besser die Finger lässt.
MfG, Jens
Wer die erhabene Weisheit der Mathematik tadelt, nährt sich von Verwirrung. (Leonardo da Vinci)
!! BITTE !! stellt mir keine Fragen über PM, dafür ist das Forum da - andere haben vielleicht auch Interesse an der Antwort!
' schrieb:Das kann man ja machen, indem man einfach diesen Error abfängt und LV eben nicht abstürzen lässt...
Das ist so einfach nicht.
Wenn LV jetzt noch keinen anständigen Try/Except hat, dann werden die ihn auch in LV9 nicht haben. Was die Sache besonders schwierig macht ist der Memorymanager. Der wenn Fehler macht - wo soll LV denn weitermachen nach dem Abfangen eines Fehlers? Oder falsche Handle, oder falsche Pointer. Wenn der Fehler mal unterhalb einer bestimmten Codeschicht auftritt ist eben alles verloren. Da helfen nur Methoden wie vor 30 Jahren auch: Sourcecode rechtzeitig sichern.
Ich gehe davon aus, die haben einen anständigen Try/Except. Das Problem sind die diversen Module, die alle intuitiv arbeiten sollen. Da ist schnell mal ein Fehler reinprogrammiert. Wie eben bei dem DLL-Knoten. Da gibt es unzählige Möglichkeiten, Daten zu übergeben. Und wenn da eine der Hundert nicht richtig getestet wird, und eben nur einer von 1000 Programmierern genau diesen einen Fall haben will - der hat dann Pech.
Ich schreib seit 30 Jahren Software, ich kann mir vorstellen, was die armen LV-Entwickler für Probleme haben. Und dann auch noch Windows im Hintergrund. Da ist es kein Wunder, wenn die lieber PXI als PCI haben wollen.
Eigenlich muss man froh sein, dass die Sache überhaupt so gut geht. Respektive dass Features durch Tricks umgehbar sind. Bei Millionen von (echten) Features, die dieses System hat, trifft halt jeder irgendwann mal einen, der nicht so ganz nach Wunsch geht. Da muss man durch.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
28.01.2008, 09:14 (Dieser Beitrag wurde zuletzt bearbeitet: 28.01.2008 09:32 von rolfk.)
' schrieb:"keine Ursache bekannt" und "beheben" - widerspricht sich das nicht?
Oder an den Zehntausend anderen, die sich mit genau solchen "Features" rumschlagen müssen.
Zwei Features von meiner Seite. Ein seit gestern neues Feature (ohne LV-Absturz): Bei einem XY-Graph auf strict-typisierter Registerkarte kann man die Größe des Felder für die Achsbeschriftung in der Achslegende nicht ändern. Die Schrift selbst kann man ändern, nicht aber das Feld, in dem der Name steht => Nur die obere Hälfte des Namens sichtbar. Lösung: XY-Graph raus auf FP schieben - Größe anpassen - wieder reinschieben und funktioniert.
Zweites Feature, jetzt mit LV-Absturz - aber ohne jedwede Meldung etc: der DLL-Knoten an sich funktioniert bei Rückgabe eines Pointers auf Array-Handle nicht - oder nicht richtig. Jedenfalls hab ich damit auch schon Bluescreens, wenn auch nur wenige, erlebt.
Wie tust Du das denn mit dem Array Handle? Wenn Die DLL nicht LabVIEW Memory Manager Funktionen verwendet um so ein Handle anzulegen, und die Informationen im Handle auch noch nicht genau einfüllt, kann das ganz einfach nicht gehen. Ein Handle ist nicht nur einfach ein Pointer auf einen Pointer. Es ist ein Pointer auf einen Pointer auf eine Datenstruktur im Speicher (an die dann noch die Userdaten angehängt sind) die nur durch dieselbe Memory Manager Instanz angelegt werden kann, die dieses Handle später auch wieder resized/dealloziert. Das ist kein Bug von LabVIEW sondern ganz einfach eine Eigenheit des Datentyps LabVIEW Handle und durch C diktiert.
Und ja, es gibt einen Try/Except Handler um den Bibliotheksknoten. Der gibt Dir diese liebe nette Dialogbox die Dir mitteilt dass die DLL eine Exception ausgelöst hat und Dich freudnlich bittet alles abzusichern und neu zu starten. Da der Code in der externen Bibliothek völlig ausser Kontrolle von LabVIEW steht ist das so ziemlich die einzige mögliche Variante. LabVIEW kann nicht mal beginnen zu vermuten was die DLL falsch gemacht hat und schon gar nicht wie man das eventuel beheben könnte oder müsste.
Nach der Rückkehr von der DLL, wo scheinbar Dein Fehler passier, wird der Code vielleicht nicht mehr mit einem Try/Exception geschützt. LabVIEW kommt von einer C Programmierung und wurde erst in Version 6.0 C++-isiert. Dabei wurden alle Sourcemodule nach *.cpp umbenannt so dass der C++ Compiler damit benüht wurde statt dem Standard C Compiler. Der Code der bis dahin aber in Standard C geschrieben worden war blieb so und das mit gutem Grund. Eine komplette Neuentwicklung mit C++ Code hätte Jahre gedauert und wäre kaum ohne riesige Kompatibilitätsprobleme gegangen. Und die Art und Weise um Crashes zu vermeiden war bis dahin, um möglichst für alle Eventualitäten gerüstet zu sein und explizite Parametervalidisierung und dergleichen zu machen und ich denke mal dass das selbst heute in den neueren in C++ geschriebenen Modulen noch oft so getan wird. Es ist immer einfacher Fehler im vorhinein abzufangen als später in einer Exceptionroutine mühsam zu versuchen alles doch noch in Ordnung zu bringen.
Aber selbst wenns nach der Rückkehr von der DLL ein Exceptionhandling gäbe, bei Memory Manager Fehlern hört es ganz einfach auf. Da kann man nur noch hoffen dass das Environment noch nicht so beschädigt ist, dass man zumindest noch die Arbeit ohne Korrumptionen speichern kann, aber viele Checks im Memory Manager sind ganz einfach asserts(), beispielsweise wenn Du ihm ein Pseudohandle unterzuschieben versuchst, dass nicht durch eben diese Instanz des Memory Managers erzeugt wurde.
Erst mal Danke, Rolf, für deine interessanten Erleuterungen.
' schrieb:Wie tust Du das denn mit dem Array Handle?
Guckst du diesen Thread. Da ist das offensichtliche Problem mit dem DLL-Knoten beschrieben - und für meine Zwecke ausreichend gelöst.
Zitat:bei Memory Manager Fehlern hört es ganz einfach auf. Da kann man nur noch hoffen dass das Environment noch nicht so beschädigt ist, dass man zumindest noch die Arbeit ohne Korrumptionen speichern kann,
Dadurch bin ich ja auf den Gedanken gekommen, dass meine Abstürze irgendwie mit dem MemoryManager (respektive mit den vom ihm verwalten Speicherbereichen) zusammen hängen müssen. Und die Lösung des Problems, wenn es denn die Lösung ist, ja noch viel mehr.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
' schrieb:bis zum Update auf 8.5.1 (hoffentlich kommt es...)
Es kommt - und zwar bald. Ich werde hoffentlich morgen früh eine Vorabversion in meinem Briefkasten haben. Dann bin ich mal gespannt, ob der Fehler - wie gestern am Telefon versprochen - auch wirklich raus ist.
"Vorabversion" heißt hier jetzt angeblich: Fertig gecoded, fertig getestet und gedebugt, aber noch nicht die Liste der gemeldeten Bugs durchgegangen, ob auch wirklich alle behoben sind. Ich versuche daran zu denken, meine Ergebisse zu posten...
BTW: Interessante Einblicke in die LV-interna hier
