On Fri, 23 Mar 2012 12:20:08 +0000 Paul Eggleton <paul.eggle...@linux.intel.com> wrote:
> On Friday 23 March 2012 02:16:35 Peter Seebach wrote: > > Still really weird to me that I can't reproduce this outside of hob. > > I am pretty sure there exists a series of forks and execs and > > environment changes such that this will end up happening. > > I now have a fairly simple test case outside of hob. Put the attached > file in meta/classes/ and then add the following to your local.conf: > > INHERIT += "breakit" Okay, some notes. The magic seems to come from the interpolated Python output that itself calls os.popen from inside the shell script. A bit of poking about turns up the following: 1. The environment setup and teardown in runqueue.py don't seem to be atomic at all, such that if I annotate the stashing in envbackup with a bb.note for each variable stashed, I sometimes see a fork() call in pseudo BETWEEN two variables. Which is to say, we can be forking WHILE changing the environment. 2. The func_exec_shell calls seem to be able to call the git_branch stuff (which uses os.popen()) in a way that does not hit the runqueue code AT ALL. Meaning it operates with Whatever Environment Seems Handy. 3. I am inclined to suggest that a first pass would be to distinguish between "we need to set this, but we never need to unset it" (PSEUDO_PREFIX) and "we need to set this and then revert it" (PSEUDO_UNLOAD). 4. We should have a handler for popen() anyway, but it will not in and of itself fix the problem. I am still getting the hang of finding my way around bitbake and figuring out who's calling what. I'd guess that just making sure PSEUDO_PREFIX never gets unset would effectively mitigate the problem, but I suspect that we'll still be vulnerable to Weird Race Conditions. -s -- Listen, get this. Nobody with a good compiler needs to be justified. _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto