To Timestamp Crashes Labview 2010 (code included)

[Jed_Davidow]

This VI crashes LV 2010 (with the saved default inputs).

The crash occurs at the To Timestamp primative.

LV 2010, Windows 7 32bit

[altenbach]

Yes, I see that too. I reported it here.

What are you actually trying to do with all this??

[Jed_Davidow]

I had written a pretty exhaustive routine to save a cluster of data within a TDMS file in LV2009.  At some point I added the Timestamp, and for brevity's sake, changed all the data to EXT.  Wasn't saving a lot of data, so the extra space wasn't a big deal.

At some point I discovered that when you write EXT data to the TDMS, there is a good chance the file will be corrupted as soon as it is closed (this took a while to figure out).

So I decided to split the TS into two DBLs and store it with the rest of the data in the TDMS.  This works fine.

But at some point I made an error and passed incorrect data to the TS function, and I have spent the last 2 hours dealing with it!

[altenbach]

On a side note, you could simplify your code quite a bit, e.g. as follows, less pink!

(Of course it still crashes! :()

[Jed_Davidow]

Nice!  I forget about the imaginary functions; only had to code with them once!

[DFGray]

I believe the problem here lies in the typecast operator.  An EXT is 80 bits in memory.  A CDB or two DBLs is 128 bits.  A timestamp is also 128 bits.  So when you typecast 128 bits into 80 bits, you overwrite some memory you shouldn't and it crashes when you then try to use that section of memory.  A simple To Time Stamp of an EXT does not crash. (of course, it should not ever crash, it simply should not work!).

I am somewhat confused why you did not use timestamps directly in your TDMS file.  They are supported.  It is also unclear from your writeup if you are using the DBLs as a convenient 64-bit container or they are actual DBLs.  Conversion to a timestamp is relatively simple in either case.

If using as a 64-bit container, cluster them with the high word first, then typecast this cluster to a timestamp.  If they are truly DBLs, the conversion will depend on what is in each one.  If one contains seconds and the other fractional seconds, it is easy.  Convert the one containing seconds to an I64.  Multiple the fractional seconds one by 264, coerce to nearest integer, and convert to a U64.  Cluster the two integers, I64, then U64, then typecast the cluster to a timestamp.

If you need more info, let us know.

[altenbach]

I agree that the operations are questionable in general, but there are a few points:

• While on Windows EXT is only 80 bytes, a flattened EXT is still 128bytes, possibly aiding the confusion.
• If we typecast the generated EXT back to a string, we get all 128 bytes back. This means we can "hide" 128 bytes in an EXT, leading to more possibilities for obfuscated LabVIEW code, e.g. similar to JPDs classic entry. 😉
• The code with CDB was my idea. I did not say it was sound, it was just a 1:1 simplification of the original code which operated on a 128bit string.
• I agree that there should be no conceivable scenario that crashes LabVIEW.
• Do you think the real problem is with "to timestamp" or with typecast  to EXT?
• Do you have a CAR?

[DFGray]

Correction:  The 264 in my previous post should be 2⁶⁴.

I have submitted CAR #277392 on the problem.

Based on what I know at the moment, I believe the problem is in the typecast.  I think its output is corrupted.  However, I have not actually looked, so this is conjecture.

[Jed_Davidow]

---

@DFGray wrote:

...

I am somewhat confused why you did not use timestamps directly in your TDMS file.  They are supported.  It is also unclear from your writeup if you are using the DBLs as a convenient 64-bit container or they are actual DBLs.  Conversion to a timestamp is relatively simple in either case.

Thanks for the thoughtful comments.

This actually stems from another problem.  I have an application that is in the early stages of design and doesn't generate that much data (.5-.25 Hz, 10 scalars per sample).  So I am storing the data in a TDMS for convenience sake.

However, I need to make sure that all the values are saved atomically.  So I converted them all to EXTs, arrayed them, and then saved them with one call.

The problem is that when I did this, the use of EXTs (to capture the Timestamp along with all the other DBL values) would corrupt the TDMS file when it was closed.  Every time.

To fix this, I did the above cast to get 2 DBLs to append to the array of DBLs I wanted to store.

In the final version, I will probably use a datalog file (this is more appropriate for what I am doing).

[DFGray]

Could you post a snippet of code you can post which shows this problem?  This sounds like a bug and I would be happy to post another CAR on it for you.