summaryrefslogtreecommitdiffstats
path: root/doc/README.imx31
diff options
context:
space:
mode:
authorStephen Warren <swarren@nvidia.com>2016-02-10 16:54:37 -0700
committerTom Rini <trini@konsulko.com>2016-02-15 20:58:29 +0000
commit93134e18e8772ad87a3c94d5d64970659835c944 (patch)
tree1fa0078ec90d2d83da5060c6af643f54f7dbe3e2 /doc/README.imx31
parent1326022c2edf4210f5726fb6a46ebbbb2926230f (diff)
downloadblackbird-obmc-uboot-93134e18e8772ad87a3c94d5d64970659835c944.tar.gz
blackbird-obmc-uboot-93134e18e8772ad87a3c94d5d64970659835c944.zip
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 'doc/README.imx31')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud