New user self-registration is disabled due to spam. For an account please email bugs-admin@lists.llvm.org with your e-mail address and full name.

Bug 43830 - lldb crashes when loading Python 3.6 interpreter
Summary: lldb crashes when loading Python 3.6 interpreter
Status: RESOLVED FIXED
Alias: None
Product: lldb
Classification: Unclassified
Component: All Bugs (show other bugs)
Version: 9.0
Hardware: PC Linux
: P enhancement
Assignee: Tom Stellard
URL:
Keywords:
Depends on:
Blocks: release-9.0.1
  Show dependency tree
 
Reported: 2019-10-28 09:42 PDT by sguelton
Modified: 2019-11-21 16:05 PST (History)
5 users (show)

See Also:
Fixed By Commit(s): 9357b5d df3ae1e 186c848 6d7bc60


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description sguelton 2019-10-28 09:42:32 PDT
Reproducer:

$ lldb -o script
(lldb) script
 #0 0x00007f89c6b890ee llvm::sys::PrintStackTrace(llvm::raw_ostream&) /home/sguelton/sources/llvm-project/llvm/lib/Support/Unix/Signals.inc:533:22
 #1 0x00007f89c6b89181 PrintStackTraceSignalHandler(void*) /home/sguelton/sources/llvm-project/llvm/lib/Support/Unix/Signals.inc:594:1
 #2 0x00007f89c6b87323 llvm::sys::RunSignalHandlers() /home/sguelton/sources/llvm-project/llvm/lib/Support/Signals.cpp:68:20
 #3 0x00007f89c6b88b6a SignalHandler(int) /home/sguelton/sources/llvm-project/llvm/lib/Support/Unix/Signals.inc:385:1
 #4 0x00007f89c65d3680 __restore_rt (/lib64/libpthread.so.0+0xf680)
 #5 0x00007f89c0fd5cf4 PyModule_GetState (/opt/rh/rh-python36/root/usr/lib64/libpython3.6m.so.rh-python36-1.0+0xe3cf4)
 #6 0x00007f89a36e0ed9 _init (/opt/rh/rh-python36/root/usr/lib64/python3.6/lib-dynload/readline.cpython-36m-x86_64-linux-gnu.so+0x3ed9)
 #7 0x00007f89b79acff5 rl_initialize (/lib64/libedit.so.0+0x20ff5)
 #8 0x00007f89a36e168f PyInit_readline (/opt/rh/rh-python36/root/usr/lib64/python3.6/lib-dynload/readline.cpython-36m-x86_64-linux-gnu.so+0x468f)
 #9 0x00007f89c10c842f _PyImport_LoadDynamicModuleWithSpec (/opt/rh/rh-python36/root/usr/lib64/libpython3.6m.so.rh-python36-1.0+0x1d642f)
#10 0x00007f89c10c7ca4 (/opt/rh/rh-python36/root/usr/lib64/libpython3.6m.so.rh-python36-1.0+0x1d5ca4)
#11 0x00007f89c0fd55f7 PyCFunction_Call (/opt/rh/rh-python36/root/usr/lib64/libpython3.6m.so.rh-python36-1.0+0xe35f7)
#12 0x00007f89c103c9b2 _PyEval_EvalFrameDefault (/opt/rh/rh-python36/root/usr/lib64/libpython3.6m.so.rh-python36-1.0+0x14a9b2)
#13 0x00007f89c1040c8c (/opt/rh/rh-python36/root/usr/lib64/libpython3.6m.so.rh-python36-1.0+0x14ec8c)
#14 0x00007f89c1041aba (/opt/rh/rh-python36/root/usr/lib64/libpython3.6m.so.rh-python36-1.0+0x14faba)
#15 0x00007f89c1041e23 (/opt/rh/rh-python36/root/usr/lib64/libpython3.6m.so.rh-python36-1.0+0x14fe23)
#16 0x00007f89c10362a7 _PyEval_EvalFrameDefault (/opt/rh/rh-python36/root/usr/lib64/libpython3.6m.so.rh-python36-1.0+0x1442a7)
#17 0x00007f89c1041a0a (/opt/rh/rh-python36/root/usr/lib64/libpython3.6m.so.rh-python36-1.0+0x14fa0a)
#18 0x00007f89c1041e23 (/opt/rh/rh-python36/root/usr/lib64/libpython3.6m.so.rh-python36-1.0+0x14fe23)
#19 0x00007f89c10362a7 _PyEval_EvalFrameDefault (/opt/rh/rh-python36/root/usr/lib64/libpython3.6m.so.rh-python36-1.0+0x1442a7)
#20 0x00007f89c1041a0a (/opt/rh/rh-python36/root/usr/lib64/libpython3.6m.so.rh-python36-1.0+0x14fa0a)
#21 0x00007f89c1041e23 (/opt/rh/rh-python36/root/usr/lib64/libpython3.6m.so.rh-python36-1.0+0x14fe23)
#22 0x00007f89c10362a7 _PyEval_EvalFrameDefault (/opt/rh/rh-python36/root/usr/lib64/libpython3.6m.so.rh-python36-1.0+0x1442a7)
#23 0x00007f89c1041a0a (/opt/rh/rh-python36/root/usr/lib64/libpython3.6m.so.rh-python36-1.0+0x14fa0a)
#24 0x00007f89c1041e23 (/opt/rh/rh-python36/root/usr/lib64/libpython3.6m.so.rh-python36-1.0+0x14fe23)
#25 0x00007f89c10362a7 _PyEval_EvalFrameDefault (/opt/rh/rh-python36/root/usr/lib64/libpython3.6m.so.rh-python36-1.0+0x1442a7)
#26 0x00007f89c1041a0a (/opt/rh/rh-python36/root/usr/lib64/libpython3.6m.so.rh-python36-1.0+0x14fa0a)
#27 0x00007f89c1041e23 (/opt/rh/rh-python36/root/usr/lib64/libpython3.6m.so.rh-python36-1.0+0x14fe23)
#28 0x00007f89c10362a7 _PyEval_EvalFrameDefault (/opt/rh/rh-python36/root/usr/lib64/libpython3.6m.so.rh-python36-1.0+0x1442a7)
#29 0x00007f89c1042f12 _PyFunction_FastCallDict (/opt/rh/rh-python36/root/usr/lib64/libpython3.6m.so.rh-python36-1.0+0x150f12)
#30 0x00007f89c0f980ce _PyObject_FastCallDict (/opt/rh/rh-python36/root/usr/lib64/libpython3.6m.so.rh-python36-1.0+0xa60ce)
#31 0x00007f89c0f993f4 _PyObject_CallMethodIdObjArgs (/opt/rh/rh-python36/root/usr/lib64/libpython3.6m.so.rh-python36-1.0+0xa73f4)
#32 0x00007f89c105a28f PyImport_ImportModuleLevelObject (/opt/rh/rh-python36/root/usr/lib64/libpython3.6m.so.rh-python36-1.0+0x16828f)
#33 0x00007f89c1039201 _PyEval_EvalFrameDefault (/opt/rh/rh-python36/root/usr/lib64/libpython3.6m.so.rh-python36-1.0+0x147201)
#34 0x00007f89c1042122 PyEval_EvalCodeEx (/opt/rh/rh-python36/root/usr/lib64/libpython3.6m.so.rh-python36-1.0+0x150122)
#35 0x00007f89c1042dbb PyEval_EvalCode (/opt/rh/rh-python36/root/usr/lib64/libpython3.6m.so.rh-python36-1.0+0x150dbb)
#36 0x00007f89c10352cb (/opt/rh/rh-python36/root/usr/lib64/libpython3.6m.so.rh-python36-1.0+0x1432cb)
#37 0x00007f89c0fd55f7 PyCFunction_Call (/opt/rh/rh-python36/root/usr/lib64/libpython3.6m.so.rh-python36-1.0+0xe35f7)
#38 0x00007f89c103c9b2 _PyEval_EvalFrameDefault (/opt/rh/rh-python36/root/usr/lib64/libpython3.6m.so.rh-python36-1.0+0x14a9b2)
#39 0x00007f89c1040c8c (/opt/rh/rh-python36/root/usr/lib64/libpython3.6m.so.rh-python36-1.0+0x14ec8c)
#40 0x00007f89c1041aba (/opt/rh/rh-python36/root/usr/lib64/libpython3.6m.so.rh-python36-1.0+0x14faba)
#41 0x00007f89c1041e23 (/opt/rh/rh-python36/root/usr/lib64/libpython3.6m.so.rh-python36-1.0+0x14fe23)
#42 0x00007f89c10362a7 _PyEval_EvalFrameDefault (/opt/rh/rh-python36/root/usr/lib64/libpython3.6m.so.rh-python36-1.0+0x1442a7)
#43 0x00007f89c1041a0a (/opt/rh/rh-python36/root/usr/lib64/libpython3.6m.so.rh-python36-1.0+0x14fa0a)
#44 0x00007f89c1041e23 (/opt/rh/rh-python36/root/usr/lib64/libpython3.6m.so.rh-python36-1.0+0x14fe23)
#45 0x00007f89c10362a7 _PyEval_EvalFrameDefault (/opt/rh/rh-python36/root/usr/lib64/libpython3.6m.so.rh-python36-1.0+0x1442a7)
#46 0x00007f89c1041a0a (/opt/rh/rh-python36/root/usr/lib64/libpython3.6m.so.rh-python36-1.0+0x14fa0a)
#47 0x00007f89c1041e23 (/opt/rh/rh-python36/root/usr/lib64/libpython3.6m.so.rh-python36-1.0+0x14fe23)
#48 0x00007f89c10362a7 _PyEval_EvalFrameDefault (/opt/rh/rh-python36/root/usr/lib64/libpython3.6m.so.rh-python36-1.0+0x1442a7)
#49 0x00007f89c1041a0a (/opt/rh/rh-python36/root/usr/lib64/libpython3.6m.so.rh-python36-1.0+0x14fa0a)
#50 0x00007f89c1041e23 (/opt/rh/rh-python36/root/usr/lib64/libpython3.6m.so.rh-python36-1.0+0x14fe23)
#51 0x00007f89c10362a7 _PyEval_EvalFrameDefault (/opt/rh/rh-python36/root/usr/lib64/libpython3.6m.so.rh-python36-1.0+0x1442a7)
#52 0x00007f89c1042f12 _PyFunction_FastCallDict (/opt/rh/rh-python36/root/usr/lib64/libpython3.6m.so.rh-python36-1.0+0x150f12)
#53 0x00007f89c0f980ce _PyObject_FastCallDict (/opt/rh/rh-python36/root/usr/lib64/libpython3.6m.so.rh-python36-1.0+0xa60ce)
#54 0x00007f89c0f993f4 _PyObject_CallMethodIdObjArgs (/opt/rh/rh-python36/root/usr/lib64/libpython3.6m.so.rh-python36-1.0+0xa73f4)
#55 0x00007f89c105a28f PyImport_ImportModuleLevelObject (/opt/rh/rh-python36/root/usr/lib64/libpython3.6m.so.rh-python36-1.0+0x16828f)
#56 0x00007f89c1039201 _PyEval_EvalFrameDefault (/opt/rh/rh-python36/root/usr/lib64/libpython3.6m.so.rh-python36-1.0+0x147201)
#57 0x00007f89c1042122 PyEval_EvalCodeEx (/opt/rh/rh-python36/root/usr/lib64/libpython3.6m.so.rh-python36-1.0+0x150122)
#58 0x00007f89c1042dbb PyEval_EvalCode (/opt/rh/rh-python36/root/usr/lib64/libpython3.6m.so.rh-python36-1.0+0x150dbb)
#59 0x00007f89c10cb97e (/opt/rh/rh-python36/root/usr/lib64/libpython3.6m.so.rh-python36-1.0+0x1d997e)
#60 0x00007f89c10cbff2 PyRun_StringFlags (/opt/rh/rh-python36/root/usr/lib64/libpython3.6m.so.rh-python36-1.0+0x1d9ff2)
#61 0x00007f89c0f7777e PyRun_SimpleStringFlags (/opt/rh/rh-python36/root/usr/lib64/libpython3.6m.so.rh-python36-1.0+0x8577e)
#62 0x00007f89c5581605 lldb_private::ScriptInterpreterPythonImpl::InitializePrivate() /home/sguelton/sources/llvm-project/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp:3201:24
#63 0x00007f89c55775f1 lldb_private::ScriptInterpreterPythonImpl::ScriptInterpreterPythonImpl(lldb_private::Debugger&) /home/sguelton/sources/llvm-project/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp:456:35
#64 0x00007f89c5584dec void __gnu_cxx::new_allocator<lldb_private::ScriptInterpreterPythonImpl>::construct<lldb_private::ScriptInterpreterPythonImpl, lldb_private::Debugger&>(lldb_private::ScriptInterpreterPythonImpl*, lldb_private::Debugger&) /opt/rh/devtoolset-8/root/usr/include/c++/8/ext/new_allocator.h:136:60
#65 0x00007f89c55849fa void std::allocator_traits<std::allocator<lldb_private::ScriptInterpreterPythonImpl> >::construct<lldb_private::ScriptInterpreterPythonImpl, lldb_private::Debugger&>(std::allocator<lldb_private::ScriptInterpreterPythonImpl>&, lldb_private::ScriptInterpreterPythonImpl*, lldb_private::Debugger&) /opt/rh/devtoolset-8/root/usr/include/c++/8/bits/alloc_traits.h:475:56
#66 0x00007f89c5584463 std::_Sp_counted_ptr_inplace<lldb_private::ScriptInterpreterPythonImpl, std::allocator<lldb_private::ScriptInterpreterPythonImpl>, (__gnu_cxx::_Lock_policy)2>::_Sp_counted_ptr_inplace<lldb_private::Debugger&>(std::allocator<lldb_private::ScriptInterpreterPythonImpl>, lldb_private::Debugger&) /opt/rh/devtoolset-8/root/usr/include/c++/8/bits/shared_ptr_base.h:545:2
#67 0x00007f89c5583c2a std::__shared_count<(__gnu_cxx::_Lock_policy)2>::__shared_count<lldb_private::ScriptInterpreterPythonImpl, std::allocator<lldb_private::ScriptInterpreterPythonImpl>, lldb_private::Debugger&>(std::_Sp_make_shared_tag, lldb_private::ScriptInterpreterPythonImpl*, std::allocator<lldb_private::ScriptInterpreterPythonImpl> const&, lldb_private::Debugger&) /opt/rh/devtoolset-8/root/usr/include/c++/8/bits/shared_ptr_base.h:656:4
#68 0x00007f89c5583684 std::__shared_ptr<lldb_private::ScriptInterpreterPythonImpl, (__gnu_cxx::_Lock_policy)2>::__shared_ptr<std::allocator<lldb_private::ScriptInterpreterPythonImpl>, lldb_private::Debugger&>(std::_Sp_make_shared_tag, std::allocator<lldb_private::ScriptInterpreterPythonImpl> const&, lldb_private::Debugger&) /opt/rh/devtoolset-8/root/usr/include/c++/8/bits/shared_ptr_base.h:1329:10
#69 0x00007f89c55831ff std::shared_ptr<lldb_private::ScriptInterpreterPythonImpl>::shared_ptr<std::allocator<lldb_private::ScriptInterpreterPythonImpl>, lldb_private::Debugger&>(std::_Sp_make_shared_tag, std::allocator<lldb_private::ScriptInterpreterPythonImpl> const&, lldb_private::Debugger&) /opt/rh/devtoolset-8/root/usr/include/c++/8/bits/shared_ptr.h:361:4
#70 0x00007f89c5582cf3 std::shared_ptr<lldb_private::ScriptInterpreterPythonImpl> std::allocate_shared<lldb_private::ScriptInterpreterPythonImpl, std::allocator<lldb_private::ScriptInterpreterPythonImpl>, lldb_private::Debugger&>(std::allocator<lldb_private::ScriptInterpreterPythonImpl> const&, lldb_private::Debugger&) /opt/rh/devtoolset-8/root/usr/include/c++/8/bits/shared_ptr.h:708:5
#71 0x00007f89c55826c8 std::shared_ptr<lldb_private::ScriptInterpreterPythonImpl> std::make_shared<lldb_private::ScriptInterpreterPythonImpl, lldb_private::Debugger&>(lldb_private::Debugger&) /opt/rh/devtoolset-8/root/usr/include/c++/8/bits/shared_ptr.h:723:42
#72 0x00007f89c5577fcf lldb_private::ScriptInterpreterPythonImpl::CreateInstance(lldb_private::Debugger&) /home/sguelton/sources/llvm-project/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp:609:64
#73 0x00007f89c4e2e147 lldb_private::PluginManager::GetScriptInterpreterForLanguage(lldb::ScriptLanguage, lldb_private::Debugger&) /home/sguelton/sources/llvm-project/lldb/source/Core/PluginManager.cpp:1544:43
#74 0x00007f89c4dc2721 lldb_private::Debugger::GetScriptInterpreter(bool) /home/sguelton/sources/llvm-project/lldb/source/Core/Debugger.cpp:1303:35
#75 0x00007f89c4f2b7bd lldb_private::CommandObjectScript::DoExecute(llvm::StringRef, lldb_private::CommandReturnObject&) /home/sguelton/sources/llvm-project/lldb/source/Interpreter/CommandObjectScript.cpp:53:77
#76 0x00007f89c4f2825a lldb_private::CommandObjectRaw::Execute(char const*, lldb_private::CommandReturnObject&) /home/sguelton/sources/llvm-project/lldb/source/Interpreter/CommandObject.cpp:994:26
#77 0x00007f89c4f14b4d lldb_private::CommandInterpreter::HandleCommand(char const*, lldb_private::LazyBool, lldb_private::CommandReturnObject&, lldb_private::ExecutionContext*, bool, bool) /home/sguelton/sources/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:1764:17
#78 0x00007f89c4f19055 lldb_private::CommandInterpreter::IOHandlerInputComplete(lldb_private::IOHandler&, std::string&) /home/sguelton/sources/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2828:16
#79 0x00007f89c4df6fdf lldb_private::IOHandlerEditline::Run() /home/sguelton/sources/llvm-project/lldb/source/Core/IOHandler.cpp:577:44
#80 0x00007f89c4dc12cb lldb_private::Debugger::ExecuteIOHandlers() /home/sguelton/sources/llvm-project/lldb/source/Core/Debugger.cpp:999:60
#81 0x00007f89c4f19d0e lldb_private::CommandInterpreter::RunCommandInterpreter(bool, bool, lldb_private::CommandInterpreterRunOptions&) /home/sguelton/sources/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:3041:5
#82 0x00007f89c492fd76 lldb::SBDebugger::RunCommandInterpreter(bool, bool, lldb::SBCommandInterpreterRunOptions&, int&, bool&, bool&) /home/sguelton/sources/llvm-project/lldb/source/API/SBDebugger.cpp:1125:37
#83 0x0000000000407a8b Driver::MainLoop() /home/sguelton/sources/llvm-project/lldb/tools/driver/Driver.cpp:620:39
#84 0x0000000000408759 main /home/sguelton/sources/llvm-project/lldb/tools/driver/Driver.cpp:889:34
#85 0x00007f89c3aef3d5 __libc_start_main (/lib64/libc.so.6+0x223d5)
#86 0x0000000000405829 _start (/home/sguelton/sources/llvm-project/_build-lldb/bin/lldb+0x405829)
Comment 1 Michał Górny 2019-10-28 10:04:42 PDT
I've seen a similar problem with 3.7 yesterday but attributed it to broken local build.  I think it used to work, so you may want to try bisecting it.
Comment 2 sguelton 2019-10-28 10:11:24 PDT
Educated guess based on first investigation: there might be a symbol confusion between libedit, as used by lldb, and read readline, as bundled in Python. Still investigating.
Comment 3 sguelton 2019-10-29 01:10:45 PDT
More info on that one:

