[bitbake-devel] [PATCH 5/8] runqueue.py: check results[0] in keys of build_pids before being used to avoid exceptions
Wang, Shane
shane.wang at intel.com
Fri Mar 30 06:11:24 UTC 2012
By the way, I have never met the exception when I do "normally stop" the bitbake.
--
Shane
Wang, Shane wrote on 2012-03-30:
> Richard Purdie wrote on 2012-03-30:
>
>> On Thu, 2012-03-29 at 20:54 +0800, Shane Wang wrote:
>>>
>>>
>>> ne.wang at intel.com>
>>> To:
>>> bitbake-devel at lists.openembedded.org
>>> Subject:
>>> [bitbake-devel] [PATCH 5/8]
>>> runqueue.py: check results[0] in
>>> keys of build_pids before being
>>> used to avoid exceptions
>>> Date:
>>> Thu, 29 Mar 2012 20:54:54 +0800
>>> (29/03/12 13:54:54)
>>>
>>>
>>> [Yocto #2186]
>>>
>>> Signed-off-by: Shane Wang <shane.wang at intel.com>
>>> ---
>>> bitbake/lib/bb/runqueue.py | 20 ++++++++++++--------
>>> 1 files changed, 12 insertions(+), 8 deletions(-)
>>
>> This kind of change sets off alarm bells. The big question is why are
>> you seeing exceptions? I suspect you're forking off processes within hob
>> which are then confusing the waitpid code. I'd have to ask why the UI is
>> forking processes when a build is running and why we're suddenly started
>> seeing this...
> The steps I did is to "Force stop" a build and click "build packages" to rebuild.
> Then I saw the exceptions.
> In the command mode, there is no issue because the process exits.
>
> In finish_now() in runqueue.py, os.kill() kills all sub-processes but
> they don't exit. when I start a new build, self.build_pids is empty, but
> due to the above reason, os.waitpid still can get the value of pids.
>
>
>>
>> So can you please explain the problem further so we can fix the real
>> problem? I did look at #2186 but that doesn't help me either :(
> OK, I am going to submit another patch, but I think the condition check
> is also needed. Otherwise, in the current code of
> runqueue_process_waitpid(), why do we have:
> if result[0] in self.build_stamps.keys():
> del self.build_stamps[result[0]]
>
>>
>> Cheers,
>>
>> Richard
>
More information about the bitbake-devel
mailing list