LabVIEW Absturz bei falsch konfiguriertem CallLibrary Knoten

[Marcel_Barthel]

Sehr geehrte Damen und Herren, im Anhang befindet sich ein VI, dass LabVIEW ohne vernünftige Fehlermeldung abstürzen lässt. Die Ursache ist eine Fehlkonfiguration in dem CallLibrary Knoten. Dort wurde statt der Calling conversion "stdcall (WINAPI)" die Calling conversion "C" eingestellt. Mit freundlichen Grüßen Marcel Barthel

[Marcel_Barthel]

Das sollte eigentlich ein Bug-Report werden, und nicht hier im Forum landen.

Sorry!

[rolfk]

Das ist kein Bug von LabVIEW sondern vom Programmierer der die Calling Convention konfiguriert. LabVIEW kann in diesem Fall nicht viel mehr tun als auszuprobieren ob es geht, da es abgesehen von Disassemblierung des DLL Codes und entsprechender Analyse des Eintritt- und Ausgangscodes, keinerlei zuverlässige Möglichkeiten hat zu detektieren ob die Calling Convention stimmt (und das wäre richtiges Futter für allerlei Anwälte, da viele Firmen sich auf den Standpunkt stellen, dass Disassemblierung ihres Codes in jeder Form eine Verletzung des Copyrights ist). Das einzige was LabVIEW tun kann ist ein Exceptionhandler installieren, der LabVIEW mitteillt ob ein Fehler aufgetreten ist, wobei dies:

- Nur noch ein "After the Fact" ist, die Korruption des Speichers ist ziemlich sicher in der einen oder anderen Form passiert und ein Restart von LabVIEW ist die einzige vernünftige Vorgehensweise. (Abspeichern von noch nicht abgespeicherten Files in LabVIEW ist dringend abzuraten, da diese nicht nur theoretisch durch die gerade aufgetretene Zugriffsverletzung beschädigt oder korrumpiert sein könnten).

- Im Falle von falscher Calling Convention ist es prinzipiel möglich dass der Stack so durcheinander gerät, dass auch der Exceptionhandler ins Nirvana geht.

- Ob ein Exceptionhandler installiert wird oder nicht wird durch den eingestellten Debugginglevel in der Call Library Konfiguration bestimmt.

[Stephan_D]

Hallo,

wie von Rolf schon beschrieben, handelt es sich hierbei wirklich nicht um einen Bug. Das Problem ist, dass LabVIEW nicht herausfinden kann, welche Call-Convention für eine Funktion in einer DLL nötig ist und diese Einstellung somit vom Benutzer vorgenommen werden muss.

Wird hierbei die falsche Call-Convention gewählt, kann es zu einem Absturtz von LabVIEW kommen, da eventuell Speicherinhalte zerstört werden. Hier hilft leider nur eine Nachfrage bei dem Lieferant der DLL, was für eine Call-Convention verwendet wird oder einfaches Ausprobieren.

Das dieses Verhalten kannt ist, kann man bereits an der Hilfe von LabVIEW sehen. Wenn man nach dem Eintrag "Configuring the Call Library Function Node": sucht, findet man folgenden Hinweis:

Caution  Using the incorrect calling convention can cause an irregular shutdown of LabVIEW.

[Norbert_B]

Im Uebrigen ist das kein Problem, dass irgendetwas mit LV spezifisch zu tun hat.

Der Aufruf einer DLL mit der falschen Calling Convention kann in jeder Programmiersprache zu crashes fuehren:

Delphi

C#

C++

VB 6.0

...

Ich denke, die Liste ist nahezu beliebig erweiterbar....

Norbert

[rolfk]

This is in fact not something that has to do with the Calling Environment but with the fact that DLLs don't have an established way to describe their interface. More modern managed systems such as Java, ActiveX or .Net contain a more or less extensive interface description of the library entry points so that any calling application can verify and even generate access glue code to call that interface.

DLLs do not officially have that (Well the possibility does exist as is demonstrated by LabWindows CVI and LabVIEW generated DLLs, which embed some sort of typelib resource similar to what ActiveX uses, but with the exception of DLLs generated by these two products I have NEVER seen any DLL with such a typelib resource. And the LabVIEW Call Library Node consequently makes use of that typelib resource if it is present!)