crash with nested cluster strict type def

[James_McN]

Hi Frank,

As I was typing the issue for my colleagues I had a brainwave.  I think the issue may be related to the fact you are referencing front panel objects in front panels that havent been loaded into memory and therefore you see memory exceptions.  I ran your VI with all the subVIs that are set to reference items to open front panel when called and these appeared to solve the problem.  Do you see the same behaviour?

Regards,

[James_McN]

Hi,

I have been having a play with this and have not been able to replicate it with a smaller cluster still so I think it is still somewhat related to the size of your clusters or some other factor in the VI settings.  As I say showing the front panel and then setting the run time position to minimised there is minimal disruption on the screen and it works.  Would this appear to be a suitable workaround in your main application?  I will also generate a corrective action request to R&D for this as well.

Regards,

[Freeky Frank]

James

The link between the “strict type def” and the panel using the definition definitely has weaknesses. I regularly edit type defs and exit them expecting the changes to be reflected into the other panels and find they are not. This is particularly obvious if I change the size of the definition, I have not spotted changes in data being omitted but that might be the cause of the problem. I then need to replace the original before the size is changed.

I have more than 20 of these panels and all bar one work perfectly! All are referenced in the same way so the front panel cluster is defined in a strict type def and the output is used by another vi. Most of them have nested strict type defs so there are over 60 type defs involved in the process and these numbers are growing. The one that fails is nested.

I wondered if because LabView started as a data driven system if the reference link was in some way a second class citizen. Clearly finding references is not quite as simple because there is not an obvious link maintained by the programmer. This could I guess be exacerbated because the cluster is used as output and not being “activated”, “acted upon”..... That said I have no evidence of the connection being lost or weak.

Remember once “triggered” everything returns to normal and that was one of the reasons I have problems being able to replicate the problem reliably. However, mass compilation does not seem to resolve the problem.

If I run the small example sent to you with the front panels open it works fine and does not force the problem to be fixed permanently. So I agree this is a work around during development for those with small numbers of panels. Deleting the included type def and re-adding it will also probably fix the problem. I have not tried producing a distributable copy of the application so I do not know if the problem persists into that domain. My main development program is now working correctly again so I am unable to test this on it, sorry.

Frank

[James_McN]

Hi Frank,

I am not suprised that you say this is the only one that is causing issues as I have also struggled to get other clusters to show the same problems.  Are the others entirely string based as well?  It appears from the logs of the crash that I got that the issue lies with memory allocations so perhaps with strings having no fixed size that could cause a problem.

I am pleased to here that the workaround works for you.  I have filed a corrective action request with the reference 175579.  This should be published in the fixed issues document of the LabVIEW release once it is fixed (although still try it if it is not listed).

Regards,

[Freeky Frank]

James

Yes, in the area where I have trouble all the clusters are strings. A “C” string without its null terminator would certainly match all the symptoms, even to the extent of once fixed never to return. I guess even an out of memory error could result from the lack of a terminator.

I still have to replace cluster defs to get the changes made in the “strict type defs” to always be acted upon.

Can I suggest NULL strings be checked because I do not always load text into the strings.

Frank

[Freeky Frank]

James

I am sorry to tell you but the problem has returned. I have no evidence but my intuition as a programmer is tell me the error occurs when I edit the strict type def and all the users (VIs) are not in memory.

Why? No idea.......

Frank

[Freeky Frank]

James

It appears that I have found another workaround.

If I connect from the master cluster via an “Unbundle by Name” to an input and connect the input to the output which is then manipulated via the “Reference” it works. I presume because LabView can trace everything through from the data flow and does not need to work backwards from the reference.

In other words LabView breaks the structure down through the Unbundle by Name and then after modifying the data inserts the data back into the original cluster via “Bundle by Name”.

It will take me some time to be sure this is a fix that lasts but we will see.

Frank

PS Another theory as to the cause that fits the symptoms; the failure occurs because LabView is reading an empty un-terminated string in the uninitialized cluster.

[Freeky Frank]

James

I have just had the problem again as I added more sub-clusters so none of the previous work arounds has solved the problem.

However, I found if I run the VI (on its own) that loaded the data in to the sub-cluster the problem no longer occurred in the main program.

So yet again it looks like some initialisation or memory problem.

Hope someone solves it soon

Frank