diff options
author | Stephen Warren <swarren@nvidia.com> | 2016-02-10 16:54:37 -0700 |
---|---|---|
committer | Tom Rini <trini@konsulko.com> | 2016-02-15 20:58:29 +0000 |
commit | 93134e18e8772ad87a3c94d5d64970659835c944 (patch) | |
tree | 1fa0078ec90d2d83da5060c6af643f54f7dbe3e2 /test/common.sh | |
parent | 1326022c2edf4210f5726fb6a46ebbbb2926230f (diff) | |
download | u-boot-imx-93134e18e8772ad87a3c94d5d64970659835c944.zip u-boot-imx-93134e18e8772ad87a3c94d5d64970659835c944.tar.gz u-boot-imx-93134e18e8772ad87a3c94d5d64970659835c944.tar.bz2 |
test/py: handle exceptions in console creation
u_boot_console.exec_attach.get_spawn() performs two steps:
1) Spawn a process to communicate with the serial console.
2) Reset the board so that U-Boot starts running from scratch.
Currently, if an exception happens in step (2), no cleanup is performed on
the process created in step (1). That process stays running and may e.g.
hold serial port locks, or simply continue to read data from the serial
port, thus preventing it from reaching any other process that attempts to
read from the same serial port later. While there is error cleanup code in
u_boot_console_base.ensure_spawned(), this is not triggered since the
exception prevents assignment to self.p there, and hence the exception
handler has no object to operate upon in cleanup_spawn().
Solve this by enhancing u_boot_console.exec_attach.get_spawn() to clean
up any objects it has created.
In theory, u_boot_spawn.Spawn's constructor has a similar issue, so fix
this too.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Simon Glass <sjg@chromium.org>
Diffstat (limited to 'test/common.sh')
0 files changed, 0 insertions, 0 deletions