[Scons-dev] [Scons-users] Corrupt cache?

[Tom Tanner (BLOOMBERG/ LONDON)]

No, the problem is that purify sets the timestamp on the instrumented file to be the same as the timestamp as the original file. This means that when the code in get_max_drift_csig looks at the drift and you have a max drift set to anything non negative, it decides that it doesn't need to re-evaluate the signature, even though in fact the contents have changed.

I've ended up adding a local max_drift to thhe nods concerned which is moderately dodgy I suppose, but it fixes my issue.

I'm a little confused as to why scons bothers to used the cached signature if it knows it's just done a build though.
----- Original Message -----
From: bill at baddogconsulting.com
To: Tom Tanner (BLOOMBERG/ LONDON), scons-dev at scons.org
Cc: scons-users at scons.org
At: May 20 2013 21:38:02

Tom,

So, if I understand correctly, even if SCons detects it should run Purify, Purify will skip it's processing due to it's build avoidance?

Would a pre-action, or list of actions to run purify where the first item removes the target file (and/or the purify cachedir) solve this issue for you?

-Bill
On May 20, 2013, at 3:02 AM, Tom Tanner (BLOOMBERG/ LONDON) <ttanner2 at bloomberg.net> wrote:


> I have at last found out what the issue is.

> 

> The purify programs have major (and not switchable off) build avoidance code. In particular, they set the timestamp of the instrumented output to the same as that of the file that is being instrumented.

> 

> I can get round this by setting max drift to -1, but that is global and I'd really like to be able to apply this only to the files in question. 

> 

> I keep trying to get my head round

> 1) get_max_drift_csig as implemented, which behaves very strangely if drift is 0

> 2) The change for bug 2001 which appears not to have even been implemented as an

>   option, and which seems a saner behaviour.

> 3) The possibility of a timestamp not changing even if something has been built.

>   Being picky, I suppose with a sufficiently small build, this isn't

>   impossible

> 

> I think probably my question is "why isn't the csig set in the built() function"?

> 

> 

> 

> ----- Original Message -----

> From: ttanner2 at bloomberg.net

> To: garyo at oberbrunner.com, scons-dev at scons.org, scons-users at scons.org

> At: May 17 2013 17:56:48

> 

> It appears that something is not causing the md5 of the contents to be recalculated. I can do this pretty consistently. I added some trace that prints out the stored md5sum of the object and I get this sort of things:

> 

> scons: Building targets ...

> x.test.o 42f3caacf79d52342143ae0708d5c773

> libthing.so_pure_p3_c3_1202102036_510_32 3ac0d2f1ff00ed90b89103c2397f80d3

> scons: `test.purecov' is up to date.

> 

> then I delete libthing.so_pure....

> 

> and I get

> 

> scons: Building targets ...

> x.test.o 42f3caacf79d52342143ae0708d5c773

> scons: building 'libthing.so_pure_p3_c3_1202102036_510_32' because it doesn't exist

> blah

> scons: `test.purecov' is up to date.

> 

> so I run the build again and get exactly the same output as the first time.

> 

> So then I run md5sum. on x.test.o it gives the same output, but for libthing.so - it gives something else. (Note there's a timestamp inserted so it would change every time it was rebuilt)

> 

> ----- Original Message -----

> From: garyo at oberbrunner.com

> To: Tom Tanner (BLOOMBERG/ LONDON), scons-dev at scons.org, scons-users at scons.org

> At: May 17 2013 13:18:35

> 

> [Tom, this is probably more of a scons-users at scons.org question; moving to that list. -- Gary]

> 

> SCons can warn if it can't copy something to the cache, if you turn on --warn=cache-write-error (it's off by default).  Unless you're doing something unusual with deciders or custom signatures, I don't see how it could store different objects under the same cache filename though -- see CacheDir.py:cachepath().  If it's repeatable, you can probably learn more by going into CacheDir.py and setting cache_debug to a filename or "-" for stdout.

> 

> -- Gary

> 

> 

> On Fri, May 17, 2013 at 5:39 AM, Tom Tanner (BLOOMBERG/ LONDON) <ttanner2 at bloomberg.net> wrote:

> 

> I've recently had a problem with some object being copied to the cache *but* the copy didn't happen because the target thing already existed, but the new object and old object had different md5sums. Not surprisingly this causes very strange problems when the files get copied from the cache.

> 

> I'm not sure how to identify what on earth is causing this, and how to trigger a warning if it happens (either on copying to or copying from), as it's a bit of a disaster.

> _______________________________________________

> Scons-dev mailing list

> Scons-dev at scons.org

> http://two.pairlist.net/mailman/listinfo/scons-dev

> 

> 

> -- 

> Gary 

> _______________________________________________

> Scons-users mailing list

> Scons-users at scons.org

> http://four.pairlist.net/mailman/listinfo/scons-users

> 

> _______________________________________________

> Scons-dev mailing list

> Scons-dev at scons.org

> http://two.pairlist.net/mailman/listinfo/scons-dev