Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 925456 - sys-apps/portage-3.0.62: strange warning with bash completion: [ERROR] Task was destroyed but it is pending!
Summary: sys-apps/portage-3.0.62: strange warning with bash completion: [ERROR] Task w...
Status: RESOLVED FIXED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core (show other bugs)
Hardware: AMD64 Linux
: Normal normal
Assignee: Portage team
URL:
Whiteboard:
Keywords: InVCS, PullRequest
Depends on: 925214
Blocks:
  Show dependency tree
 
Reported: 2024-02-25 03:22 UTC by nurali
Modified: 2024-02-26 21:49 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
emerge --info output (info.txt,18.53 KB, text/plain)
2024-02-25 03:22 UTC, nurali
Details

Note You need to log in before you can comment on or make changes to this bug.
Description nurali 2024-02-25 03:22:40 UTC
Created attachment 885915 [details]
emerge --info output

When I was trying to emerge a set(@world,@system,etc.),after I entered part of the set's name like @sys and hit Tab to complete it by bash-comletion,this came up:

sudo emerge @sy[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()]>
stem

I downgraded portage and everything is normal.I post a topic on Gentoo forums and Sam told me to file a bug here.

emerge --info also makes this happen
Comment 1 Zac Medico gentoo-dev 2024-02-25 04:30:43 UTC
Like I was saying over in bug 925333 comment 3, it might be possible for the ForkProcess instance used by _start_proc to trigger this, since _start_proc only returns the associated MultiprocessingProcess instance, so the ForkProcess instance can get garbage collected before its main coroutine exits. It was introduced in this commit related to bug 916566:

https://gitweb.gentoo.org/proj/portage.git/commit/?id=a69c1b853a47346192950c91b088163490287350

We may be able to optimize away the bits that are getting garbage collected here. For example, in this commit related to bug 923750 there's a os.devnull file descriptor opened just to satisfy the expectations of the mostly unused main coroutine:

https://gitweb.gentoo.org/proj/portage.git/commit/?id=e8b31c86eaed645a8740fb2844e2935aee161e43

The main coroutine can be used for a short time to send fd_pipes for the multiprocessing spawn start method (bug 915896).
Comment 2 Zac Medico gentoo-dev 2024-02-25 04:42:12 UTC
(In reply to nurali from comment #0)
> sudo emerge @sy[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()]>
> stem

The ForkProcess.py line 200 referenced here is where it has finished sending fd_pipes for the purposes of bug 915896, and all that remains for the coroutine to do is read a os.devnull file descriptor to EOF.

The simplest fix would be to have MultiprocessingProcess hold a reference to the ForkProcess instance in order to prevent it from being garbage collected.
Comment 3 Zac Medico gentoo-dev 2024-02-25 05:46:06 UTC
It's possible that the garbage collection protection which I've added in   https://github.com/gentoo/portage/pull/1284 will not be enough to prevent some of these messages. If that's the case, then I'll need to add a special wait method that also waits for the ForkProcess instance, but maybe it's not really needed.
Comment 4 Zac Medico gentoo-dev 2024-02-25 06:08:58 UTC
I went ahead and added the special wait method to https://github.com/gentoo/portage/pull/1284 in order to handle the edge cases.
Comment 5 nurali 2024-02-25 06:16:07 UTC
(In reply to Zac Medico from comment #3)
> It's possible that the garbage collection protection which I've added in  
> https://github.com/gentoo/portage/pull/1284 will not be enough to prevent
> some of these messages. If that's the case, then I'll need to add a special
> wait method that also waits for the ForkProcess instance, but maybe it's not
> really needed.

Thank you for what you're doing
Comment 6 Larry the Git Cow gentoo-dev 2024-02-25 08:25:11 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/proj/portage.git/commit/?id=92615cd37d7a1efce923c474e455f59fe61a589c

commit 92615cd37d7a1efce923c474e455f59fe61a589c
Author:     Zac Medico <zmedico@gentoo.org>
AuthorDate: 2024-02-25 05:09:48 +0000
Commit:     Sam James <sam@gentoo.org>
CommitDate: 2024-02-25 08:24:59 +0000

    _start_proc: Prevent premature ForkProcess garbage collection
    
    In order to prevent the constructed ForkProcess instance from
    being prematurely garbage collected, return a reference to the
    caller inside of a _GCProtector object, preventing messages
    reported in bug 925456 like this:
    
        [ERROR] Task was destroyed but it is pending!
    
    Fixes: a69c1b853a47 ("process.spawn: Use multiprocessing.Process for returnproc")
    Bug: https://bugs.gentoo.org/925456
    Signed-off-by: Zac Medico <zmedico@gentoo.org>
    Closes: https://github.com/gentoo/portage/pull/1284
    Signed-off-by: Sam James <sam@gentoo.org>

 lib/portage/process.py | 41 +++++++++++++++++++++++++++++++++++++++--
 1 file changed, 39 insertions(+), 2 deletions(-)
Comment 7 Larry the Git Cow gentoo-dev 2024-02-25 08:33:02 UTC
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(+)
Comment 8 Larry the Git Cow gentoo-dev 2024-02-26 21:49:15 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/proj/portage.git/commit/?id=0ff7a3b28e0ec63d68d32e01145db8962d53774d

commit 0ff7a3b28e0ec63d68d32e01145db8962d53774d
Author:     Zac Medico <zmedico@gentoo.org>
AuthorDate: 2024-02-26 05:09:21 +0000
Commit:     Zac Medico <zmedico@gentoo.org>
CommitDate: 2024-02-26 05:09:21 +0000

    SpawnProcess: Wait for async set_term_size
    
    Use the SpawnProcess _unregister method to handle async
    set_term_size results, avoiding possible messages like
    bug 925456 triggered:
    
        [ERROR] Task was destroyed but it is pending!
    
    Also update _BinpkgFetcherProcess and _EbuildFetcherProcess
    which inherit the _pty_ready attribute from SpawnProcess.
    
    Fixes: f97e414ce980 ("set_term_size: Wait asynchronously if event loop is running")
    Bug: https://bugs.gentoo.org/923750
    Bug: https://bugs.gentoo.org/925456
    Signed-off-by: Zac Medico <zmedico@gentoo.org>

 lib/_emerge/BinpkgFetcher.py |  6 ++++--
 lib/_emerge/EbuildFetcher.py |  6 ++++--
 lib/_emerge/SpawnProcess.py  | 14 +++++++++++++-
 lib/portage/output.py        | 13 +++++++++----
 lib/portage/util/_pty.py     | 23 ++++++++++++++++-------
 5 files changed, 46 insertions(+), 16 deletions(-)