More results, no fix yet. The generated file all-defuns.c I mentioned before is definitely part of the problem. I back-ported the tracing code I wrote to just before Dirk's memory optimization. In that version, near the beginning of the build phase something calls node.is_up_to_date() on all-defuns.c and it says it has changed, due to depending on a dir "mkl" which is in no_state (i.e. hasn't been evaluated yet). In Dirk's version, this result gets cached, which seems sensible. But in the old version, when the taskmaster considers that all-defuns.c node, and calls is_up_to_date(), now it correctly returns True, because by now the mkl dir has been evaluated and it's in up-to-date state. So it's definitely the caching that's causing the trouble, but I don't understand why is_up_to_date should return different values at different times -- especially go from false to true before anything's been built. Perhaps there's another bug in the code which Dirk's patch exposes?
I would think is_up_to_date() should never assume that being unprocessed (i.e. no_state) means not up-to-date; I'd think it should have scanned the no_state node before its dependents. Anyone have any clues? On Sun, Jan 26, 2014 at 11:15 AM, Gary Oberbrunner <ga...@oberbrunner.com>wrote: > I'm continuing to track this down. No solid results so far (but I'm > adding lots of tracing code). I have a generated source file, > all-defuns.c, that depends (using Depends) on a dir (mkl), and it > seems like with the new code while the taskmaster is checking > all-defuns.obj it checks all-defuns.c, which calls Dir.changed() on > the dir, which just checks the node.state -- and the state is > no_state, i.e. it hasn't been evaluated yet, which changed() > interprets as being changed, so it decides to regenerate the source > file all-defuns.c. Later, when the taskmaster gets to checking the > mkl dir, it finds all of its children are up to date and marks it up > to date, but it's too late by then. I suspect (?) something in the > taskmaster updates but will have to keep poking at it. > > On Tue, Jan 14, 2014 at 1:39 PM, Dirk Bächle <tshor...@gmx.de> wrote: > > On 14.01.2014 14:44, Gary Oberbrunner wrote: > >> > >> OK, I'll try that. I guess the approach should be to set a new > >> (temporary) flag in the node when its executor is released, and then > print a > >> stack trace if any node with that flag set gets its changed() method > called? > >> > > This flag already exists and it's called "self.released_target_info" > (check > > the end of the relase_target_info() method). > > Then you want to use the KeyError exception path in File.changed() like > > this: > > > > if node is None: > > > > try: > > return self._memo['changed'] > > except KeyError: > > if self.released_target_info: > > # We have no executor anymore, but the cached > "changed" > > # value doesn't exist either -> print stacktrace! > > > > > > Dirk > > > > > > _______________________________________________ > > Scons-dev mailing list > > Scons-dev@scons.org > > http://two.pairlist.net/mailman/listinfo/scons-dev > > > > -- > Gary > -- Gary
_______________________________________________ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
