Complete rebuilds due to random hashes

Complete rebuilds due to random hashes

[Enrico Scholz]

Hello,

I have encountered the problem the whole distribution gets rebuilt when
I change a single, completely unrelated variable (e.g. BB_DISKMON_DIRS).

Dumping data in _build_data() (siggen.py) revealed that sometimes a
gitpkgv_do_configure() (or _do_compile/install...) function is in the
deps, sometimes not.  The recipes where this happens (e.g. m4) do not
inherit gitpkgv and it is not included globally either.

Further debugging[1] shows

| ERROR: calledvar=autotools_do_configure, vars=[['gitpkgv_do_configure', 'autotools_do_configure'], ['do_configure', 'gitpkgv_do_configure']], allvars=['do_configure', 'autotools_do_configure', 'gitpkgv_do_configure'], classes=[None, 'gitpkgv', 'autotools']

for such a recipe (note the 'gitpkgv_do_configure')


For me, it seems that this depends on the (random) order in which recipes
are read.  E.g. when a recipe using 'gitpkgv' is read first, the global
'classes' array will contain 'gitpkgv' and ExportFuncsNode() is constructed
with it.

But when m4 is read before the first recipe using 'gitpkgv', it won't be
contained in 'classes' and the corresponding ExportFuncsNode() will not
create this variable.


Does somebody know how to fix this?


Enrico

Footnotes: 
[1]  
--- a/lib/bb/parse/ast.py
+++ b/lib/bb/parse/ast.py
@@ -207,6 +207,8 @@ class ExportFuncsNode(AstNode):
 
                 for flag in [ "func", "python" ]:
                     if data.getVarFlag(calledvar, flag):
+                        if var == 'gitpkgv_do_configure':
+                            bb.error("calledvar=%s, vars=%s, allvars=%s, classes=%s" % (calledvar,vars,allvars,self.classes))
                         data.setVarFlag(var, flag, data.getVarFlag(calledvar, flag))
                 for flag in [ "dirs" ]:
                     if data.getVarFlag(var, flag):

Re: Complete rebuilds due to random hashes

[Richard Purdie]

On Fri, 2012-12-07 at 11:26 +0100, Enrico Scholz wrote:
> Hello,
> 
> I have encountered the problem the whole distribution gets rebuilt when
> I change a single, completely unrelated variable (e.g. BB_DISKMON_DIRS).
> 
> Dumping data in _build_data() (siggen.py) revealed that sometimes a
> gitpkgv_do_configure() (or _do_compile/install...) function is in the
> deps, sometimes not.  The recipes where this happens (e.g. m4) do not
> inherit gitpkgv and it is not included globally either.
> 
> Further debugging[1] shows
> 
> | ERROR: calledvar=autotools_do_configure,
> vars=[['gitpkgv_do_configure', 'autotools_do_configure'],
> ['do_configure', 'gitpkgv_do_configure']], allvars=['do_configure',
> 'autotools_do_configure', 'gitpkgv_do_configure'], classes=[None,
> 'gitpkgv', 'autotools']

I'm struggling to figure out how the code is doing this. The most
interesting piece here is:

classes=[None, 'gitpkgv', 'autotools']

and I cannot get a recipe locally to do this. classes is basically set
from BBConfHandler and its a relatively simple codepath. This would
imply the gitpkgv class is doing an "inherit autotools"?

Can you show how you're using gitpkgv in your code and what the bbclass
contains? I have the version from meta-oe but I'm failing to reproduce
or explain how this would get into there...

Are you doing anything interesting with EXPORT_FUNCTIONS anywhere in
your code?

Its very odd and any more information about your configuration would be
helpful in reproducing/debugging this.

Cheers,

Richard

Re: [bitbake-devel] Complete rebuilds due to random hashes

[Richard Purdie]

On Fri, 2012-12-07 at 11:26 +0100, Enrico Scholz wrote:
> Hello,
> 
> I have encountered the problem the whole distribution gets rebuilt when
> I change a single, completely unrelated variable (e.g. BB_DISKMON_DIRS).
> 
> Dumping data in _build_data() (siggen.py) revealed that sometimes a
> gitpkgv_do_configure() (or _do_compile/install...) function is in the
> deps, sometimes not.  The recipes where this happens (e.g. m4) do not
> inherit gitpkgv and it is not included globally either.
> 
> Further debugging[1] shows
> 
> | ERROR: calledvar=autotools_do_configure,
> vars=[['gitpkgv_do_configure', 'autotools_do_configure'],
> ['do_configure', 'gitpkgv_do_configure']], allvars=['do_configure',
> 'autotools_do_configure', 'gitpkgv_do_configure'], classes=[None,
> 'gitpkgv', 'autotools']

I'm struggling to figure out how the code is doing this. The most
interesting piece here is:

classes=[None, 'gitpkgv', 'autotools']

and I cannot get a recipe locally to do this. classes is basically set
from BBConfHandler and its a relatively simple codepath. This would
imply the gitpkgv class is doing an "inherit autotools"?

Can you show how you're using gitpkgv in your code and what the bbclass
contains? I have the version from meta-oe but I'm failing to reproduce
or explain how this would get into there...

Are you doing anything interesting with EXPORT_FUNCTIONS anywhere in
your code?

Its very odd and any more information about your configuration would be
helpful in reproducing/debugging this.

Cheers,

Richard

Re: Complete rebuilds due to random hashes

[Richard Purdie]

On Fri, 2012-12-07 at 11:26 +0100, Enrico Scholz wrote:
> Hello,
> 
> I have encountered the problem the whole distribution gets rebuilt when
> I change a single, completely unrelated variable (e.g. BB_DISKMON_DIRS).
> 
> Dumping data in _build_data() (siggen.py) revealed that sometimes a
> gitpkgv_do_configure() (or _do_compile/install...) function is in the
> deps, sometimes not.  The recipes where this happens (e.g. m4) do not
> inherit gitpkgv and it is not included globally either.
> 
> Further debugging[1] shows
> 
> | ERROR: calledvar=autotools_do_configure, vars=[['gitpkgv_do_configure', 'autotools_do_configure'], ['do_configure', 'gitpkgv_do_configure']], allvars=['do_configure', 'autotools_do_configure', 'gitpkgv_do_configure'], classes=[None, 'gitpkgv', 'autotools']
> 
> for such a recipe (note the 'gitpkgv_do_configure')
> 
> 
> For me, it seems that this depends on the (random) order in which recipes
> are read.  E.g. when a recipe using 'gitpkgv' is read first, the global
> 'classes' array will contain 'gitpkgv' and ExportFuncsNode() is constructed
> with it.
> 
> But when m4 is read before the first recipe using 'gitpkgv', it won't be
> contained in 'classes' and the corresponding ExportFuncsNode() will not
> create this variable.
> 
> 
> Does somebody know how to fix this?

Actually, I think I do have theory for what is happening. I think there
is some kind of exception happening in one of your recipes which is
perhaps causing it to be skipped/ignored and this is corrupting the
state of the parser.

I'm guessing the classes variable in BBConfHandler.py isn't getting
reset to [None, ] and hence the next recipe to be parsed sees "oddness"
due to the field not being reset.

This would happen in the classes.remove(__classname__) line never get
called, which would happen if statements.eval(d) or some other part of
the processing failed.

I would add some debug code into gitpkgv.bbclass around the functions
there, perhaps a try:/except: and see if there is some kind of uncaught
exception happening for one of your recipes. If that isn't it, I would
be intersted to understand what you have which is breaking out the
fetcher. It could be a SkipPackage exception under some circumstance for
example.

This would explain the cause, we then need to fix the parser state
engine so its properly reset each time...

Cheers,

Richard

Re: [bitbake-devel] Complete rebuilds due to random hashes

[Richard Purdie]

