qemu doesn't always behave well and can hang too.
kill it with force if it was still alive. Move clean up
commands into cleanup() function.
(From OE-Core rev: 079c2935d2f585ce49e1c7daab2155fcf0094c48)
Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When qemu machine hangs, the ssh commands done by tests
are not timing out. do_testimage() task has last logs like this:
DEBUG: time: 1673531086.3155053, endtime: 1673531686.315502
The test process is stuck for hours, or for ever if the
executing command or test case did not set a timeout correctly.
The default 300 second timeout is not working when target hangs.
Note that timeout is really a "inactive timeout" since data returned
by the process will reset the timeout.
Make the process stdout non-blocking so read() will always return
right away using os.set_blocking() available in python 3.5 and later.
Then change from python codec reader to plain read() and make
the ssh subprocess stdout non-blocking. Even with select()
making sure the file had input to be read, the codec reader was
trying to find more stuff and blocking for ever when process hangs.
While at it, add a small timeout to read data in larger chunks if
possible. This avoids reading data one or few characters at a time
and makes the debug logs more readable.
close() the stdout file in all cases after read loop is complete.
Then make sure to wait or kill the ssh subprocess in all cases.
Just reading the output stream and receiving EOF there does not mean
that the process exited, and wait() needs a timeout if the process
is hanging. In the end kill the process and return the return value
and captured output utf-8 encoded, just like before these changes.
This fixes ssh run() related deadlocks when a qemu target hangs
completely.
(From OE-Core rev: 9c63970fce3a3d6029745252a6ec2bf9b9da862d)
Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Due to using mkdtemp instead of TemporaryDirectory we needed to
manually cleanup the directory in a try finally block.
With tempfile.TemporaryDirectory we can handle the cleanup with
a "with" statement and not need to manually clean up oursevels.
(Bitbake rev: 36a231d2a45e7c87172196538d18ded81a234774)
Signed-off-by: Paulo Neves <paulo@myneves.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
branchname was set but never used in the context of _contains_lfs
method.
(Bitbake rev: a64ec64c2faf1ac6ce995cdd4e311d8be6046155)
Signed-off-by: Paulo Neves <paulo@myneves.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Added tests that verify that git-lfs works with an actual
real git-lfs server. This was not previously the case because
the repo in the test was a simulation of git-lfs but not
a real git lfs repo.
The 2 added tests are almost the same but test that the
git lfs file checkout is successfult with or without the
lfs=1 flag. The lfs=1 URI parameter is a quirk that triggers
2 different code paths for git lfs.
lfs=1, when used on git lfs repositories triggers the git lfs
downloading at the fetch bare stage.
lfs query parameter unset triggers the git lfs downloading only
on checkout as an implicit behavior of git. This leads to possible
network access on the unpack stage and outside the DL_DIR.
lfs=0 actually disables git-lfs functionality even if supported.
(Bitbake rev: d2be7f7f652360f13cd66d0850f3e19ffe2afb0a)
Signed-off-by: Paulo Neves <paulo@myneves.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Not restoring the mocked _find_git_lfs leads to other tests
failing.
(Bitbake rev: 70f848631450bd723c223227c21c60e815ee033d)
Signed-off-by: Paulo Neves <paulo@myneves.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If the inotifier code has an exception, bitbake currently hangs. Catch any
exception and exit if seen. Also check the idle thread is alive and exit
if it disappears. This should stop bitbake hanging if such a situation arises
in future such as this example:
3323260 21:48:31.554468 Running command ['getVariable', 'BBINCLUDELOGS']
Exception in thread Thread-1 (idle_thread):
Traceback (most recent call last):
File "/usr/lib64/python3.10/threading.py", line 1016, in _bootstrap_inner
self.run()
File "/usr/lib64/python3.10/threading.py", line 953, in run
self._target(*self._args, **self._kwargs)
File "/home/pokybuild/yocto-worker/oe-selftest-fedora/build/bitbake/lib/bb/server/process.py", line 408, in idle_thread
self.cooker.process_inotify_updates()
File "/home/pokybuild/yocto-worker/oe-selftest-fedora/build/bitbake/lib/bb/cooker.py", line 256, in process_inotify_updates
n.read_events()
File "/home/pokybuild/yocto-worker/oe-selftest-fedora/build/bitbake/lib/pyinotify.py", line 1207, in read_events
if fcntl.ioctl(self._fd, termios.FIONREAD, buf_, 1) == -1:
OSError: [Errno 9] Bad file descriptor
3323260 21:48:32.206995 Command Completed (socket: True)
(Bitbake rev: 358b5b02d5de1ab0f98104c4ec4953e46999b9a5)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We've seen a couple of cases which bitbake hangs due to an inotifer exception
such as:
3323260 21:48:31.554468 Running command ['getVariable', 'BBINCLUDELOGS']
Exception in thread Thread-1 (idle_thread):
Traceback (most recent call last):
File "/usr/lib64/python3.10/threading.py", line 1016, in _bootstrap_inner
self.run()
File "/usr/lib64/python3.10/threading.py", line 953, in run
self._target(*self._args, **self._kwargs)
File "/home/pokybuild/yocto-worker/oe-selftest-fedora/build/bitbake/lib/bb/server/process.py", line 408, in idle_thread
self.cooker.process_inotify_updates()
File "/home/pokybuild/yocto-worker/oe-selftest-fedora/build/bitbake/lib/bb/cooker.py", line 256, in process_inotify_updates
n.read_events()
File "/home/pokybuild/yocto-worker/oe-selftest-fedora/build/bitbake/lib/pyinotify.py", line 1207, in read_events
if fcntl.ioctl(self._fd, termios.FIONREAD, buf_, 1) == -1:
OSError: [Errno 9] Bad file descriptor
3323260 21:48:32.206995 Command Completed (socket: True)
Ensure we don't destory the inotifier when the idle thread is reading is
by holding the lock during setup/teardown.
(Bitbake rev: 8fc5c50c2e23017833f93bcd514d708a14fa4266)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Somewhere along the way this ceased to be a build requirement;
I have verified that the recipe installs the same set
of identical files with and without introspection enabled and
present in sysroot.
(From OE-Core rev: 32283136eaad7631c5253b8da538b747666d2705)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The script is operating on layer repositories, which can and do sometimes contain
several layers. This distinction is important as the script will be tweaked
to write a record of actual layer locations.
(From OE-Core rev: 833965e6001db98039c0aa816ae661232213bcea)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Using bb.fatal for a fatal error message is the best practise, switch
the code to match other call sites.
(Bitbake rev: c27e48fa81c2327a4a355a028884ab457cde3ae7)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This code appears to be dangerous, it swallows exceptions, turning them into
"handled" versions which then show no errors to the user. This is a pretty
poor user experience and I can't see why this code should be swallowing
such things. Drop the worst bits of code.
(Bitbake rev: 13279044f16f2cf2502ebf39d277415f99bb6c18)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Martin Jansa reported that if you put a syntax error into an imported
module such as qa.py in OE, no error is shown.
Part of the issue appears to be that the catch_parse_error() decorator only
catches certain exceptions and SyntaxError isn't one of them. As far as I can
tell we should remove all the special cases and use the more advanced code
in all cases, not just expansion errors.
I confirmed this now prints a proper error message for a qa.py syntax error.
(Bitbake rev: 2365d891847f8e73d1c4661ddfdab8818ff619dc)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* to be used by standalone script scripts/contrib/patchreview.py
as well
(From OE-Core rev: c326efeec8f576200728a44c694becdeab4fe2db)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
