Collisions in executable cache directory

Create issue
Issue #1321 new
Ian Hinder created an issue

If I have two Cactus trees both using the same configuration names and the same simulation directory, I believe that the executable cache in simulations/CACHE will suffer from collisions between the cached executables in the different Cactus trees. A solution would be to use a unique name for the executable, just as is done when purging simulations to the TRASH directory.


Comments (6)

  1. Frank Löffler

    Bumping this up a little since this can be really a bad surprise, and be hidden from the user for a while. It also isn't all such an exotic setup. Using the same configuration name is easy - just use the default 'sim' in all Cactus trees.

    I am hesitant to set the ET_2013_05 milestone, but a fix which would make it into the release would be very welcome.

  2. Erik Schnetter
    • removed comment

    This is a cache directory. Name collisions mean that the executable won't be cached. Unless you run many simulations with the same executable, the disk space overhead will be negligible. This is a low-priority issue.

  3. Frank Löffler
    • marked as
    • removed comment

    Looking through the code it seems to me that simfactory checks whether the srcfile has the same size as the cached file. This is likely false for two configurations, but not necessarily so (say, you compile the same thorns using the same configuration, but change just one little detail which just happens to not change the compiled code size, say a hard-coded number, a hard-coded parameter maybe?). simfactory also looks at the mtime of srcfile and the cached file, but treats files as equal if src.mtime <= dst.mtime, so with a certain order of building and sim-creation you can 'hit' this.

    So yes, it is probably not 'major' since hitting this bug is not all that likely (and I'll downgrade the ticket because of that), but if you hit it, results will be quite surprising.

  4. Erik Schnetter
    • removed comment

    Note that the optimisation applied here (compare file sizes and times instead of file content) is the same optimisation that I recently disabled for "sim sync", and am now receiving complaints that comparing file content is too slow.

    One easy modification would be to set the cache file time stamp to the original file's time stamp, which allows comparing file times for equality instead of using <=.

  5. Roland Haas
    • removed comment

    This does not change the severity of the bug, but isn't it actually quite likely that one has identically named executables? Simfactory by default calls its executable cactus_sim and if one uses several Cactus trees for different versions of Cactus then they are all in conflict. Ian's situation where for tests he had a unique hash in the executable name is the more unusual I believe.

  6. Log in to comment