LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Bug (by inspection) in MD5Checksum core.vi execution settings?

The only form of MD5 encoding I found in LV was for files. I needed it for strings so copied MD5Checksum File.vi to a new name and started the modification. I noticed repeated calls to MD5Checksum Core.vi within MD5Checksum File.vi, and things pretty clearly showed that each such call depended on the state left by the previous call. No big deal, but just in case I checked to verify the MD5Checksum Core.vi's execution properties had "reentrant" checked. And they did not.

 

What this means, in case it's not clear to somebody, is that interleaved calls to MD5Checksum File.vi from multiple vi's running in parallel can cause undetected errors in the checksum. This is especially true if the MD5Checksum file is being used in a production environment where lots of files are being marked with a verification checksum.

 

If I'm right, this is a really bad kind of bug. It doesn't show up during normal testing, but only occurs during heavy use, and the errors it causes are passed on as real data, and only when your installation software tries to verify files during install at your customer's site does the problem show up as "file corrupt", and this only sometimes.

 

Anyway, if I missed something I'd be really glad for the learning experience. In the meantime I'll fix it for myself. Of course.

0 Kudos
Message 1 of 2
(2,016 Views)

Dang, never mind, core doesn't appear now to retain data between calls.

 

0 Kudos
Message 2 of 2
(2,005 Views)