Flattened String To Variant - In some cases, LV crashes

[ouadji]

LabVIEW (2017) shows an error message for some unknow types, in my point of view it's the good behavior ... but for some others unknow types, LabVIEW crashes. My english is not good enough for explain all this, so i use a picture.

see attached VI

[pincpanter]

You are playing badly with memory, probably inducing LabVIEW to overwrite portions of memory which should be reserved to other data.

In those cases, LabVIEW may crash or not, depending on the severeness of the damage. It's kind of random outcome.

You should not expect any guaranteed graceful behaviour here.

[ouadji]

After some thought, you are probably right.

It is perhaps a bit of a shame that LV can not check the validity of the descriptor in all cases ...
that said, I understand it would be difficult. ... and useless.
It's true that kind of thing may arise with any language.

ok, thank you for your point of view.

[Yamaeda]

What are you trying to achieve? Usually you'll use a Flatten to string to get the Type array, not supply one arbitrary. If you manage to crash LV that way we have a big problem.

/Y

[Intaris]

I disaagree that one should not expect graceful behaviour here.

If the node already outputs errors for malformed input data, it should be consistent.  Crashing is not a very nice way of saying what the user has done is incorrect.

While I agree the usage is a bit out there, I still think avoiding crashes when a user inputs malformed data to a LV primitive should be expected.

[ouadji]

@Intaris : " Crashing is not a very nice way of saying what the user has done is incorrect. "

yes, it's also my opinion.

With "C" or "Assembler" .. ok ...

but with a high level language, like LabVIEW ... LV should never crash. (whatever you do)

[rolfk · Accepted solution]

---

@ouadji wrote:

@Intaris : " Crashing is not a very nice way of saying what the user has done is incorrect. "

yes, it's also my opinion.

With "C" or "Assembler" .. ok ...

but with a high level language, like LabVIEW ... LV should never crash. (whatever you do)

---

But flattened data is NOT a high level feature. It is rather low level and there is no way to make it foolproof under all conditions. If the typedescriptor does describe one thing but the data stream contains something entirely different there is no bullet proof way to guarantee that nothing bad can happen. LabVIEW does all kinds of plausibility checks here, such as not trying to index data beyond the end of the actually provided string, but if the data in the stream itself results in inconsistent behaviour it gets really though to determine that. Microsoft has an API function that you can use to check if a pointer is valid. It's horrendously inefficient, and not foolproof either.

Type 0x70 is a refnum and especially tricky as it is similar to a pointer to some data. If the data in the stream happens to resemble a valid refnum then LabVIEW will try to access it and add it to the Variant.

And no 0x52 is not an unknown datatype. It is an OLE Variant, a datatype that can contain pointers. It's not normally used in flattened formats but probably not specificially disabled either. It's internal format is however just as much undocumented as the native LV Variant though, except that the memory layout is defined by the Windows API.

[ouadji]

@rolfk : " But flattened data is NOT a high level feature ... ... "

ok, rolfk, understood !

a very interesting explanation