INFO: Dieses Forum nutzt Cookies...
Cookies sind für den Betrieb des Forums unverzichtbar. Mit der Nutzung des Forums erklärst Du dich damit einverstanden, dass wir Cookies verwenden.

Es wird in jedem Fall ein Cookie gesetzt um diesen Hinweis nicht mehr zu erhalten. Desweiteren setzen wir Google Adsense und Google Analytics ein.


Antwort schreiben 

protocolsupp.cpp



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!

28.01.2008, 09:14 (Dieser Beitrag wurde zuletzt bearbeitet: 28.01.2008 09:32 von rolfk.)
Beitrag #6

rolfk Offline
LVF-Guru
*****


Beiträge: 2.305
Registriert seit: Jun 2007

alle seit 6.0
1992
EN

2901GG
Niederlande
protocolsupp.cpp
' schrieb:"keine Ursache bekannt" und "beheben" - widerspricht sich das nicht? Blink

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.

Rolf Kalbermatter

Rolf Kalbermatter
Technische Universität Delft, Dienst Elektronik und Mechanik
https://blog.kalbermatter.nl
Webseite des Benutzers besuchen Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
30
Antwort schreiben 


Nachrichten in diesem Thema
protocolsupp.cpp - monoceros84 - 24.01.2008, 11:53
protocolsupp.cpp - IchSelbst - 24.01.2008, 15:27
protocolsupp.cpp - monoceros84 - 25.01.2008, 09:05
protocolsupp.cpp - jg - 25.01.2008, 09:53
protocolsupp.cpp - IchSelbst - 25.01.2008, 12:21
protocolsupp.cpp - rolfk - 28.01.2008 09:14
protocolsupp.cpp - IchSelbst - 28.01.2008, 10:02
protocolsupp.cpp - monoceros84 - 30.01.2008, 22:04

Gehe zu: