I am struggling with an error that I traced to the Easy XML read VI from the JKI XML toolkit. The error appears in my application after running for a week or so. It is the very simple error you get when you do not wire the required Labview data Type:
Easy Parse XML<ERR>
Input data is a null (empty) variant. You must wire valid data into the variant data input of the EasyXML VIs.
The problem is: the VI that must be causing this error is actually hard-wired with a cluster constant! And this cluster constant does not contain any empty variants either. Furthermore, it runs for extended time before it starts returning this error. Once it starts with this error, it will not restore itself.
Any advise what may be happening in runtime to cause such an error?
It is so much easier to find/test/explore problematic code when we can "see" the code. I haven't used EasyXML recently, but had licenses to the first two versions that were released, and it worked fine then. I'm guessing (!?!) that the problem is somehow "data-driven", which means we need to "see the data" (which is generated by your code) in order to make help suggestions (as opposed to wild guesses). Please attach the relevant VIs (or compress the folder holding the Project and attach the resulting .zip).
The point is that I boiled it down to a single VI where the error must originate. And this VI is very simple:
That is so helpful! A static picture, with an unknown string called "header" (are the contents important?) being read by Easy XML using an unknown TypeDef with a generic Icon ("2"), resulting in what appears to be a Cluster (of unknown type) going into an unknown Indicator also called "header".
If you really want meaningful help (as opposed to "educated (?) guesses"), attach your VI, the TypeDef, and an indication of what's in the "header" string control.
Bob, you are right. I appreciate you take an interest. I just don't see how this issue can originate from this VI (maybe the toolkit itself).
Please see the code attached. The error appears in an executable built with LV2018-32, combined with EasyXML v 220.127.116.11
It may take up to a week before the error starts appearing
My apologies. Now that I see the code, have run it, and have (more carefully) re-read your original Post, I think you are (probably) correct, there's a bug somewhere deep (possibly meaning "nested, ran out of memory") in the EasyXML implementation.
I probably tried the same things that you did, namely disconnecting one of the two inputs, and noticing that this immediately gives you a Broken Arrow, as these are "necessary". Putting in an empty string also doesn't cause an error.
So it's either the Code (meaning EasyXML) or the Data (meaning what you are feeding it). You describe this routine as running for a week before failing -- is it parsing data all this time? Do you know anything about the data stream going in when the error occurs?
Sometimes when code runs for a week and then fails, there's a problem with memory, as in something grows (slowly) until you fill memory, or some such. Is this a possibility? Something you might try is to bring your input into EasyXML out as an indicator (which you simply ignore until the crash occurs, then you can see the last input processed, and see if it offers any clues).
If you run the routine several times, does it seem to fail at the same place in the data (or after the same amount of time)? This could be a significant clue. Is there any possibility that buried somewhere in the data is the equivalent of a "Curse Card" (one of my fellow students, a long time ago, punched up a Fortran card with a complicated equation that started "curse=" (I don't remember what "curse" stood for, but it wasn't intended to cause the Compiler to crash ...), some weird data that puts the Parser in an endless loop or something like that.
Note that EasyXML comes to us from JKI, who created VIPM, the JKI State Machine, and other goodies. I would encourage you to reach out to them, as you may have an example of legitimate input that causes their algorithm to hit some (probably memory) constraint and fail "ungracefully".
I'd be interested in their response ...
Do you know anything about the data stream going in when the error occurs?
I do not know for sure what string is fed to the VI at the point of failure. However, It should not return this error regardless of what string it is.
Sometimes when code runs for a week and then fails, there's a problem with memory, as in something grows (slowly) until you fill memory, or some such. Is this a possibility?
Although I can not yet rule out memory leaks, I would not expect to always see the same error appear in such case. This VI is part of a parser, and the data load routine that allocates memory is executed before it, making that more prone to a memory error.
If you run the routine several times, does it seem to fail at the same place in the data (or after the same amount of time)?
I have only seen the error in an executable. The error can only originate from this VI. I am curious about the time, although it might also be a set number of iterations.
Is there any possibility that buried somewhere in the data is the equivalent of a "Curse Card"?
In the XML toolkit maybe. I guess I have contacted JKI. Regarding their stellar quality, I find it more likely that I cause the error.
I read through this discussion. A couple thoughts:
1) In order to debug this, we'll need to know what data is being passed into EasyXML when the error occurs. Maybe you can try to test for this error and then modify the error message to include the data that was passed into EasyXML (or log the XML data to disk).
2) EasyXML is open source, so you can look at how the code is written.
Beyond that, I'm not really sure what could be causing it -- we'd need to see the actual data, in order to debug the issue.
Here's a followup to Jim's suggestion -- the following alteration to your code will allow you to stop and "trap" the data causing EasyXML to raise an error. Let EasyXML "help" find (what might be) the bad XML.When the Parse XML or Variant to Data functions throw an Error, use the One-Button Dialog to show the XML string that (might have) caused the error, otherwise just pass the header out (the "hidden" No Error case). Note you might want to write the string to a file, as it might be too long to see the whole thing on your screen. Also note the Format into String has been "lifted off" the Error Line.
Thank you both for your suggestions! I will get on it. Seen the nature of the issue (after a week or so, deployed at customer) I will need some time to get results.