Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 617550 - sys-apps/portage: Ctrl+C hangs emerge (just before pkg_setup)
Summary: sys-apps/portage: Ctrl+C hangs emerge (just before pkg_setup)
Status: RESOLVED FIXED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core - Interface (emerge) (show other bugs)
Hardware: All All
: Normal normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords: InVCS
Depends on:
Blocks: 184128 619102
  Show dependency tree
 
Reported: 2017-05-05 04:19 UTC by Zac Medico
Modified: 2017-08-11 19:43 UTC (History)
1 user (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Zac Medico gentoo-dev 2017-05-05 04:19:04 UTC
When the Scheduler._terminate_tasks method clears self._task_queues, it prevents exit listeners from being called for an EbuildExecuter instance that has previously called self.scheduler.scheduleSetup(setup_phase). This causes the parent MergeListItem to remain in Scheduler._running_tasks indefinitely, and the event loop just hangs forever in the self._thread_condition.wait(wait_timeout) call. The backtrace of this state is as follows:

(Pdb) bt
  /usr/lib/python-exec/python3.4/emerge(50)<module>()
-> retval = emerge_main()
  /usr/lib64/python3.4/site-packages/_emerge/main.py(1229)emerge_main()
-> return run_action(emerge_config)
  /usr/lib64/python3.4/site-packages/_emerge/actions.py(3266)run_action()
-> retval = action_build(emerge_config, spinner=spinner)
  /usr/lib64/python3.4/site-packages/_emerge/actions.py(525)action_build()
-> retval = mergetask.merge()
  /usr/lib64/python3.4/site-packages/_emerge/Scheduler.py(1042)merge()
-> rval = self._merge()
  /usr/lib64/python3.4/site-packages/_emerge/Scheduler.py(1444)_merge()
-> self._main_loop()
> /usr/lib64/python3.4/site-packages/_emerge/Scheduler.py(1421)_main_loop()
-> self._event_loop.iteration()
  /usr/lib64/python3.4/site-packages/portage/util/_eventloop/EventLoop.py(222)iteration()
-> self._thread_condition.wait(wait_timeout)

The Scheduler._running_tasks state looks like this:

(Pdb) p next(iter(self._running_tasks.values()))
<_emerge.MergeListItem.MergeListItem object at 0x7f67b275f900>
(Pdb) p next(iter(self._running_tasks.values()))._current_task
<_emerge.EbuildBuild.EbuildBuild object at 0x7f67b275f9f8>
(Pdb) p next(iter(self._running_tasks.values()))._current_task._current_task
<_emerge.EbuildExecuter.EbuildExecuter object at 0x7f67acf129d8>
(Pdb) p next(iter(self._running_tasks.values()))._current_task._current_task._exit_listeners
[<bound method EbuildBuild._build_exit of <_emerge.EbuildBuild.EbuildBuild object at 0x7f67b275f9f8>>]
(Pdb) p next(iter(self._running_tasks.values()))._current_task._current_task.returncode
1
Comment 1 Zac Medico gentoo-dev 2017-05-05 04:59:07 UTC
(In reply to Zac Medico from comment #0)
> (Pdb) p
> next(iter(self._running_tasks.values()))._current_task._current_task.
> _exit_listeners
> [<bound method EbuildBuild._build_exit of <_emerge.EbuildBuild.EbuildBuild
> object at 0x7f67b275f9f8>>]
> (Pdb) p
> next(iter(self._running_tasks.values()))._current_task._current_task.
> returncode
> 1

The 1 returncode suggests that there may have been an _async_wait callback registered when it went into the endless sleep.
Comment 2 Zac Medico gentoo-dev 2017-05-05 09:27:51 UTC
I've posted a patch to fix Eventloop handling of idle_add/call_soon callbacks:

https://archives.gentoo.org/gentoo-portage-dev/message/ba1ec7812ec5a839896cc1a880b7f3f4
https://github.com/gentoo/portage/pull/160

That seems to be the only problem, since the code from bug 425554 should handle the interaction between Scheduler._terminate_tasks and _schedule_setup, as long as task.cancel() works appropriately (the EventLoop patch should fix that).
Comment 4 Zac Medico gentoo-dev 2017-08-11 19:43:21 UTC
Fixed in 2.3.6.