Summary: | sys-apps/portage-2.1.10.46: TypeError: an integer is required | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Martin Mokrejš <mmokrejs> |
Component: | Core | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED FIXED | ||
Severity: | normal | Keywords: | InVCS |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 614112 | ||
Bug Blocks: | 651804 |
Description
Martin Mokrejš
2012-02-14 20:54:10 UTC
Ehm, do not know when this happened but my external USB drive with USB-stick modem connected to same USB hub crashed in the kernel. Maybe this is a false alarm. Will re-install PyQt4 after I repair the filesystem. So, I have successfully re-emerged =dev-python/PyQt4-4.9.1. Don't know what that really means. ;-) I suspect that python's os.fork() returns a non-integer sometimes. I've added some code to check for this case: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=11937db0fb2e25a30d855b084417f8d52547ff54 http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=174da53469886a2d42e55326377d59e453b696c2 (In reply to comment #3) > I suspect that python's os.fork() returns a non-integer sometimes. I've added > some code to check for this case: > > http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=11937db0fb2e25a30d855b084417f8d52547ff54 > http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=174da53469886a2d42e55326377d59e453b696c2 This debugging code is included in 2.1.10.47 and 2.2.0_alpha87. Then, the assert triggered, this is what I got today:
>>> Running pre-merge checks for www-client/chromium-44.0.2403.89
Traceback (most recent call last):
File "/usr/lib/python-exec/python2.7/emerge", line 50, in <module>
retval = emerge_main()
File "/usr/lib64/python2.7/site-packages/_emerge/main.py", line 1154, in emerge_main
return run_action(emerge_config)
File "/usr/lib64/python2.7/site-packages/_emerge/actions.py", line 3191, in run_action
emerge_config.args, spinner)
File "/usr/lib64/python2.7/site-packages/_emerge/actions.py", line 498, in action_build
retval = mergetask.merge()
File "/usr/lib64/python2.7/site-packages/_emerge/Scheduler.py", line 1005, in merge
rval = self._run_pkg_pretend()
File "/usr/lib64/python2.7/site-packages/_emerge/Scheduler.py", line 926, in _run_pkg_pretend
current_task.wait()
File "/usr/lib64/python2.7/site-packages/_emerge/AsynchronousTask.py", line 54, in wait
self._wait()
File "/usr/lib64/python2.7/site-packages/_emerge/CompositeTask.py", line 85, in _wait
task.wait()
File "/usr/lib64/python2.7/site-packages/_emerge/AsynchronousTask.py", line 54, in wait
self._wait()
File "/usr/lib64/python2.7/site-packages/_emerge/SubProcess.py", line 98, in _wait
(self.__class__.__name__, repr(self.pid)))
AssertionError: EbuildProcess: pid is non-integer: None
I have re-merged python (while investigating this), but it happened the next time I have tried again.
I have just upgraded GCC before this happened, from 4.7.3 to 4.8.5
(In reply to Petr Nejedly from comment #5) > File "/usr/lib64/python2.7/site-packages/_emerge/SubProcess.py", line 98, > in _wait > (self.__class__.__name__, repr(self.pid))) > AssertionError: EbuildProcess: pid is non-integer: None This proves that the problem is not os.fork(), since otherwise a different assertion following fork would have been triggered. I don't know where the None value comes from. I've reviewed the code, and I don't see how it's possible to trigger this case. > I have re-merged python (while investigating this), but it happened the next > time I have tried again. > > I have just upgraded GCC before this happened, from 4.7.3 to 4.8.5 So, can you reproduce it reliably? I have now hit the same problem with pid is non-integer: None This was while building inside a chroot (with GRS) and lots of custom overlays, so I am not going to post details here until I find exactly what's causing this. This issue is triggered by event loop recursion in the AbstractEbuildProcess._start() method, which leads to the SpawnProcess._wait() method being called before self.pid has been initialized. The patch for bug 614112 that fixes event loop recursion in AbstractEbuildProcess._start() will handle this. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/portage.git/commit/?id=3e235049eb36dd983b695ed50aca4e32d7d28950 commit 3e235049eb36dd983b695ed50aca4e32d7d28950 Author: Zac Medico <zmedico@gentoo.org> AuthorDate: 2018-04-29 00:48:41 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2018-04-29 00:48:41 +0000 AbstractEbuildProcess: use _async_waitpid after kill (bug 403697) Use _async_waitpid() instead of _async_wait() in the _cancel_timeout_cb method, since the pid exit status may not be available yet. Bug: https://bugs.gentoo.org/403697 pym/_emerge/AbstractEbuildProcess.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)} (In reply to Larry the Git Cow from comment #9) > The bug has been referenced in the following commit(s): > > https://gitweb.gentoo.org/proj/portage.git/commit/ > ?id=3e235049eb36dd983b695ed50aca4e32d7d28950 > > commit 3e235049eb36dd983b695ed50aca4e32d7d28950 > Author: Zac Medico <zmedico@gentoo.org> > AuthorDate: 2018-04-29 00:48:41 +0000 > Commit: Zac Medico <zmedico@gentoo.org> > CommitDate: 2018-04-29 00:48:41 +0000 > > AbstractEbuildProcess: use _async_waitpid after kill (bug 403697) Actually the above commit is not relevant to this bug. The patch for bug 614112 is the one that's relevant: https://gitweb.gentoo.org/proj/portage.git/commit/?id=30c69adfc0ffa450ff3a4d4d176023db66171ae7 Fixed in portage-2.3.40-r1. |