Блог

Недавно я выполнил различные обновления программного обеспечения, предложенные «Центром программного обеспечения» на моем компьютере Ubuntu ( Ubuntu 18.04.5 LTS ). Теперь, когда я пытаюсь импортировать numba ( numba==0.51.2 ) через

 python3 -c 'import numba'
 

Я получаю следующую ошибку

двойное освобождение или повреждение (вверху) прервано (сброс ядра)

То же самое происходит, когда я создаю новую среду conda с новой numba установкой.

Я просмотрел дамп ядра через

 gdb -c core
 

с

 thread apply all bt full
 

но я получаю только информацию об адресе памяти. Я использую python 3.6.9 на своей машине, но я также попробовал 3.8 в новой среде conda, где я получаю ту же ошибку.

Я подозреваю, что причиной ошибки, описанной выше, является обновление программного обеспечения. Но я могу ошибаться, и здесь происходит что-то еще.

Есть ли какой-либо другой способ получить дополнительную информацию о том, где происходит сбой python? Я действительно не хочу просматривать обновленные библиотеки одну за другой и откатывать их назад, чтобы найти ошибку.

По крайней мере, теперь я нашел библиотеку, которая вызывает эту ошибку. Что я сделал, так это следующие шаги:

1. поместить import numba в файл, например importNumba.py
2. найдите python3.X-gdb.py с помощью locate --regex python3.*-gdb.py . В моем случае это в /usr/share/gdb/auto-load/usr/bin/python3.6-gdb.py
3. запустите python в режиме отладки через gdb python3 — откроется консоль gdb
4. выполнить source /usr/share/gdb/auto-load/usr/bin/python3.6-gdb.py в консоли gdb — это загрузит расширения python в gdb
5. выполнить run importNumba.py в консоли gdb — это приведет к вышеуказанной ошибке
6. выполнить py-bt в консоли gdb

Это дает

 Traceback (most recent call first):
  File "/usr/local/lib/python3.6/dist-packages/llvmlite/binding/ffi.py", line 113, in __call__
    return self._cfn(*args, **kwargs)
  File "/usr/local/lib/python3.6/dist-packages/llvmlite/binding/dylib.py", line 29, in load_library_permanently
    _encode_string(filename), outerr):
  File "/usr/local/lib/python3.6/dist-packages/numba/__init__.py", line 151, in _try_enable_svml
    llvmlite.binding.load_library_permanently("libsvml.so")
  File "/usr/local/lib/python3.6/dist-packages/numba/__init__.py", line 201, in <module>
    config.USING_SVML = _try_enable_svml()
  <built-in method exec of module object at remote 0x7ffff7fb7638>
  File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed
  File "<frozen importlib._bootstrap_external>", line 678, in exec_module
  File "<frozen importlib._bootstrap>", line 665, in _load_unlocked
  File "<frozen importlib._bootstrap>", line 955, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 971, in _find_and_load
  File "importNumba.py", line 1, in <module>
    import numba
 

Так что, похоже, что-то не так libsvml.so .
Я обнаружил, что numba это позволяет отключить SVML
, установив для флага среды NUMBA_DISABLE_INTEL_SVML значение, отличное от 0, см. https://numba.pydata.org/numba-doc/dev/reference/envvars.html

Изменение importNumba.py на

 import os
# note that this must be executed before 'import numba'
os.environ['NUMBA_DISABLE_INTEL_SVML'] = '1'
import numba
 

и запуск его через python3 importNumba.py now работает без ошибок.

Вот несколько полезных ресурсов, которые я использовал: https://fedoraproject.org/wiki/Features/EasierPythonDebugging#New_gdb_commands
https://wiki .python.org/moin/DebuggingWithGdb