You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Just coming back from hunting down a use-after-free bug in my code caused by UserEvents.
In summary: Some elements, i.e. notifiers, UserEvents, queues... allow the user to free the memory/reference in LabVIEW. At the same time these are things that one probably holds on for longer than just a single function call.
All I did in my code was release the UserEvent in LV right before the DLL call to my library. In the meantime my lib tried to send some UserEvents and crashed.
Idea:
Test if the memory manager functions to check handles and ptrs (DSCheckHandle, DSCheckPtr) also work for the references of these elements.
If that is possible we could implement a safe wrapper around the respective functionality. Maybe hidden behind a config option to disable this safety feature if the performance penalty may be unacceptable for some use cases.
The text was updated successfully, but these errors were encountered:
Sounds good if possible. I think we should always include the check if possible. However these use Magic Cookies instead of Handles so I expect that wouldn't work - they may be another route to look at though. Certainly a crash should be avoided at all costs.
If we cannot check it we should mark the functions as unsafe for this reason.
Just coming back from hunting down a use-after-free bug in my code caused by UserEvents.
In summary: Some elements, i.e. notifiers, UserEvents, queues... allow the user to free the memory/reference in LabVIEW. At the same time these are things that one probably holds on for longer than just a single function call.
All I did in my code was release the UserEvent in LV right before the DLL call to my library. In the meantime my lib tried to send some UserEvents and crashed.
Idea:
The text was updated successfully, but these errors were encountered: