search

Quuxplusone / LLVMBugzillaTest

0 stars 0 forks source link

lldb crashes when loading Python 3.6 interpreter #42800

Closed Quuxplusone closed 4 years ago

Quuxplusone commented 4 years ago
Bugzilla Link PR43830
Status RESOLVED FIXED
Importance P enhancement
Reported by sguelton@redhat.com
Reported on 2019-10-28 09:42:32 -0700
Last modified on 2019-11-21 16:05:56 -0800
Version 9.0
Hardware PC Linux
CC jdevlieghere@apple.com, labath@google.com, llvm-bugs@lists.llvm.org, mgorny@gentoo.org, tstellar@redhat.com
Fixed by commit(s) rG9357b5d, rGdf3ae1e, rG186c848, rG6d7bc60
Attachments
Blocks PR43360
Blocked by
See also 
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)
Quuxplusone commented 4 years ago

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.

Quuxplusone commented 4 years ago

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.

Quuxplusone commented 4 years ago

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?

Quuxplusone commented 4 years ago 
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.
Quuxplusone commented 4 years ago

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...

Quuxplusone commented 4 years ago 
Bug reported on cpython side: https://bugs.python.org/issue38634
And a cpython PR: https://github.com/python/cpython/pull/16986
Quuxplusone commented 4 years ago

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".

Quuxplusone commented 4 years ago

Should we just add the old workaround back?

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

Quuxplusone commented 4 years ago 
(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).
Quuxplusone commented 4 years ago

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.

Quuxplusone commented 4 years ago

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.

Quuxplusone commented 4 years ago 
(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...
Quuxplusone commented 4 years ago

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 :-)

Quuxplusone commented 4 years ago

Should be fixed by https://reviews.llvm.org/D69793

Quuxplusone commented 4 years ago 
Pavel,

Are these OK to merge to 9.0.1:

https://reviews.llvm.org/rGdf3ae1eb296d5193232649b5f282dfc4f01ba61f
https://reviews.llvm.org/rG9357b5d08497326a1895cab6c1d712bf12a34519
Quuxplusone commented 4 years ago 
(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.
Quuxplusone commented 4 years ago 
Cherry-picked and commited in release/9.x as :

186c848d84f1a4e7cd5b217ff3ae26083e2fdedf
6d7bc6033d7d3e452eeb181156e6c1bc2b14b897