lldb is linked against libedit, and libpython dynaically loads readline.cpython-36m-x86_64-linux-gnu.so which is itself linked against libreadline. Both library define `rl_initialize`, and in the lookup order, libedit comes before libreadline so when the readline python native extension initializes, it calls the libedit one, which wreaks havoc.

I managed to workaround that issue by injecting a fake readline module into the embeded Python interpreter before it loads

```
static PyObject* fakereadline() {
    PyErr_SetImportError(PyUnicode_FromString("readline"), nullptr, nullptr); 
    return nullptr;
}
(...)
PyImport_AppendInittab("readline", &fakereadline);
```

This basically defines a new readline module that superseds the default one, and raises an import error when it is imported, which seems ok from the lldb perspective. It could also return an empty module.

This is half hacky, half decent, any thoughts/alternatives?
Comment 4 labath 2019-10-29 01:58:32 PDT
That would mean we lose the interactive command line in the built-in python interpreter, right? That is something people do care about, as we've in the past had a fake "readline" module to make this work. However, it was removed in <https://reviews.llvm.org/D59972>, because we got the impression it is not needed anymore -- it seems we were wrong.

As an alternative, maybe we could avoid linking against libedit.so, and either:
a) link it statically (libedit.a). Then our linker version script should ensure that these symbols are not available to python. This would be my preferred solution, but I don't know if there are any environments which have libedit.so, but not .a. Potentionaly, we could just prefer linking to the .a file, and fall back to .so (maybe with a warning) if the .a is not available.

