Actor Framework Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

MemoryManager.cpp error message

I wrote some AF code, debugged it, got it working. I then moved said code (dragging and dropping) into a different folder figuring I would just have to update some references to find common vi's I use elsewhere. My project loads and runs as before, but there is one specific event (button click that leads to a number of messages and methods being called) that is causing LV to crash, giving me the following error:

DAbort 0xF50EFD7B in MemoryManager.cpp

I've attached the error log also. I wish I could post my code, but unfortunately my company policy won't allow me. I don't know how to read the error log. I'm hoping someone can provide insight into what the issue might be.

Thanks

0 Kudos
Message 1 of 6
(6,534 Views)

That error almost always comes from you calling into a Call Library Node and doing wrong things to memory or calling into a hardware driver of some sort that does wrong things to memory. Yes, it could also be a bug in LabVIEW, but that isn't as common. The call stack in the log file indicates a double deallocation of a memory handle of some piece of data on a block diagram. In other words, this isn't something in the internals of LabVIEW, but something upstream of this crash. Now, that upstream thing could be an internal part of LV, but it is more likely a call out to external code. You got anything like that in your system?

Oh... it could also be an abusive use of the Type Cast node. If NI has done its job right, no nodes should be able to crash LV except the Call Library Node and the Type Cast node. Those are the two places where we allow users to access memory in ways that it is hard/impossible for LV to "check their work".

0 Kudos
Message 2 of 6
(5,629 Views)

I'm not using a Call Library Node or Type Cast node. This actor does not interface with any HW. This particular actor, aside from recieving messages from outside, is using only methods and calls within it's own class (except for a few type defs outside of it's library). I've been adding custom debug traces to sort it out. I have found there is an error now that I didn't have when it originally worked. The error shows up in DETT just before LV crashes. The error is "Error: 1 (LabVIEW:  An input parameter is invalid..." That's just a matter of finding the offending input node, probably something on one of my Generate User Event calls. I wouldn't expect this error to crash LV, at least I've seen this error many times in the past and it hasn't killed LV. I'm still not sure why it broke after the folder move, since it worked beforehand.

0 Kudos
Message 3 of 6
(5,629 Views)

I solved the problem. I can't say exactly what the underlying root issue was, but I have an idea.

I have 3 actors, a Core actor that handles the logic, a UI Core that allows for loosely coupled UI, and a concrete implementation of the UI that inherits from UI Core. Each actor is in it's own library. When I moved my files on disk (not in the project, just moving the folder...not the best idea but sometimes unavoidable), the associations between these libraries was broken. As expected, when I opened the project after the move, it had to search for the files. After fixing the loading locations, I figured all would work. It did on the other projects I moved. This particular project was the only one with the issue.

I traced the issue down to one VI. This VI happens to be the only one in the set of 3 actors that had a DD parent, a child override, and a message called from the third actor. I tried, unsuccessfully, several times to fix things by removing vi's from libraries, readding them, replacing the child, and so on. In the end, the solution was to completely remove the message that called the method, remove the DD method from parent, and remove the child override. I blew all of it away. Saved the project and restarted LV. I then recreated the method, child, and message. The code was exactly the same as before. After replacing all of that, everything worked as before.

Something about the folder/file move caused an issue with the libraries or associations. I thought I had fixed the associations, but there was apparently some association between these library compnents that I couldn't see (or didn't know how to find) outside of finding where the file currently existed and loading from that location. So, the problem is fixed, but I still don't know the root cause (well, other than me moving files).

It would be nice if there was a tool or feature of LV that would tell you all the information about a particular vi / library / class etc. Info like owning library, references to other libraries and their exact locations on disk, callers, callees, and so on. Some of this info is available via right clicks in the project or when there is a conflict, but not all of it, and not all the time.

0 Kudos
Message 4 of 6
(5,629 Views)

Glad it is solved. It does sound like you were wandering into an actual LV bug. I'm out of office for a while... you may want to contact an AE to file the bug report if you have replicating code that you can share.

0 Kudos
Message 5 of 6
(5,629 Views)

I have the same problem 😞

0 Kudos
Message 6 of 6
(1,631 Views)