Impossible Easy XML read error

[aartjan]

It took me some time, but I have now confirmed that the error indeed originates from the suspected VI and that it receives a proper XML string. Apparently the VI really does not receive the variant cluster as the error suggests!! Could it have something to do with the EasyXML read.vi being a shared clone reentrant execution? I am not sure why that is.

Aart-Jan

[Jim_Kring]

I don't quite follow. Are you saying that your code is not passing in the variant cluster? Or, are you saying that LabVIEW is somehow losing its mind and claiming that there's not data inside the variant cluster, even though you've wired a constant to it on the block diagram.

Do you have an actual VI that demonstrates/reproduces the bug?

Can you post the XML string data that shows the bug?

I'm guessing that you may also be on to some kind of LabVIEW bug where, because of shared clone reentrant execution, after some amount of time LabVIEW loses its mind, because too may reentrant clones have been shared over time. I don't know.

Ideas:

- Are you using the most recent patch of 2018?

- Can you try in LabVIEW 2019 and see if the problem goes away?

Sorry, I don't have better answers. If I don't have a way to reproduce what you're seeing, then I can only make guesses (and second guess the observations you described).

[aartjan]

Thank you, Jim! Please see my answers below

I don't quite follow. Are you saying that your code is not passing in the variant cluster? Or, are you saying that LabVIEW is somehow losing its mind and claiming that there's not data inside the variant cluster, even though you've wired a constant to it on the block diagram.

The latter: It appears that LabVIEW is somehow losing its mind and claiming that there's not data inside the variant cluster, even though I have wired a constant to it on the block diagram.

Do you have an actual VI that demonstrates/reproduces the bug?

I have shared the VI that produces the error in a previous post. So far, I have only been able to reproduce the issue within the built application.
I have tried to reproduce it by running the easyXML parse over a million iterations, but that won't reproduce the error.

Can you post the XML string data that shows the bug?
It is not a specific XML string that triggers the bug. After a non-specific runtime or number of calls, the VI starts returning this error, whatever XML string I throw at it!

The strings are of the following XML format: <header columns="4" rows="8"><column type="Int32" name="EventLogID" /><column type="Int32" name="SessionID" /><column type="Int32" name="QueryID" /><column type="Int32" name="FilterID" /></header>

I'm guessing that you may also be on to some kind of LabVIEW bug where, because of shared clone reentrant execution, after some amount of time LabVIEW loses its mind, because too may reentrant clones have been shared over time. I don't know.

Ideas:

- Are you using the most recent patch of 2018? Yes: LV2018f2

- Can you try in LabVIEW 2019 and see if the problem goes away?

I have been trying to port the application to LV2019. I am running into a very ugly issue there that my application main VI won't compile and crashes Labview! In 2018, it compiles fine.

Sorry, I don't have better answers. If I don't have a way to reproduce what you're seeing, then I can only make guesses (and second guess the observations you described).

[Yamaeda]

Is it set to Preallocate or reuse memory or inlining? I can imagine enough new allocations would mess stuff up, but reusing shouldn't, unless it can lead to some sort of race condition (not LV related, but i had a program crash after opening ActiveX references 1 million times ...)? Can you turn off reentrancy and see if it solves it? I'm just spewing ideas, it all sounds really strange.

/Y

[aartjan]

This particular instance of the EasyXML.vi is not called all that often: likely less than 100.000 times over the course of a week

[aartjan]

I have magically succeeded to overcome the compile issue and ported the project to LV2019-32. Unfortunately no resolve for the issue.

[aartjan]

I also caved in and created a VI to manually parse this relatively simple piece of XML and circumvent the issue. I still hope to solve the issue, but my project won't depend on it anymore.