Summary: | sys-apps/portage-3.0.62: -e @world gets interrupted | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Sam James <sam> |
Component: | Core | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | fcoiffie, zmedico |
Priority: | Normal | Keywords: | InVCS |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: |
https://github.com/gentoo/portage/pull/1278 https://bugs.gentoo.org/show_bug.cgi?id=932241 |
||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 925214 | ||
Bug Blocks: |
Description
Sam James
2024-02-23 13:11:00 UTC
It might be that the first one is just noise from an emerge --sync while the -e is running, but it seems weird that it died on a live ebuild which is still in tree. (In reply to Sam James from comment #0) > I had this just now with a world rebuild: > ``` > $ emerge -ev @world > [...] > >>> Completed (515 of 2557) sys-devel/llvm-17.0.6::gentoo > > >>> Emerging (516 of 2557) sys-devel/gcc-14.0.9999::gentoo > [ERROR] Exception in callback AsynchronousTask._exit_listener_cb(<bound > method...ffff9b50e200>>) > handle: <Handle AsynchronousTask._exit_listener_cb(<bound > method...ffff9b50e200>>)> > Traceback (most recent call last): > File "/usr/lib/python3.11/asyncio/events.py", line 84, in _run > self._context.run(self._callback, *self._args) > File "/usr/lib/python3.11/site-packages/_emerge/AsynchronousTask.py", line > 209, in _exit_listener_cb > listener(self) > File "/usr/lib/python3.11/site-packages/_emerge/EbuildBuild.py", line 77, > in _start_with_metadata > (settings.configdict["pkg"]["SRC_URI"],) = aux_get_task.future.result() > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > File "/usr/lib/python3.11/site-packages/portage/dbapi/porttree.py", line > 786, in async_aux_get > raise AssertionError( > AssertionError: async_aux_get called from thread <_MainThread(MainThread, > started 281473559502880)> with loop > <_emerge.Scheduler.Scheduler._iface_class object at 0xffff8e3a8840> > Terminated > ``` https://github.com/gentoo/portage/pull/1278 should fix this but I haven't tested it yet. > There's another issue w/ emerge --version too: > ``` > $ emerge --version > Portage 3.0.62 (python 3.11.8-final-0, default/linux/arm64/17.0/hardened, > gcc-14, glibc-2.38-r11, 5.15.148-gentoo-dist aarch64) > [ERROR] Task was destroyed but it is pending! > task: <Task pending name='Task-4' coro=<ForkProcess._main() running at > /usr/lib/python3.11/site-packages/portage/util/_async/ForkProcess.py:200> > wait_for=<Future pending cb=[AsynchronousTask.async_wait.<locals>.<lambda>() > at /usr/lib/python3.11/site-packages/_emerge/AsynchronousTask.py:49, > Task.task_wakeup()]> cb=[SpawnProcess._main_exit()]> Hmm, that could be something like one of the stty spawns, so we really need to make it return a Future to wait for when the event loop is running: commit f97e414ce980299acc962e357db24106d62e4c7c Author: Zac Medico <zmedico@gentoo.org> Date: Sat Feb 3 22:12:00 2024 -0800 set_term_size: Wait asynchronously if event loop is running When set_term_size is called from an asynchronous context, we can wait for the process to exit asynchronously. This will prevent a "RuntimeError: This event loop is already running" error in the future when synchronous spawn calls will need to run the event loop in order to wait for the spawned process(es). Bug: https://bugs.gentoo.org/923750 Signed-off-by: Zac Medico <zmedico@gentoo.org> (In reply to Zac Medico from comment #2) > > There's another issue w/ emerge --version too: > > ``` > > $ emerge --version > > Portage 3.0.62 (python 3.11.8-final-0, default/linux/arm64/17.0/hardened, > > gcc-14, glibc-2.38-r11, 5.15.148-gentoo-dist aarch64) > > [ERROR] Task was destroyed but it is pending! > > task: <Task pending name='Task-4' coro=<ForkProcess._main() running at > > /usr/lib/python3.11/site-packages/portage/util/_async/ForkProcess.py:200> > > wait_for=<Future pending cb=[AsynchronousTask.async_wait.<locals>.<lambda>() > > at /usr/lib/python3.11/site-packages/_emerge/AsynchronousTask.py:49, > > Task.task_wakeup()]> cb=[SpawnProcess._main_exit()]> > > Hmm, that could be something like one of the stty spawns, so we really need > to make it return a Future to wait for when the event loop is running: > > commit f97e414ce980299acc962e357db24106d62e4c7c > Author: Zac Medico <zmedico@gentoo.org> > Date: Sat Feb 3 22:12:00 2024 -0800 > > set_term_size: Wait asynchronously if event loop is running Also, it might be possible for the ForkProcess instance used by _start_proc to trigger this (introduced in a69c1b853a47 for bug 916566), since _start_proc only returns the associated MultiprocessingProcess instance, so the ForkProcess instance can get garbage collected before its main coroutine exits. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/portage.git/commit/?id=acb69a6f234bd412e95e76f5c1db1b1f5b8e1dc5 commit acb69a6f234bd412e95e76f5c1db1b1f5b8e1dc5 Author: Zac Medico <zmedico@gentoo.org> AuthorDate: 2024-02-24 03:52:47 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2024-02-24 04:23:27 +0000 SchedulerInterface/PollScheduler: Add _loop property This allows async_aux_get to easily verify the identity of the underlying loop so that this assertion will not fail: _start_with_metadata (settings.configdict["pkg"]["SRC_URI"],) = aux_get_task.future.result() ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3.11/site-packages/portage/dbapi/porttree.py", line 786, in async_aux_get raise AssertionError( AssertionError: async_aux_get called from thread <_MainThread(MainThread, started 281473559502880)> with loop <_emerge.Scheduler.Scheduler._iface_class object at 0xffff8e3a8840> Terminated Fixes: 389bb304abf5 ("async_aux_get: Use EbuildMetadataPhase deallocate_config future") Bug: https://bugs.gentoo.org/925333 Signed-off-by: Zac Medico <zmedico@gentoo.org> lib/_emerge/PollScheduler.py | 9 ++++++++- lib/portage/dbapi/porttree.py | 2 +- lib/portage/tests/ebuild/test_doebuild_spawn.py | 3 ++- lib/portage/tests/ebuild/test_ipc_daemon.py | 3 ++- lib/portage/util/_async/SchedulerInterface.py | 9 ++++++++- 5 files changed, 21 insertions(+), 5 deletions(-) (In reply to Zac Medico from comment #3) > Also, it might be possible for the ForkProcess instance used by _start_proc > to trigger this (introduced in a69c1b853a47 for bug 916566), since > _start_proc only returns the associated MultiprocessingProcess instance, so > the ForkProcess instance can get garbage collected before its main coroutine > exits. Let's follow up on this issue in bug 925456 (I now have a patch to test in https://github.com/gentoo/portage/pull/1284). The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6ad9d3103abc02f60d9e123ae21fa4a2e69b7e38 commit 6ad9d3103abc02f60d9e123ae21fa4a2e69b7e38 Author: Sam James <sam@gentoo.org> AuthorDate: 2024-02-25 08:32:40 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-02-25 08:32:47 +0000 sys-apps/portage: add 3.0.63 Closes: https://bugs.gentoo.org/925214 Closes: https://bugs.gentoo.org/651018 Closes: https://bugs.gentoo.org/922935 Closes: https://bugs.gentoo.org/925240 Closes: https://bugs.gentoo.org/925311 Closes: https://bugs.gentoo.org/925333 Closes: https://bugs.gentoo.org/925350 Closes: https://bugs.gentoo.org/925456 Closes: https://bugs.gentoo.org/925460 Signed-off-by: Sam James <sam@gentoo.org> sys-apps/portage/Manifest | 1 + sys-apps/portage/portage-3.0.63.ebuild | 246 +++++++++++++++++++++++++++++++++ 2 files changed, 247 insertions(+) |