b) use dlopen(RTLD_LOCAL). This should achieve the same effect but still enable dynamic linking. I don't know if there is any ld(1) flag which would enable us to achieve the RTLD_LOCAL semantics without needing to dlopen/dlsym everything.
Comment 5 labath 2019-10-29 08:01:57 PDT
BTW, this is now failing for me too, but there have been a couple of changes since I last ran the test suite, so it's hard to pin down the exact problem. I'll try to do some bisection to figure that out...
Comment 6 sguelton 2019-10-29 08:21:55 PDT
Bug reported on cpython side: https://bugs.python.org/issue38634
And a cpython PR: https://github.com/python/cpython/pull/16986
Comment 7 labath 2019-10-29 10:47:25 PDT
Nice detective work. It sounds like the root cause is libedit incompatibility, but as python already has code to work around that, I'm hoping they won't have a problem with extending the workaround to other platforms. I'll also try to contact the libedit maintainer to see if this incompatibility can be fixed in libedit.

Unfortunately, I think we will still need somehow address this in lldb too, since it will take a while before the fixed python versions are readily available.

In other news, I've figured out why this has started "suddenly" failing for me -- reconfiguring the tree (which I've needed to done for the github switch) chose python3 by default, whereas I've previously had python 2.7 selected. Switching back to python2 makes the problem "disappear".
Comment 8 Jonas Devlieghere 2019-10-29 10:51:59 PDT
Should we just add the old workaround back? 

