Created attachment 1271758 [details] Full backtrace with debuginfo installed On a number of different F25 machines, all with python3-3.5.3-4.fc25.x86_64, I found that running pydoc3 -k with any argument will segfault. Coredumpctl says: PID: 476632 (pydoc3) UID: 7225 (tibbs) GID: 7225 (tibbs) Signal: 11 (SEGV) Timestamp: Fri 2017-04-14 15:07:09 CDT (11min ago) Command Line: /usr/bin/python3.5 /usr/bin/pydoc3 -k posix Executable: /usr/bin/python3.5 Control Group: /user.slice/user-7225.slice/session-15915.scope Unit: session-15915.scope Slice: user-7225.slice Session: 15915 Owner UID: 7225 (tibbs) Boot ID: 7b65d3d664ec4f9fa3ac44c28b4c55f1 Machine ID: 66adb4e0cc334c5f882963d6b0077b93 Hostname: epithumia.math.uh.edu Coredump: /var/lib/systemd/coredump/core.pydoc3.7225.7b65d3d664ec4f9fa3ac44c28b4c55f1.476632.1492200429000000000000.lz4 Message: Process 476632 (pydoc3) of user 7225 dumped core. Stack trace of thread 476632: #0 0x00007fefec3187ab PyInit__libpycomps (_libpycomps.so) #1 0x00007ff00608e5f0 _PyImport_LoadDynamicModuleWithSpec (libpython3.5m.so.1.0) #2 0x00007ff00608c7c3 _imp_create_dynamic (libpython3.5m.so.1.0) #3 0x00007ff005fffee9 PyCFunction_Call (libpython3.5m.so.1.0) #4 0x00007ff006077739 PyEval_EvalFrameEx (libpython3.5m.so.1.0) #5 0x00007ff0060799b3 _PyEval_EvalCodeWithName (libpython3.5m.so.1.0) #6 0x00007ff0060760d9 PyEval_EvalFrameEx (libpython3.5m.so.1.0) #7 0x00007ff006077dc4 PyEval_EvalFrameEx (libpython3.5m.so.1.0) #8 0x00007ff006077dc4 PyEval_EvalFrameEx (libpython3.5m.so.1.0) #9 0x00007ff006077dc4 PyEval_EvalFrameEx (libpython3.5m.so.1.0) #10 0x00007ff006077dc4 PyEval_EvalFrameEx (libpython3.5m.so.1.0) #11 0x00007ff0060799b3 _PyEval_EvalCodeWithName (libpython3.5m.so.1.0) #12 0x00007ff006079a93 PyEval_EvalCodeEx (libpython3.5m.so.1.0) #13 0x00007ff005fe3278 function_call (libpython3.5m.so.1.0) #14 0x00007ff005fb8167 PyObject_Call (libpython3.5m.so.1.0) #15 0x00007ff005fb8c04 _PyObject_CallMethodIdObjArgs (libpython3.5m.so.1.0) #16 0x00007ff00608da47 PyImport_ImportModuleLevelObject (libpython3.5m.so.1.0) #17 0x00007ff00606c0c8 builtin___import__ (libpython3.5m.so.1.0) #18 0x00007ff005ffff09 PyCFunction_Call (libpython3.5m.so.1.0) #19 0x00007ff005fb8167 PyObject_Call (libpython3.5m.so.1.0) #20 0x00007ff00606fe87 PyEval_CallObjectWithKeywords (libpython3.5m.so.1.0) #21 0x00007ff006071c87 PyEval_EvalFrameEx (libpython3.5m.so.1.0) #22 0x00007ff0060799b3 _PyEval_EvalCodeWithName (libpython3.5m.so.1.0) #23 0x00007ff006079a93 PyEval_EvalCodeEx (libpython3.5m.so.1.0) #24 0x00007ff006079abb PyEval_EvalCode (libpython3.5m.so.1.0) #25 0x00007ff00606d83d builtin_exec (libpython3.5m.so.1.0) #26 0x00007ff005fffee9 PyCFunction_Call (libpython3.5m.so.1.0) #27 0x00007ff006077739 PyEval_EvalFrameEx (libpython3.5m.so.1.0) #28 0x00007ff0060799b3 _PyEval_EvalCodeWithName (libpython3.5m.so.1.0) #29 0x00007ff0060760d9 PyEval_EvalFrameEx (libpython3.5m.so.1.0) #30 0x00007ff006077dc4 PyEval_EvalFrameEx (libpython3.5m.so.1.0) #31 0x00007ff006077dc4 PyEval_EvalFrameEx (libpython3.5m.so.1.0) #32 0x00007ff006077dc4 PyEval_EvalFrameEx (libpython3.5m.so.1.0) #33 0x00007ff0060799b3 _PyEval_EvalCodeWithName (libpython3.5m.so.1.0) #34 0x00007ff006079a93 PyEval_EvalCodeEx (libpython3.5m.so.1.0) #35 0x00007ff005fe3278 function_call (libpython3.5m.so.1.0) #36 0x00007ff005fb8167 PyObject_Call (libpython3.5m.so.1.0) #37 0x00007ff005fb8c04 _PyObject_CallMethodIdObjArgs (libpython3.5m.so.1.0) #38 0x00007ff00608da47 PyImport_ImportModuleLevelObject (libpython3.5m.so.1.0) #39 0x00007ff00606c0c8 builtin___import__ (libpython3.5m.so.1.0) #40 0x00007ff005ffff09 PyCFunction_Call (libpython3.5m.so.1.0) #41 0x00007ff006077e50 PyEval_EvalFrameEx (libpython3.5m.so.1.0) #42 0x00007ff005fdc0a0 gen_send_ex (libpython3.5m.so.1.0) #43 0x00007ff006072102 PyEval_EvalFrameEx (libpython3.5m.so.1.0) #44 0x00007ff0060799b3 _PyEval_EvalCodeWithName (libpython3.5m.so.1.0) #45 0x00007ff0060760d9 PyEval_EvalFrameEx (libpython3.5m.so.1.0) #46 0x00007ff006077dc4 PyEval_EvalFrameEx (libpython3.5m.so.1.0) #47 0x00007ff006077dc4 PyEval_EvalFrameEx (libpython3.5m.so.1.0) #48 0x00007ff0060799b3 _PyEval_EvalCodeWithName (libpython3.5m.so.1.0) #49 0x00007ff006079a93 PyEval_EvalCodeEx (libpython3.5m.so.1.0) #50 0x00007ff006079abb PyEval_EvalCode (libpython3.5m.so.1.0) #51 0x00007ff006098d44 run_mod (libpython3.5m.so.1.0) #52 0x00007ff00609b295 PyRun_FileExFlags (libpython3.5m.so.1.0) #53 0x00007ff00609b404 PyRun_SimpleFileExFlags (libpython3.5m.so.1.0) #54 0x00007ff0060b206c Py_Main (libpython3.5m.so.1.0) #55 0x0000558156de2b60 main (python3.5) #56 0x00007ff00527e401 __libc_start_main (libc.so.6) #57 0x0000558156de2c0a _start (python3.5) However, when I install a few thousand debuginfo packages and wait while GDB chews 100% CPU for several minutes, I can get a rather huge backtrace that has 86 frames, which I will attach. I note that Rawhide does not have this problem (python3-3.6.1-2.fc27.x86_64). Nor does F24 (with python3-3.5.3-4.fc24.x86_64). But, weirdly, I spun up an old F23 VM and it does have the problem (python3-3.4.3-12.fc23.x86_64). I don't have any easy to test F26 right now.
It occurs to me that the old F23 VM and the F25 machines I'm testing have a lot of things installed, while the F24 and rawhide VMs I tried have fairly minimal installations. And indeed, when I use a minimal F25 VM, it's OK: vs00:~❯ pydoc3 -k posix _locale - Support for POSIX locales. posix - This module provides access to operating system functionality that is crypt - Wrapper to the POSIX crypt library call and associated functionality. multiprocessing.popen_spawn_posix os - OS routines for NT or Posix depending on what system we're on. posixpath - Common operations on Posix pathnames. _posixsubprocess vs00:~❯ rpm -q python3 python3-3.5.3-4.fc25.x86_64 ἐπιθυμία:~❯ pydoc3 -k posix _locale - Support for POSIX locales. posix - This module provides access to operating system functionality that is crypt - Wrapper to the POSIX crypt library call and associated functionality. multiprocessing.popen_spawn_posix os - OS routines for NT or Posix depending on what system we're on. posixpath - Common operations on Posix pathnames. _posixsubprocess [1] 484231 segmentation fault (core dumped) pydoc3 -k posix ἐπιθυμία:~❯ rpm -q python3 python3-3.5.3-4.fc25.x86_64 I went one by one through all of the packages and found that the culprit is python3-pykde4-4.14.3-13.fc25.x86_64. If you move /usr/lib64/python3.5/site-packages/PyKDE4/__init__.py out of the way, the crash stops immediately. But that file contains only the following: import sys,DLFCN # This is needed to ensure that dynamic_cast and RTTI works inside kdelibs. sys.setdlopenflags(DLFCN.RTLD_NOW|DLFCN.RTLD_GLOBAL) I'm kind of out of ideas, because that file alone won't cause the crash.
Interestingly, if you comment out the last line of that file (sys.setdlopenflags...) the crash won't occur.
I've tracked down the issue: 1. Pydoc run with the -k flag starts loading all available modules and extensions (pydoc.py -> ModuleScanner.run() ) and 2. when gets to the `/usr/lib64/python3.5/site-packages/PyKDE4/__init__.py` file the line `sys.setdlopenflags(DLFCN.RTLD_NOW|DLFCN.RTLD_GLOBAL)` sets the dlopenflags to a new value (previously set to os.RTLD_NOW [at least on my machine]) 3. which then crashes loading of some other extension module down the line that's not prepared for those flags. I'm reassigning the bug to
I'm reassigning the bug to the pykde4 component that contains the python3-pykde4 rpm. Since the PyKDE4 module is operating as a library, it cannot permanently set dlopenflags. Pydoc cannot be guarded against any and all environment changes that could be introduced by loading libraries and thus we need to make sure the libraries comply with the limitations.
I've reported the issue upstream as well: https://bugs.kde.org/show_bug.cgi?id=378927
Thanks for looking at this. It makes sense now that you've explained it but it's still pretty bizarre.
No problem! Indeed pydoc would merit a rewrite in such a way that it doesn't load all the modules like this, but it'll be a while till someone gets to that.
Just wanted to confirm that this is still an issue. I wonder if there's a relatively simple patch for pykde4 which would get around this. Unfortunately even importing DLFCN doesn't work in python 3.6 (unless you run h2py to create the module yourself) so... I don't know.
(In reply to Jason Tibbitts from comment #8) > Just wanted to confirm that this is still an issue. > > I wonder if there's a relatively simple patch for pykde4 which would get > around this. Unfortunately even importing DLFCN doesn't work in python 3.6 > (unless you run h2py to create the module yourself) so... I don't know. It might be possible to save the output of `sys.getdlopenflags()` at the start of the `/usr/lib64/python3.5/site-packages/PyKDE4/__init__.py` scrpit and then use `sys.setdlopenflags` to set the value back at the end of the __init__.py file. I have not tested this, however.
This message is a reminder that Fedora 25 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '25'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 25 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Still valid.
it's fixed in pykde4-4.14.3-21.fc28
pykde4-4.14.3-21.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-7ff28c3a4c
pykde4-4.14.3-21.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-7ff28c3a4c
This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle. Changing version to '28'.
pykde4-4.14.3-21.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.