distribution
distribution copied to clipboard
clearlinux
python: Illegal instruction
python is terminating immediately on startup with SIGILL:
$ python
Illegal instruction (core dumped)
I tried to debug with gdb but this also has the same problem!
$ gdb python
Illegal instruction (core dumped)
My CPU info:
vendor_id : GenuineIntel
cpu family : 6
model : 77
model name : Intel(R) Atom(TM) CPU C2750 @ 2.40GHz
stepping : 8
microcode : 0x12d
cpuid level : 11
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 movbe popcnt tsc_deadline_timer aes rdrand lahf_lm 3dnowprefetch cpuid_fault epb pti ibrs ibpb stibp tpr_shadow flexpriority ept vpid tsc_adjust smep erms dtherm ida arat vnmi md_clear
I also tried lldb and it crashes when trying to initialize a Python interpreter (I had no idea it had Python embedded in to it)
lldb
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0. Program arguments: lldb
#0 0x0000558944f297d8 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/usr/bin/../lib64/libLLVM-17.so+0xa757d8)
#1 0x0000558944f27b80 llvm::sys::RunSignalHandlers() (/usr/bin/../lib64/libLLVM-17.so+0xa73b80)
#2 0x0000558944f29d28 (/usr/bin/../lib64/libLLVM-17.so+0xa75d28)
#3 0x0000558943e43670 __restore_rt libc_sigaction.c:0:0
#4 0x00005589437039aa PyImport_AppendInittab /builddir/build/BUILD/Python-3.12.2/Python/import.c:1496:21
#5 0x000055894bd87138 (anonymous namespace)::InitializePythonRAII::InitializePythonRAII() /builddir/build/BUILD/llvm-project-17.0.6.src/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp:114:5
#6 0x000055894bd87138 lldb_private::ScriptInterpreterPythonImpl::Initialize() /builddir/build/BUILD/llvm-project-17.0.6.src/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp:3085:24
#7 0x0000558943e9c137 __pthread_once_slow /builddir/build/BUILD/glibc-2.39/nptl/pthread_once.c:118:7
#8 0x000055894bd7694c void std::call_once<lldb_private::ScriptInterpreterPython::Initialize()::$_0>(std::once_flag&, lldb_private::ScriptInterpreterPython::Initialize()::$_0&&) /usr/lib64/gcc/x86_64-generic-linux/14/../../../../include/c++/14/mutex:916:15
#9 0x000055894bd7694c void llvm::call_once<lldb_private::ScriptInterpreterPython::Initialize()::$_0>(std::once_flag&, lldb_private::ScriptInterpreterPython::Initialize()::$_0&&) /builddir/build/BUILD/llvm-project-17.0.6.src/llvm/include/llvm/Support/Threading.h:89:5
#10 0x000055894bd7694c lldb_private::ScriptInterpreterPython::Initialize() /builddir/build/BUILD/llvm-project-17.0.6.src/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp:333:3
#11 0x000055894bd7694c lldb_private::lldb_initialize_ScriptInterpreterPython() /builddir/build/BUILD/llvm-project-17.0.6.src/lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp:62:1
#12 0x000055894b7d5ed7 lldb_private::SystemInitializerFull::Initialize() /builddir/build/BUILD/llvm-project-17.0.6.src/llvm/clr-build/tools/lldb/source/Plugins/Plugins.def:102:1
#13 0x000055894b99a4f1 llvm::Error::operator bool() /builddir/build/BUILD/llvm-project-17.0.6.src/llvm/include/llvm/Support/Error.h:234:21
#14 0x000055894b99a4f1 lldb_private::SystemLifetimeManager::Initialize(std::unique_ptr<lldb_private::SystemInitializer, std::default_delete<lldb_private::SystemInitializer>>, llvm::sys::DynamicLibrary (*)(std::shared_ptr<lldb_private::Debugger> const&, lldb_private::FileSpec const&, lldb_private::Status&)) /builddir/build/BUILD/llvm-project-17.0.6.src/lldb/source/Initialization/SystemLifetimeManager.cpp:36:14
#15 0x000055894b6ffae6 std::unique_ptr<lldb_private::SystemInitializer, std::default_delete<lldb_private::SystemInitializer>>::~unique_ptr() /usr/lib64/gcc/x86_64-generic-linux/14/../../../../include/c++/14/bits/unique_ptr.h:397:6
#16 0x000055894b6ffae6 lldb::SBDebugger::InitializeWithErrorHandling() /builddir/build/BUILD/llvm-project-17.0.6.src/lldb/source/API/SBDebugger.cpp:218:16
#17 0x000055894c420118 main /builddir/build/BUILD/llvm-project-17.0.6.src/lldb/tools/driver/Driver.cpp:789:13
#18 0x0000558943e29b47 __libc_start_call_main /builddir/build/BUILD/glibc-2.39/csu/../sysdeps/nptl/libc_start_call_main.h:74:3
#19 0x0000558943e29bfb call_init /builddir/build/BUILD/glibc-2.39/csu/../csu/libc-start.c:128:20
#20 0x0000558943e29bfb __libc_start_main@GLIBC_2.2.5 /builddir/build/BUILD/glibc-2.39/csu/../csu/libc-start.c:347:5
#21 0x000055894c41c8e1 _start /builddir/build/BUILD/glibc-2.39/csu/../sysdeps/x86_64/start.S:117:0
fish: Job 1, 'lldb' terminated by signal SIGILL (Illegal instruction)
I found a static build of an old version of GDB (7.10.1) to find where it was crashing in Python.
Program received signal SIGILL, Illegal instruction.
0x00005555550c27ab in get_allocator_unlocked () from /usr/lib64/libpython3.12.so.1.0
(gdb) bt
#0 0x00005555550c27ab in get_allocator_unlocked () from /usr/lib64/libpython3.12.so.1.0
#1 0x00005555550c1921 in set_default_allocator_unlocked () from /usr/lib64/libpython3.12.so.1.0
#2 0x00005555550c235a in _PyRuntimeState_Init.localalias () from /usr/lib64/libpython3.12.so.1.0
#3 0x00005555550c182b in _PyRuntime_Initialize.localalias () from /usr/lib64/libpython3.12.so.1.0
#4 0x00005555550c26f3 in pymain_init () from /usr/lib64/libpython3.12.so.1.0
#5 0x00005555550c18d7 in pymain_main () from /usr/lib64/libpython3.12.so.1.0
#6 0x00005555550c16a8 in Py_BytesMain () from /usr/lib64/libpython3.12.so.1.0
#7 0x0000555554a29b47 in __libc_start_call_main () from /usr/lib64/libc.so.6
#8 0x0000555554a29bfb in __libc_start_main_impl () from /usr/lib64/libc.so.6
#9 0x0000555555555081 in _start ()
(gdb) disassemble
Dump of assembler code for function get_allocator_unlocked:
0x00005555550c27a0 <+0>: test %edi,%edi
0x00005555550c27a2 <+2>: jne 0x5555550c27c3 <get_allocator_unlocked+35>
0x00005555550c27a4 <+4>: mov 0x27257d(%rip),%rax # 0x555555334d28
=> 0x00005555550c27ab <+11>: vmovdqu 0x60(%rax),%ymm1
0x00005555550c27b0 <+16>: vmovdqu %ymm1,(%rsi)
0x00005555550c27b4 <+20>: mov 0x80(%rax),%rax
0x00005555550c27bb <+27>: mov %rax,0x20(%rsi)
0x00005555550c27bf <+31>: vzeroupper
0x00005555550c27c2 <+34>: retq
0x00005555550c27c3 <+35>: cmp $0x1,%edi
0x00005555550c27c6 <+38>: je 0x5555550c27ed <get_allocator_unlocked+77>
0x00005555550c27c8 <+40>: cmp $0x2,%edi
0x00005555550c27cb <+43>: jne 0x5555550c280d <get_allocator_unlocked+109>
0x00005555550c27cd <+45>: mov 0x272554(%rip),%rax # 0x555555334d28
0x00005555550c27d4 <+52>: vmovdqu 0xb0(%rax),%ymm2
0x00005555550c27dc <+60>: vmovdqu %ymm2,(%rsi)
0x00005555550c27e0 <+64>: mov 0xd0(%rax),%rax
0x00005555550c27e7 <+71>: mov %rax,0x20(%rsi)
0x00005555550c27eb <+75>: jmp 0x5555550c27bf <get_allocator_unlocked+31>
0x00005555550c27ed <+77>: mov 0x272534(%rip),%rax # 0x555555334d28
0x00005555550c27f4 <+84>: vmovdqu 0x88(%rax),%ymm3
0x00005555550c27fc <+92>: vmovdqu %ymm3,(%rsi)
0x00005555550c2800 <+96>: mov 0xa8(%rax),%rax
0x00005555550c2807 <+103>: mov %rax,0x20(%rsi)
0x00005555550c280b <+107>: jmp 0x5555550c27bf <get_allocator_unlocked+31>
0x00005555550c280d <+109>: jmpq 0x555554f04719 <get_allocator_unlocked.cold>
End of assembler dump.
The offending instruction is vmovdqu which is an AVX instruction. As far as I know my CPU does not have AVX support.
I think I'm having a similar issue with gdb, and it's giving me trouble with my C++ development in VSCode. Every time I run gdb I have the illegal instruction error message... I don't know if I should open a new issue?
Also I'm running an Intel Celeron N2808 CPU, this wasn't an issue in the past...
Python issue should be fixed in the next release.
Will this also apply to gdb? I had a similar problem at #3055, the OP also seems to have problems with gdb, or should this be treated in another issue?
Will this also apply to gdb? I had a similar problem at #3055, the OP also seems to have problems with gdb, or should this be treated in another issue?
Given gdb links to python, I'd expect it to be the same problem.