aboutsummaryrefslogtreecommitdiffstats
path: root/lib/bb/parse/parse_py/BBHandler.py
diff options
context:
space:
mode:
authorRichard Purdie <richard.purdie@linuxfoundation.org>2021-06-15 12:00:33 -1000
committerRichard Purdie <richard.purdie@linuxfoundation.org>2021-06-19 17:06:14 +0100
commit0e0af15b84e07e6763300dcd092b980086b9b9c4 (patch)
treecc8d397dc6168737068c10a89873977dad593f3e /lib/bb/parse/parse_py/BBHandler.py
parentfe1b57f4d39c287526353387e164c863eb9df421 (diff)
downloadbitbake-contrib-0e0af15b84e07e6763300dcd092b980086b9b9c4.tar.gz
cooker: Avoid parser deadlocks
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 'lib/bb/parse/parse_py/BBHandler.py')
0 files changed, 0 insertions, 0 deletions