Pavel, when you say this repros with Python 3, is that 3.6 or 3.7?
Comment 9 labath 2019-10-29 11:12:01 PDT
(In reply to Jonas Devlieghere from comment #8)
> Should we just add the old workaround back? 

Yeah... maybe? Though that makes me sad as I found that workaround quite gross and was very happy to see it go... And I understand a lot of linux distros were not shipping it because installing it would mean it would override the readline module globally. mgorny may know more about that.

I think I'd prefer some combination of (a) and (b) from #4.

> 
> Pavel, when you say this repros with Python 3, is that 3.6 or 3.7?

This was with python 3.6, but judging by the nature Serge's fix, I'd expect that the same problem is manifested on a wide range of python versions (I have no idea why 2.7 is immune).
Comment 10 Michał Górny 2019-10-29 13:05:00 PDT
Honestly, the solution I'd really prefer to see is ability to build CPython with libedit instead of readline.  But that's some tedious work, and I suspect it will take real effort to convince Python upstream to accept it.
Comment 11 sguelton 2019-10-30 03:11:36 PDT
> But that's some tedious work, and I suspect it will take real effort to convince Python upstream to accept it.

I'm more optimist than this :-) Hoewer it may not be backported so we still need to have an option.

I've been inspecting https://reviews.llvm.org/D59972 and it turns out we can easily build the module and only load it inside the Python interpreter embeded into lldb, hotpatching the host readline. This would prevent the existing issue without any impact on the system.

I'll propose a review going that way.
Comment 12 labath 2019-10-30 03:20:09 PDT
(In reply to Michał Górny from comment #10)
> Honestly, the solution I'd really prefer to see is ability to build CPython
> with libedit instead of readline.  But that's some tedious work, and I
> suspect it will take real effort to convince Python upstream to accept it.

Judging by the last comment on <https://github.com/python/cpython/pull/16986>, it looks like they would be open to that. However, won't that just reverse the problem? I.e., if you have a libedit version of python but embed it into a readline application (gdb?), won't you still get a crash ?

What would be the ideal solution IMO would be some version of RTLD_DEEPBIND dlopen flag, but which works for static dynamic linking (whatever you want to call it -- DT_NEEDED). That way, python would always get the library it was linked against, instead of some random library in the same process...
Comment 13 sguelton 2019-11-02 14:43:53 PDT
This is a work in progress but it solves the issue on my config, while not polluting the python global namespace.

https://sergesanspaille.fedorapeople.org/0001-Revert-Python-Remove-readline-module-patches.patch

I think I can make it cleaner though :-)
Comment 14 sguelton 2019-11-04 02:37:57 PST
Should be fixed by https://reviews.llvm.org/D69793
Comment 16 labath 2019-11-13 04:48:26 PST
(In reply to Tom Stellard from comment #15)
> Pavel,
> 
> Are these OK to merge to 9.0.1:
> 
> https://reviews.llvm.org/rGdf3ae1eb296d5193232649b5f282dfc4f01ba61f
> https://reviews.llvm.org/rG9357b5d08497326a1895cab6c1d712bf12a34519

The change is slightly risky, but it has been sitting in the tree for over a week, so it hopefully won't break in a spectacular way. Also, the problem it is fixing is pretty important too.

I'm not sure what's our bar for 9.0.1 at this point, but I would be inclined to cherry-pick it.
Comment 17 sguelton 2019-11-21 14:34:05 PST
Cherry-picked and commited in release/9.x as :

186c848d84f1a4e7cd5b217ff3ae26083e2fdedf
6d7bc6033d7d3e452eeb181156e6c1bc2b14b897