On Fri, 2012-12-07 at 11:26 +0100, Enrico Scholz wrote:
> Hello,
> 
> I have encountered the problem the whole distribution gets rebuilt when
> I change a single, completely unrelated variable (e.g. BB_DISKMON_DIRS).
> 
> Dumping data in _build_data() (siggen.py) revealed that sometimes a
> gitpkgv_do_configure() (or _do_compile/install...) function is in the
> deps, sometimes not.  The recipes where this happens (e.g. m4) do not
> inherit gitpkgv and it is not included globally either.
> 
> Further debugging[1] shows
> 
> | ERROR: calledvar=autotools_do_configure, vars=[['gitpkgv_do_configure', 'autotools_do_configure'], ['do_configure', 'gitpkgv_do_configure']], allvars=['do_configure', 'autotools_do_configure', 'gitpkgv_do_configure'], classes=[None, 'gitpkgv', 'autotools']
> 
> for such a recipe (note the 'gitpkgv_do_configure')
> 
> 
> For me, it seems that this depends on the (random) order in which recipes
> are read.  E.g. when a recipe using 'gitpkgv' is read first, the global
> 'classes' array will contain 'gitpkgv' and ExportFuncsNode() is constructed
> with it.
> 
> But when m4 is read before the first recipe using 'gitpkgv', it won't be
> contained in 'classes' and the corresponding ExportFuncsNode() will not
> create this variable.
> 
> 
> Does somebody know how to fix this?

Actually, I think I do have theory for what is happening. I think there
is some kind of exception happening in one of your recipes which is
perhaps causing it to be skipped/ignored and this is corrupting the
state of the parser.

I'm guessing the classes variable in BBConfHandler.py isn't getting
reset to [None, ] and hence the next recipe to be parsed sees "oddness"
due to the field not being reset.

This would happen in the classes.remove(__classname__) line never get
called, which would happen if statements.eval(d) or some other part of
the processing failed.

I would add some debug code into gitpkgv.bbclass around the functions
there, perhaps a try:/except: and see if there is some kind of uncaught
exception happening for one of your recipes. If that isn't it, I would
be intersted to understand what you have which is breaking out the
fetcher. It could be a SkipPackage exception under some circumstance for
example.

This would explain the cause, we then need to fix the parser state
engine so its properly reset each time...

Cheers,

Richard

Re: Complete rebuilds due to random hashes

[Enrico Scholz]

Richard Purdie <richard.purdie@linuxfoundation.org> writes:

>> I have encountered the problem the whole distribution gets rebuilt when
>> I change a single, completely unrelated variable (e.g. BB_DISKMON_DIRS).
>> 
>> Dumping data in _build_data() (siggen.py) revealed that sometimes a
>> gitpkgv_do_configure() (or _do_compile/install...) function is in the
>> deps, sometimes not.
> ...
> I would add some debug code into gitpkgv.bbclass around the functions
> there, perhaps a try:/except: and see if there is some kind of uncaught
> exception happening for one of your recipes. If that isn't it, I would
> be intersted to understand what you have which is breaking out the
> fetcher. It could be a SkipPackage exception under some circumstance for
> example.

Sorry, my fault.  I patched bitbake to ignore SkipPackage[1] and missed
that the global 'classes' variable was not reset.

fwiw, patch was required to allow 'gitpkgv' recipes to be skipped
e.g. because no git branch exists for the corresponding setup. Expansion
of PV will fail in this case with a fetcher error.




Enrico

Footnotes: 
[1]  https://github.com/ensc/bitbake/commit/fe0093b34dabe979c81a9b428de96ba73a4e3edb
     (working variant)

Re: [bitbake-devel] Complete rebuilds due to random hashes

[Enrico Scholz]

Richard Purdie <richard.purdie@linuxfoundation.org> writes:

>> I have encountered the problem the whole distribution gets rebuilt when
>> I change a single, completely unrelated variable (e.g. BB_DISKMON_DIRS).
>> 
>> Dumping data in _build_data() (siggen.py) revealed that sometimes a
>> gitpkgv_do_configure() (or _do_compile/install...) function is in the
>> deps, sometimes not.
> ...
> I would add some debug code into gitpkgv.bbclass around the functions
> there, perhaps a try:/except: and see if there is some kind of uncaught
> exception happening for one of your recipes. If that isn't it, I would
> be intersted to understand what you have which is breaking out the
> fetcher. It could be a SkipPackage exception under some circumstance for
> example.

Sorry, my fault.  I patched bitbake to ignore SkipPackage[1] and missed
that the global 'classes' variable was not reset.

fwiw, patch was required to allow 'gitpkgv' recipes to be skipped
e.g. because no git branch exists for the corresponding setup. Expansion
of PV will fail in this case with a fetcher error.




Enrico

Footnotes: 
[1]  https://github.com/ensc/bitbake/commit/fe0093b34dabe979c81a9b428de96ba73a4e3edb
     (working variant)