Summary: | app-portage/porthole with python3 - File "/usr/lib/portage/pym/portage/__init__.py", line 224, in __call__ rval = self._func(*wrapped_args, **wrapped_kwargs) OSError: [Errno 9] Bad file descriptor | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Kete Tefid <ketetefid> |
Component: | Third-Party Tools | Assignee: | Brian Dolbec <dolsen> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | pinkbyte, tools-portage |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Kete Tefid
2012-12-31 21:20:05 UTC
It looks like the traceback shows 2 threads entering portdbapi.aux_get() at the same time, which is unsafe. You'll need to wrap that call with a threading lock. yeah, the description reader was running in a thread, updating the description db and there was a pkg display call in the main thread. After all these years, this is the first collision of that sort. At least reported. I've never run into that myself, and I've been doing pkg display changes while the description reader has been running. As for the python3 issue, porthole is not yet capable of running in python3, that is why it runs in python2 only. It will need a lot of updating to be python3 capable. I also need to work on the gtk migration to the introspection python interface. The easiest workaround is to start porthole and leave it be for awhile, so it can update it's description db and save it. (In reply to comment #2) > The easiest workaround is to start porthole and leave it be for awhile, so > it can update it's description db and save it. Alternately, run `emerge --regen` before running porthole. That way, portdbapi.aux_get() won't enter the thread-sensitive areas of portdbapi.aux_get() while porthole is running. That won't work reliably since porthole can be running, and call emerge --sync, then it will automatically reload the description db. It has been my intention to move all portage/pkgcore activity to a single thread/process (for the data gathering instance, user privileges). There will be another instance running with root privileges for merging and other operations. In that way, I'd be able to enable the sqlite backend, since it does not work threaded. Just too many other projects/distractions/real life this past couple years. This portage patch should suppress the problem by using a separate EventLoop instance for each thread: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=400a2a983b374ec54e7b574789d1f94752581b81 Thanks to everybody. Is there any hope to get it working soon? Will the patch go to main portage? yes, it is available now for testing in portage-9999. It will also be in the next 2.2 alpha release. and will eventually make it's way into portage-2.1 once it's proven to be working correctly and not causing other problems. (In reply to comment #5) > This portage patch should suppress the problem by using a separate EventLoop > instance for each thread: > > http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit; > h=400a2a983b374ec54e7b574789d1f94752581b81 This is in sys-apps/portage-2.1.11.50 which is stable now: https://bugs.gentoo.org/show_bug.cgi?id=455930 So, is it fixed for now? Can we close this? closing as it has been in stable releases for some time now. |