Opened 5 years ago

Last modified 5 years ago

#1321 new defect

Collisions in executable cache directory

Reported by: Ian Hinder Owned by: Erik Schnetter
Priority: minor Milestone:
Component: SimFactory Version: development version
Keywords: Cc:

Description (last modified by Frank Löffler)

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.

Attachments (0)

Change History (6)

comment:1 Changed 5 years ago by Frank Löffler

Description: modified (diff)
Priority: minormajor
Version: development version

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.

Last edited 5 years ago by Frank Löffler (previous) (diff)

comment:2 Changed 5 years ago by Frank Löffler

Description: modified (diff)

comment:3 Changed 5 years ago by Erik Schnetter

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.

comment:4 Changed 5 years ago by Frank Löffler

Priority: majorminor

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.

comment:5 Changed 5 years ago by Erik Schnetter

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 <=.

comment:6 Changed 5 years ago by Roland Haas

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.

Modify Ticket

Change Properties
Set your email in Preferences
as new The owner will remain Erik Schnetter.
Next status will be 'review'.
as The resolution will be set.
to The owner will be changed from Erik Schnetter to the specified user.
Next status will be 'confirmed'.
The owner will be changed from Erik Schnetter to anonymous.

Add Comment

E-mail address and name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.