summaryrefslogtreecommitdiffstats
path: root/bitbake/lib/bb/cooker.py
Commit message (Collapse)AuthorAgeFilesLines
* bitbake: utils: Split profile reports into separate filesRichard Purdie26 hours1-3/+3
| | | | | | | | | Use a more logical name for the profile reports and put each report into a separate file since people struggle to discover them currently. (Bitbake rev: a8145c84e0899285a5e6a809f1515118b002b106) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: main: Add an option to specify what to profileRichard Purdie2 days1-1/+1
| | | | | | | | | | | | | | | | | | Starting with python 3.12, profiling now stays enabled over threads yet you can't extract the profile data in the threads themselves, which makes it difficult to use for our use case. Our main loop starts the idle loop which starts the parsing threads and this means we can't profile in the main loop and the parsing threads or the idle loop at the same time due to this. Add options to the commandline so you can specify which piece of bitbake you want to enable profiling for. This allows some profiling with python 3.12 onwards rather than crashing. (Bitbake rev: 09f29a4968841ee5070f70277ba8c253bb14f017) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker/process/utils: Create profiling common function to remove ↵Richard Purdie2 days1-15/+1
| | | | | | | | | | | | | | code duplication We have code duplication in the way we handle profiling of code sections. Create a common function in utils which covers this. The main loop and idle loop profile files were also reversed. Fix this and the naming, removing a couple of unused variables containing the profile log names in the process too. (Bitbake rev: b4f6bae97ac9607420fc49fd4c9e957d89c9a5f3) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: Use shared counter for processing parser jobsJoshua Watt10 days1-12/+18
| | | | | | | | | | | | | | Instead of pre-partitioning which jobs will go to which parser processes, pass the list of all jobs to all the parser processes (efficiently via fork()), then used a shared counter of the next index in the list that needs to be processed. This allows the parser processes to run independently of needing to be feed by the parent process, and load balances them much better. (Bitbake rev: 373c4ddaf0e8128cc4f7d47aefa9860bd477a00f) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: Add better parse debugRichard Purdie12 days1-1/+1
| | | | | | | | | If parsing ends early and unexpectedly, add some internal values to better understand why/how it failed. (Bitbake rev: 775f9720a17c9f3d6815d42c733ab5aaaa53749c) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: Try and avoid parsing hangsRichard Purdie12 days1-9/+15
| | | | | | | | | | | | | | | | | | | | | | We sometimes see hangs in parsing during automated testing. It appears that SIGINT was sent to the underlying processes which see KeyboardInterrupt but they're stuck trying to write into the results pipe. The SIGINT was probably from some kind of parsing failure which doens't happen often, hence the hang being rare (in the incompatible license selftests from OE). This patch: * sets a flag to indicate exit upon SIGINT so the exit is more graceful and a defined exit path * empties the results queue after we send the quit event * empties the results queue after the SIGINT for good measure * increases the 0.5s timeout to 2s since we now have some very slow to parse recipes due to class extensions (ptests) This should hopefully make the parsing failure codepaths more robust. (Bitbake rev: 5b533370595f83b87e480bace3e0b42c9ba61e22) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: Add debug for parsing being completeRichard Purdie2025-03-111-0/+1
| | | | | | | | | | We have a "parsing started" event in the cooker deamon log but we don't currently log the corresponding "parsing complete" event which is confusing. Add this so that the logs are more logical. (Bitbake rev: 1aa491c1f1211bf9faab712c321b66629fb7be66) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: lib/bb/cooker.py: produce an error when BB_HASHSERVE_UPSTREAM ↵Alexander Kanavin2025-03-061-2/+8
| | | | | | | | | | | | | | | | cannot be used due to missing python module Previously if the websockets module was not installed bitbake would only print a warning and continue, resulting in a degraded user experience due to inability to use the configured sstate server. Let's consider that as fatal misconfiguration, so that users can address the issue properly and not wonder why builds are taking forever. (Bitbake rev: cfba2a9fca9dfa3b05ec9040fe0cb8143ac04af7) Signed-off-by: Alexander Kanavin <alex@linutronix.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: Make cooker 'skiplist' per-multiconfig/mcChris Laplante2024-12-171-5/+6
| | | | | | | | | | | | | | | | | | Previously, the cooker skiplist was shared across multiconfigs (including default ''). If you had a recipe that was incompatible with several multiconfigs for different reasons, then the displayed reason (i.e. the "ERROR: Nothing PROVIDES" and "* was skipped" messages) might vary across invocations of bitbake. This was caused by the random order in which recipes are parsed under different multiconfig contexts, with each skip reason overwriting the previously assigned reason. I hit this specificially when using COMPATIBLE_MACHINE, but COMPATIBLE_HOST (or anything using bb.parse.SkipRecipe) would have done it too. (Bitbake rev: c51f01a35ed9a928402eab0899598b5c59602eef) Signed-off-by: Chris Laplante <chris.laplante@agilent.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: use enum for cooker state to improve readabilityChris Laplante2024-12-061-30/+28
| | | | | | | | | enum was introduced in Python 3.4 (Bitbake rev: 35b71a94f8757fcca830f972a42edab1dd000c16) Signed-off-by: Chris Laplante <chris.laplante@agilent.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: Remove custom exception backtrace formattingJoshua Watt2024-11-281-8/+24
| | | | | | | | | | | | | | | | | | | | | | | Removes the code in bitbake to show custom backtrace formatting for exceptions. In particular, the bitbake exception code prints function arguments, which while helpful is a security problem when passwords and other secrets can be passed as function arguments. As it turns out, the handling of the custom serialized exception stack frames was pretty much made obsolete by d7db75020ed ("event/msg: Pass formatted exceptions"), which changed the events to pass a preformatted stacktrack list of strings, but the passing of the serialized data was never removed. Change all the code to use the python traceback API to format exceptions instead of the custom code; conveniently traceback.format_exception() also returns a list of stack trace strings, so it can be used as a drop in replacement for bb.exception.format_exception() (Bitbake rev: 2cda75a185aaf8f657f072dac34f8cef9d75f63a) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: Drop support for BB_DANGLINGAPPENDS_WARNONLYRichard Purdie2024-11-211-7/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | DANGLINGAPPENDS_WARNONLY is a very poorly designed interface and is commonly abused. The challenge is that once it is set, by any layer, it applies everywhere. Some layers rely on this to get notification they need to update bbappend files and having the behaviour change from inclusion of an antisocial layer is not good. In addition, showing warnings as an accepted thing on the console devalues them and trains the user to ignore them. I want to steer us away from this mindset. We could extend the functionality and make it apply only to certain layers, or only to certain appends but then we've basically re-invented BBMASK. Given all the above, we should drop support for BB_DANGLINGAPPENDS_WARNONLY and direct anyone with issues to BBMASK instead. https://lists.openembedded.org/g/openembedded-architecture/message/2029 [YOCTO #14870] (Bitbake rev: fca9c9e3cb6f8e9f99bf51dc5e8a8d83f4c84c69) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: Sort pn-buildlistRobert Yang2024-11-051-4/+5
| | | | | | | | | So that we can compare the different pn-buildlist easily. (Bitbake rev: 529043117a7c62feb45bc891658a412cc8dd7e3f) Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cookerdata: Separate out data_hash and hook to tinfoilRichard Purdie2024-08-131-3/+7
| | | | | | | | | | | | | | | | | Within tinfoil, the user can write to the configuration data but it won't cause the data_hash checksum to be re-written, meaning cached parsing data can be reused when it would now be incorrect. Abstract out the data_hash code and add it to the invalidateCaches command, called by tinfoil.modified_files() meaning that tinfoil can instruct bitbake to update the caches and re-parse if necessary. Also move the data_hash entirely into databuilder and drop the copy in cooker as obsolete and not needed. (Bitbake rev: d9ee77829f693ce75348fa64f406fcecfe4989aa) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: Drop older python version compatibility codeRichard Purdie2024-05-311-5/+4
| | | | | | | | | | | | | | cooker: We can call multiprocessing close() unconditionally and tweak a comment give 3.8 is now the minimum version. lib/bb: We can drop the logger addition code only needed before 3.6 asyncrpc/hashserv: Since the minimum version is 3.8, we can drop the conditional code. (Bitbake rev: 16f4386400f88ba50605307961c248bef09895c1) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: Improve handling errors during parsing when profilingRichard Purdie2024-05-311-4/+5
| | | | | | | | | We've seeing profiling tracebacks when parse errors occur during profiling. Try and avoid these but not processing invalid profiles. (Bitbake rev: 171bd9dd575307fbd61b5179ad86131d76add067) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue: Process unihashes in parallel at initRichard Purdie2024-05-281-1/+0
| | | | | | | | | | | | | | Improve the runqueue init code to call unihash queries in parallel since this is faster and more efficient, particularly on slower links with longer round trip times. The call to the function from cooker is unneeded since that function calls prepare() and hence this functionality will already have run, so drop that obsolete call. (Bitbake rev: 721c97a115a7a4bf21955be79391bd6e0099f40e) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: Ensure generateTaskDepTreeData fails for NoProviderRichard Purdie2024-05-171-3/+3
| | | | | | | | | | If an invalid provider is requested, error out early rather than trying to build partial runqueue data structures as the taskdep UI will have exited after seeing the bad provider. (Bitbake rev: a478087998cb794cc4e31189b3ce07973d3949bc) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: Handle ImportError for websocketsjoshua Watt2024-05-081-1/+2
| | | | | | | | | | | | Handles ImportError when creating a hash equivalence to ping the server. This notifies user earlier with a more precise error if websockets can't be used, and also prevents passing a known bad upstream value to the local server (Bitbake rev: aa80b3cfc5d16dfba13ca7fb9b78bae179ce3b74) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: Use hash client to ping upstream serverjoshua Watt2024-05-021-4/+3
| | | | | | | | | | | | | | The cooker attempts to connect to the upstream hash equivalent server to warn the user early if it is misconfigured. However, this was making the assumption that it was a raw TCP connection and failed when attempting to use a websocket upstream server. Fix this by creating an hash client and using the ping API to check the server instead of using a raw socket. (Bitbake rev: 5e84c13a6c594ed34c341849806657ddda206714) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: Avoid eventlog variable listing lockupsRichard Purdie2023-11-271-25/+11
| | | | | | | | | | | | | | | If the event log is enabled and parsing the metadata triggers log messages, the event code and deadlock. Iterating the variables inside the event handling code causes this. SOURCE_DATE_EPOCH triggers a python function which calls bb.debug() and can trigger a lockup as one example. Move the code around and add it to the BuildStarted events explictly. This does mean runs without builds no longer get variables added to the eventlog however we can look into a more targetted version of data if/as/where neded. (Bitbake rev: 4135a617ae16d509362b5bf56378139cdc0876d2) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: Avoid sideeffects for autorev from getAllKeysWithFlagsRichard Purdie2023-11-231-0/+7
| | | | | | | | | | | | | If we expand the variable AUTOREV in OE-Core, it triggers side effects in the fetcher. The situation isn't ideal and needs improvement but this breaks and is blocking enabling BB_DEFAULT_EVENTLOG. Hack around the issue for now so we unblock things until we can work out a better plan for how to improve AUTOREV support. (Bitbake rev: cb9b6530f3d12c56a8b48847af2e7461924205d2) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: Add support for BB_DEFAULT_EVENTLOGRichard Purdie2023-11-231-8/+17
| | | | | | | | | | Currently it is only possible to specify an eventlog on the bitbake commandline. Add a variable that can be used in bitbake.conf so that we can log data by default more easily. (Bitbake rev: ee174b231897a53cdde0f68769518342e53210cf) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: asyncrpc: Add option to set log level when running as a processJoshua Watt2023-11-141-1/+1
| | | | | | | | | | | | | | | | When running an asyncrpc server as a subprocess, it is often desired to run it with a lower logging level since the normal logging of clients connecting and disconnecting is not desired. As such, add an option to set the logging level of the server when running as a subprocess and set the level to WARNING when starting a local hashserver or PRserver (Bitbake rev: 61dac7b99ad6d2a858f85d8ed1b5524d558be6c8) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: Fix find_bbfiles string endswith callBELHADJ SALEM Talel2023-10-231-1/+1
| | | | | | | | (Bitbake rev: 5f742591b251b6a5302ab07fe6b809c2863c3c70) Signed-off-by: Talel BELHAJSALEM <bhstalel@gmail.com> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: cooker: add a new function to retrieve task signaturesJulien Stephan2023-09-281-0/+31
| | | | | | | | | | | | adding a new command in cooker to compute and get task signatures this commit also add the associated command and event needed to get the signatures using tinfoil (Bitbake rev: 05c15162de90c41dad67e37a95ec9fdb440a7864) Signed-off-by: Julien Stephan <jstephan@baylibre.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: Drop unneeded flush callsRichard Purdie2023-09-201-3/+0
| | | | | | | | | | Since the flush calls have significant effects for bitbake timeout issues, drop the remaining ones from cooker. These aren't in as critical paths as the other issues but it makes sense to clean up. (Bitbake rev: dd682363341bae3b060e284d73f000813964dc05) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: lib: Drop inotify support and replace with mtime checksRichard Purdie2023-09-181-139/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With the flush in serverlog() removed and a memory resident bitbake with a 60s timeout, the following could fail in strange ways: rm bitbake-cookerdaemon.log bitbake-layers add-layer ../meta-virtualization/ bitbake-layers add-layer ../meta-openembedded/meta-oe/ bitbake -m specifically that it might error adding meta-oe with an error related to meta-virt. This clearly shows that whilst bblayers.conf was modified, bitbake was not recognising that. This would fit with the random autobuilder issues seen when the serverlog flush() call was removed. The issue appears to be that you have no way to "sync()" the inotify events with the command stream coming over the socket. There is no way to know if there are changes in the IO queue which bitbake needs to wait for before proceeding with the next command. I did experiment with os.sync() and fsync on the inotify fd, however nothing addressed the issue. Since it is extremely important we have accurate cache data, the only realistic thing to do is to switch to stat() calls and check mtime. For bitbake commands, this is straightforward since we can revalidate the cache upon new connections/commands. For tinfoil this is problematic and we need to introduce and explict command "revalidateCaches" that the code can use to force bitbake to re-check it's cache validity. I've exposed this through tinfoil with a new "modified_files" function. So, this patch: a) drops inotify support within bitbake's cooker/server and switch to using mtime b) requires a new function call in tinfoil when metadata has been modified (Bitbake rev: da3ec3801bdb80180b3f1ac24edb27a698415ff7) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: Fix error messageJoshua Watt2023-08-161-1/+1
| | | | | | | | | "Not" should be "No" (Bitbake rev: a06619951a43acb80b80d92e0caac560657ca249) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: Log when parsing starts in server logRichard Purdie2023-06-301-0/+1
| | | | | | | | | | | It is unclear from the server logs when parsing starts. We know that timeouts sometimes happen when parsing but it is unclear where in the code the delays are from. Adding this debug message to the server log should help narrow that down. (Bitbake rev: a5c145f436d68f090b113cfb9b82857adc95b546) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: Add FILE_LAYERNAME variable containing the layername for a ↵Richard Purdie2023-05-251-14/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | recipe There are times when it would be useful for code to know which layer (or collection in old bitbake terms) it is contained within. Add support for FILE_LAYERNAME to be set by bitbake when parsing a recipe so that it is possible to determine this. To do it, we need to pass data from the cooker into the recipe endpoints, since only the top level cooker information knows about the layer structure which makes the patch a bit painful. The idea is that this would make layer overrides possible: OVERRIDES .= ":layer-${FILE_LAYERNAME}" which then opens possibilities like: WARN_QA:append:layer-core = " patch-fuzz" as an example where OE-Core could enable specific QA tests only for that specific layer. (Bitbake rev: 7090a14b0035842112d073acf7f2ed1a01fdeccf) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: Fix/improve collections handlingRichard Purdie2023-05-251-5/+5
| | | | | | | | | | | | | | | | Code changes for FILE_LAYERNAME exposed lifecycle issues around the collections object in Cooker which only appeared in devtool usage in eSDK. Move the collections setup to an earlier stage after parsing completes to avoid any kind of race around it. Also stop overwriting the code variable in MatchFiles. Ultimately we need to combine these codepaths but that is for another patch. (Bitbake rev: 27b872ed4fbe73b3b61e14cb885bb7c16c039cdb) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: Log config and parse cache status changesRichard Purdie2023-05-021-12/+27
| | | | | | | | | | It can be hard to tell why bitbake does some things slowly. Log the changes to the base configuration and parse cache status so that it becomes clear from the logs when the cache invalidation causes a slowdown. (Bitbake rev: 6e99d89f3c00a5f53c24d687eaef24f52fe0ef99) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: do not abort on single ctrl-cEnrico Scholz2023-04-201-1/+1
| | | | | | | | | | | | | | | | After b7ed7e9a815c4e10447fd499508be3dbb47f06e8 bitbake aborts immediately when a single ctrl-c is pressed. Patch restores the previous behavior where a single ctrl-c waits for active tasks to finish. https://bugzilla.yoctoproject.org/show_bug.cgi?id=15094 (Bitbake rev: 66131fa6a3e12c28710d09e1dbf3c03f2981280d) Signed-off-by: Enrico Scholz <enrico.scholz@sigma-chemnitz.de> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: event: add bb.event.ParseErrorMingli Yu2023-04-131-2/+3
| | | | | | | | | Add bb.event.ParseError to let error-report can catch this kind of error. (Bitbake rev: 316524ab59a5e738c25e062923ee5717d88ae5c7) Signed-off-by: Mingli Yu <mingli.yu@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: Fix memory resident cache invalidation issueRichard Purdie2023-02-241-6/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We've been seeing weird PRServ failures on the autobuilder. These had one failure always followed by a second. Whilst I can't reproduce the first, if I made that test fail, I could reproduce the second with memory resident bitbake. This was with the tests: prservice.BitbakePrTests.test_import_export_replace_db and then prservice.BitbakePrTests.test_pr_service_deb_arch_dep which was giving a strange looking error: NOTE: Running task 1053 of 1055 (/home/pokybuild/yocto-worker/oe-selftest-debian/build/meta/recipes-devtools/m4/m4_1.4.19.bb:do_package_write_rpm) NOTE: Running task 1054 of 1055 (/home/pokybuild/yocto-worker/oe-selftest-debian/build/meta/recipes-devtools/m4/m4_1.4.19.bb:do_package_qa) ERROR: No such task: do_package_write_rpm ERROR: Task (/home/pokybuild/yocto-worker/oe-selftest-debian/build/meta/recipes-devtools/m4/m4_1.4.19.bb:do_package_write_rpm) failed with exit code '1' where the issue is that selftest.inc written by the test framework and containing PACKAGE_CLASSES = "package_deb" was being ignored. The issue is the cached_statements{} within BBHandler() is not being invalidated at the right time. This patch changes the code to ensure base configuration is not parsed until inotify updates have been processed. (Bitbake rev: cada37c6b9e5862ca2c5a54ad6fd1e1f1939cd9c) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: event/cooker/runqueue: Add ability to interrupt longer running codeRichard Purdie2023-02-231-0/+4
| | | | | | | | | | | | | | | | | | | | Bitbake is now able to understand when a UI wants it to stop the current processing. There are some long running functions which currently have no mechanism to interrupt them however. This patch adds a call, bb.event.check_for_interrupts(d) which can be placed in long running code and allows an internal state flag within bitbake to be checked. If set, that flag will trigger an exit. This means that Ctrl+C can be made to work in a variety of places where it currently would not. Long running event handlers in OE-Core can also then benefit from this new approach with the addition of the function call as well. (Bitbake rev: b7ed7e9a815c4e10447fd499508be3dbb47f06e8) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: Ensure lock is held with changing notifierRichard Purdie2023-02-201-16/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* bitbake: cache/codeparser: Switch to a new BB_CACHEDIR variable for cache ↵Richard Purdie2023-01-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | location Currently the codeparser cache is set from CACHE, which is typically in bitbake.conf which means we can't read/write any cache until it is found/read. We may well have python expressions to parse before that happens. The net result is suboptimal functioning of the codeparser cache since it will often be invalidated by data that is never written. This patch changes the codeparser and filechecksum caches to use BB_CACHE as their setting and defaults it to ${TOPDIR}/cache. The patch doesn't change where the "persistent" data such as prserver and hash-equiavalance resides (PERSISTENT_DIR) or where the metadata parsing cache resists (still currently CACHE). I've left those for a later patch. The patch does ensure data parsed by the core datastore parsing calls is written back since this is now much more useful after this change. (Bitbake rev: ee89ade5b5a4cf9c53f336d8b800e06fbe436628) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: Fix parsing race around cache handlingRichard Purdie2023-01-241-8/+8
| | | | | | | | | | | | | When draining the result queue from the parsing processes, cache objects can be created even if they are then immediately destroyed. The reset in the sync code needs to happen after any objects have been created. Change the ordering to fix this. This ordering has caused various cache errors, particularly when interrupting parsing with Ctrl+C. (Bitbake rev: f45a94e6720dacf7f51ac147c115a6f608769093) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: Fix siggen recipe cache race issueRichard Purdie2023-01-241-2/+1
| | | | | | | | | We need to reset the cache before the start() call which starts the parsing processs, tweak the code to ensure this is the case. (Bitbake rev: 4712d6237df5d2188238294fbdb9f107b068a3a7) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: Fix exit handling issuesRichard Purdie2023-01-111-6/+4
| | | | | | | | | | | | | The shutdown() call should definitely not be waiting for idle, since we expect execution and events to continue even after setting either shutdown state. This was causing the UI to appear to hang at Ctrl+C interrupts. Also ensure that if we reset cooker, we stop any active parser processes since these currently appear to be being left behind. (Bitbake rev: 4f73c2eb12ee074f3b7d4717380649f6ca8f3def) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: process/cooker/command: Fix currentAsyncCommand locking/racesRichard Purdie2023-01-111-4/+8
| | | | | | | | | | | | | | currentAsyncCommand currently doesn't have any locking and we have a conflict in "idle" conditions since the idle functions count needs to be zero *and* there needs to be no active command. Move the changes/checks of currentAsyncCommand to within the lock and then we can add it to the condition for idle, simplifying some of the code. (Bitbake rev: b5215887d2f8ea3f28f1ebda721bd5b8f93ec7f3) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker/command: Drop async command handler indirection via cookerRichard Purdie2023-01-111-9/+0
| | | | | | | | | Indirecting the async command handler via cooker is confusing and no longer needed. Drop it to make things slightly clearer. (Bitbake rev: 4a41a7d0594e6a84a67b9de70a505858aebcd84a) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: Clean up inotify idle handlerRichard Purdie2023-01-061-6/+0
| | | | | | | | | We no longer need to abstract the inotify callback handler, remove the abstraction and simplify/clean up the code. (Bitbake rev: af4ccab8acc49e91bf7647f209d69f4858618466) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: Rework the parsing results submissionRichard Purdie2023-01-061-11/+15
| | | | | | | | | | | | | The loop submitting the parser results was not efficient on many core systems as may of the parsers could block for a long time waiting to send the results. While a result was pending, the code wouldn't parse further jobs. Change the code to parse further jobs even if the results can't be submitted and lower the result submission timeout to keep the parsers busy. (Bitbake rev: 9ece4a2e406509bd89dbce8dac80a02e600b0ecf) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: lib/bb: Update thread/process locks to use a timeoutRichard Purdie2023-01-051-2/+2
| | | | | | | | | | | | | | | | | | | | | The thread/process locks we use translate to futexes in Linux. If a process dies holding the lock, anything else trying to take the lock will hang indefinitely. An example would be the OOM killer taking out a parser process. To avoid bitbake processes just hanging indefinitely, add a timeout to our lock calls using a context manager. If we can't obtain the lock after waiting 5 minutes, hard exit out using os._exit(1). Use _exit() to avoid locking in any other places trying to write error messages to event handler queues (which also need locks). Whilst a bit harsh, this should mean we stop having lots of long running processes in cases where things are never going to work out and also avoids hanging builds on the autobuilder. (Bitbake rev: d2a3f662b0eed900fc012a392bfa0a365df0df9b) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: server/process: Run idle commands in a separate idle threadRichard Purdie2022-12-311-8/+21
| | | | | | | | | | | | | | | | | | | | | | | | | When bitbake is off running heavier "idle" commands, it doesn't service it's command socket which means stopping/interrupting it is hard. It also means we can't "ping" from the UI to know if it is still alive. For those reasons, split idle command execution into it's own thread. The commands are generally already self containted so this is easier than expected. We do have to be careful to only handle inotify poll() from a single thread at a time. It also means we always have to use a thread lock when sending events since both the idle thread and the command thread may generate log messages (and hence events). The patch depends on previous fixes to the builtins locking in event.py and the heartbeat enable/disable changes as well as other locking additions. We use a condition to signal from the idle thread when other sections of code can continue, thanks to Joshua Watt for the review and tweaks squashed into this patch. We do have some sync points where we need to ensure any currently executing commands have finished before we can start a new async command for example. (Bitbake rev: 67dd9a5e84811df8869a82da6a37a41ee8fe94e2) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: server/process: Improve idle loop exit codeRichard Purdie2022-12-311-8/+5
| | | | | | | | | | | | | | When idle handlers want to exit, returning "False" isn't very clear and also causes challenges with the ordering of the removing the idle handler and marking that no async command is running. Use a specific class to signal the exit condition allowing clearer code and allowing the async command to be cleared after the handler has been removed, reducing any opportunity for races. (Bitbake rev: 102e8d0d4c5c0dd8c7ba09ad26589deec77e4308) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: Ensure commands clean up any parser processesRichard Purdie2022-12-311-0/+3
| | | | | | | | | When finishing a command, we need to ensure any parsing processes that may have been started are cleaned up before we reset the cooker state. (Bitbake rev: 6569ab64bea35de21acc89053ba76e2828163f3f) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2025-07-19 17:12:37 +0000