Compiled executable is different every time

[GPeople]

Thanks for the replies!

I am using LV 7.1 for this particular problem and we are migrating to LV 8.2.1

I read on some other boards that some Microsoft builds (win apps) compile slightly different because of an embedded time stamp.  I can't verify that is true because my 17+ years experience is with embedded apps using C code, so I really can't say. 

In my experience all the builds I used to do in C code could recreate the EXE (bin) file every time without fail.  If you got a wrong CRC or checksum, then it is a positive flag that your code, build process or linked libraries have changed and thus your build (application) cannot be trusted to be identical.

I have seen in a very few isolated cases (in 17+ years) a situation where the checksum is off by just a couple bytes (due to internal version # being updated by mistake for example).  Our work around in that case was to diff the binary and this simple difference in the data section is very identifiable and thus can be validated by analysis and high confidence that it would not adversely effect the application function in any way.  Thus, all would not have to be retested and development could proceed.

However, when I do a diff on the two LabVIEW binaries that were compiled within minutes of each other, they are radically different.  I diff'd them with Beyond Compare and the maker pane on the left showing differences looked like a 2 foot long bar code (every bar in this bar code analogy marks a difference between the two files), yet the OS reports the exact same total bytes in both files.  I am guessing because G language is not top down like C code, when it is compiling a diagram that has multiple paths in parallel, I guess the compiler randomly picks which it is going to do first, thus creating the same amount of binary, just in different order each time.

An interesting test would be to create an application that uses strict data flow with no parallel paths and see if it reproduces the checksum each time it is built.  Then create an application that has many while loops, each with multiple paths in parallel within each loop and see if this produces different checksums with each build.  This would validate that theory.

I have been to all the basic and intermediate classes and I thought I was taught that when a LV app is running it would determine at run time which parallel path is the best to run first but now I am wondering if it is really dependent on what flavor of the minute is compiled....

Thanks!!

[m3nth]

If you read the knowledgebase article linked to at the beginning of this post you will see why it is different every time.  Obviously software configuration or embedded program maintenance were not a concern when developing the way LabVIEW operates or compiles programs, but it is what it is until they fix it.

---

This is a result of the file format. Some parts of the files actually contain copies of the structures that are used to keep track of the files in memory. These structures contain memory pointers that tell LabVIEW where the different parts of the file are saved. Because these pointers are different each time you run LabVIEW and they are written into the executable file, the resulting executable is different each time it is built.

---

[dhedges]

The knowledge base was from version 5.1, and as you can imagine, a lot has changed since then.  Specifically, the article says that pointers are a part of the file format.  That was true in 5.1 and in 7.1, but by 8.2.1 it had been changed.  Sort-of.

Ryan, when you upgrade to 8.2.1, you will notice that the problem is a great deal less-pronounced.  There will still be differences, but now they will be countable, instead of the whole file being a red bar in your differ.  But I don't think you'll be at the point where your boss will allow a release without total retesting.

I ran a test with a small system of four simple VIs that I package up into an app.  My differ found five differences in the EXE -- one per VI, and one more:

• An EXE contains an LLB, which contains the four VIs.  The LLB also contains a listing which has, among other things, each VI's name and create and mod dates.  The mod dates are different for each VI -- they are the timestamp of when the build was created.  This directory is the first difference.
• There was a bug in 8.2 (also in 8.2.1) that caused nonreproducible data to be saved at the end of each VI file.  This accounts for the other four differences.  The bug was fixed in time for 8.5.

So, we have made great strides in the direction of giving you what you want.  Unfortunately, we're not there yet.  There are also other problems that cause diffs in larger, nontrivial systems.  For instance, if you use Express VIs or if your build process disconnects Poly VIs or if your VIs are not compiled to the current version at build time.  And those are just the problems I know about.

Anyway, thank you for your post.  It sounds to me like if you could demonstrate, through manual inspection or otherwise, that the only difference between the EXEs was the timestamps, you would be able to get out of retesting.  Is that correct?

Thanks,
--Dan

[GPeople]

Thanks dhedges (Dan is the Man)!

You are right on it and in every aspect.  Great explanation of problem...most detailed information I have received as of yet, thank you!!

It is also great to hear that NI is working towards solutions for this problem as well.

Yes, if we can identify simple differences that would be a huge step forward.

This would require a more detailed description and process for our CM people to verify the builds.

Then we would be able to prove by analysis that the build process is not corrupt and then a compete retest would not be

required when adding functionality to the existing tool chain.

That answers all my questions on this topic.

I will give 8.5 a go and then most likely have our IT department roll out 8.5 in time before our next big release.

Thanks again, I appreciate all the help.

-Ryan