diff options
author | Richard Purdie <richard.purdie@linuxfoundation.org> | 2021-06-15 12:00:33 -1000 |
---|---|---|
committer | Richard Purdie <richard.purdie@linuxfoundation.org> | 2021-06-19 17:06:14 +0100 |
commit | 0e0af15b84e07e6763300dcd092b980086b9b9c4 (patch) | |
tree | cc8d397dc6168737068c10a89873977dad593f3e /.gitignore | |
parent | fe1b57f4d39c287526353387e164c863eb9df421 (diff) | |
download | bitbake-2020-04.10-dunfell.tar.gz |
cooker: Avoid parser deadlocksyocto-3.1.9yocto-3.1.102020-04.9-dunfell2020-04.10-dunfell1.46.91.46.10
If you make parsing fail (e.g. add something like:
X := "${@d.getVar('MCMACHINES').split()[1]}"
to meson.bbclass, then run "while true; do bitbake -g bash; done"
it will eventually hang. It appears the cancel_join_thread() call the
parsing failure triggers, breaks the results_queue badly enough that it
sits in read() indefintely (called from self.result_queue.get(timeout=0.25)).
The timeout only applies to lock aquisition, not the read call.
I've tried various other approaches such as using cancel_join_thread()
in other places but the only way things don't lock up is to avoid
cancel_join_thread() entirely for results_queue.
I do have a concern that this may adversely affect Ctrl+C handling
but equally, its broken now already and this appears to improve
things.
[YOCTO #14034]
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to '.gitignore')
0 files changed, 0 insertions, 0 deletions