building daqmx client errors after a an hour

[pettaa123]

Hi,

I am struggling to build daqmx client. If fails after an a few hours compiling with this error:

Any suggestions?

AB#3073418

[pettaa123]

[jasonmreding]

I am not sure how much time I will have to continue looking at this given the nature of the problem, but I was able to reproduce the failure you reported. In my case, it was ~4.5 hours into generation before failing, and it had generated 5,709 files before it failed. I don't know if it failed similarly for you or how deterministic the failure is.

From examining the stack trace that is reported, I can see the failure is coming from the Get or Create Typedef.vi shown below:

Just from code inspection, it appears there might be a race condition of sorts between the top and bottom railroad tracks. The top railroad track is going to try to delete the typedef from the library if it already exists while the bottom railroad track is going to create a new typedef with the same file name (presumably stand alone and not part of any library just yet). Since there is no data flow dependency between the deletion of the old typedef and the creation of the new typedef, it is a race as to which will finish first. The delete in this case is really a removal of the item from the library it belongs to and not a delete from memory/disk. By removing it from its owning library, what I call the "link name" of the typedef is changed since it is no longer scoped to a library. This creates an opportunity for a name collision if there is already a typedef in memory in the global namespace with that same name. I'm pretty sure that is what error 2 is referring to in this case (not a memory full error). LabVIEW just does a horrible job of indicating what really went wrong in this case.

To be honest, I'm having a hard time understanding why there would ever be an existing typedef for that name in the library such that we would need to remove it, but clearly it is happening. That assumes a clean generation from scratch and not trying to regenerate on top of an already generated client library. Perhaps if you are able to identify the typedef that is producing the failure, we can correlate back to the .proto file and figure out what might be going wrong.

If you want to take a stab at debugging/fixing on your own, I would probably start by either:

• Changing data flow so that the delete/remove always occurs before the create/save of the new typedef. If nothing else, it seems like that disallows the possibility you could end up removing the typedef you just generated/added to the library.
• Update invoke node inside Delete Item From Library.vi so that it calls Force Delete rather than Delete. In order to see the Force Delete method, you need to have certain ini tokens enabled for scripting. If you don't see it, you should be able to copy it from Delete Item from LVClass.vi. The force delete differs from delete in that it will ignore certain errors like I described above that can lead to ambiguous linking due name conflicts of items loaded into memory.

If you haven't already, you'll need to clone the repo to do any debugging. You can then execute / debug the code generator from outside the tools menu using the project shown below. That avoids the need for you to have to mess with any of the installed software that is executed from the tools menu.

[pettaa123]

Hello, thanks for looking into this. I think I followed your advice and did a build via ClientServer Support New.lvproj but I still get this error after a few hours:

delete before create/save:

force delete:

[pettaa123]

I am going to log if this happens reproducable on the same input: name.

[pettaa123]

Reproducable error on:

[jasonmreding]

OK, I think I jumped the gun a bit on my original post. While the race condition I hypothesized about might also be problematic under certain circumstances, I don't think it is the cause of this issue as the error is coming from the Get All Descendants invoke node inside of Find Item in Library.vi and not the Delete invoke node from Delete Item from Library.vi. When I set a conditional probe to break on error, I actually got saw LV give out of memory from the probes of library refnums (but not folder refnums) so I think this might actually be a refnum leak that has surfaced due to the size of the DAQmx API proto file.

A did a quick trace using the Desktop Execution Trace Toolkit configured to only look for reference leaks, let it run for a couple of minutes, and then closed the top level VI. This identified a few potential leaks, one of which I suspect might be the likely culprit. The leak is in Find Item in Project Item.vi as shown below.

In the VI, we search for an existing item under a top level project item. If it is found, we end up closing all references but the matching reference.

However, if no match is found, we end up doing nothing.

Instead, we should probably move the Close Reference node outside the case structure and wire the correct array of refnums to it for both cases. It's possible there are other leaks as well, but this is the first one that jumped out to me as clearly problematic that could lead to a large enough leak to exhaust LV of memory resources.

[pettaa123]

After 28 hours the build completed without errors with the fix you suggested:

[jasonmreding]

I am going to close out this issue since it seems the recent changes from #425 were enough to get you past the out of memory issues and there were other issues created for the performance issues.