[Scons-dev] please try latest default branch

[roberto de vecchi]

Gary,

 

Can you please point me to the testcase you are investigating? I would like
to test it with the scons code I’m running ( dirk patch + some in house
changes): my developers that are running the experimental code did not
report problems so far, so I see a few options: 

1)       our company work does not include a case like your one

2)       my people did not realized the defect

3)       our in house changes ( really few things) may have fixed the
problem.. in such a case I would be happy to provide them.

 

regards,

roberto

 

  _____  

From: scons-dev-bounces at scons.org [mailto:scons-dev-bounces at scons.org] On
Behalf Of Gary Oberbrunner
Sent: Tuesday, January 28, 2014 23:57
To: Dirk Baechle; SCons developer list
Subject: Re: [Scons-dev] please try latest default branch

 

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 <garyo at 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 <tshortik at 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 at scons.org

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





--
Gary





 

-- 
Gary 

 



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://two.pairlist.net/pipermail/scons-dev/attachments/20140129/b1677148/attachment-0001.html>