Summary: | dev-python/zstandard-0.22.0 prefers cffi import policy and that crash app-misc/anki-bin-24.04.1-r1 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | pva <peter.volkov> |
Component: | Current packages | Assignee: | Python Gentoo Team <python> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | mgorny, peter.volkov |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
pva
2024-07-02 10:56:10 UTC
Can you make an independent reproducer? Presumably it happens when calling zstandard from pure Python, correct? I've tried, but unfortunately, I failed to find a way to call ZSTD_decompress() in a way it is done from anki bin. Note, that this function is called from /usr/lib64/libQt6Core.so.6, #3 0x00007ffff32f1af2 in QResourcePrivate::decompress(char*, long long) const () at /usr/lib64/libQt6Core.so.6 Note, there is no zstd_decompress function in exported in dev-python/zstandard. So, to reproduce this issue I need somehow to: 1. build binary that will calls ZSTD_decompress() (that's easy, zstd has examples) 2. to link this binary somehow with cffi. And here I don't understand how to do that... BTW, I found that if I build mesa with "zstd" backtrace will be different: 0x00007ffff41606c0 in ZSTD_freeDDict () from /usr/lib/python3.10/site-packages/zstandard/_cffi.cpython-310-x86_64-linux-gnu.so (gdb) bt #0 0x00007ffff41606c0 in ZSTD_freeDDict () at /usr/lib/python3.10/site-packages/zstandard/_cffi.cpython-310-x86_64-linux-gnu.so #1 0x00007ffff4166bbb in ZSTD_decompressDCtx () at /usr/lib/python3.10/site-packages/zstandard/_cffi.cpython-310-x86_64-linux-gnu.so #2 0x00007ffff404513b in ZSTD_decompress () at /usr/lib64/libzstd.so.1 #3 0x00007fffdda83f2f in util_compress_inflate () at /usr/lib64/dri/iris_dri.so #4 0x00007fffdda5ce71 in parse_and_validate_cache_item () at /usr/lib64/dri/iris_dri.so #5 0x00007fffdda5d5de in disk_cache_load_item () at /usr/lib64/dri/iris_dri.so #6 0x00007fffdda5c6ae in disk_cache_get () at /usr/lib64/dri/iris_dri.so #7 0x00007fffde1838cb in iris_disk_cache_retrieve () at /usr/lib64/dri/iris_dri.so #8 0x00007fffde18ebf4 in iris_create_shader_state () at /usr/lib64/dri/iris_dri.so #9 0x00007fffddb089be in st_create_fp_variant () at /usr/lib64/dri/iris_dri.so #10 0x00007fffddb090a6 in st_get_fp_variant () at /usr/lib64/dri/iris_dri.so #11 0x00007fffddb0959b in st_finalize_program () at /usr/lib64/dri/iris_dri.so #12 0x00007fffddb09772 in st_program_string_notify () at /usr/lib64/dri/iris_dri.so #13 0x00007fffddc871bc in _mesa_get_fixed_func_fragment_program () at /usr/lib64/dri/iris_dri.so #14 0x00007fffddaa1938 in update_program () at /usr/lib64/dri/iris_dri.so #15 0x00007fffddaa1f50 in _mesa_update_state_locked () at /usr/lib64/dri/iris_dri.so #16 0x00007fffddaa21b5 in _mesa_update_state () at /usr/lib64/dri/iris_dri.so #17 0x00007fffddce1eec in find_value () at /usr/lib64/dri/iris_dri.so #18 0x00007fffddce3665 in _mesa_GetBooleanv () at /usr/lib64/dri/iris_dri.so #19 0x00007ffff0255d10 in qt_gl_resolve_extensions() () at /usr/lib64/libQt6Gui.so.6 #20 0x00007ffff0256739 in QOpenGLExtensions::hasOpenGLExtension(QOpenGLExtensions::OpenGLExtension) const () at /usr/lib64/libQt6Gui.so.6 #21 0x00007ffff026b45e in QRhiGles2::create(QFlags<QRhi::Flag>) () at /usr/lib64/libQt6Gui.so.6 #22 0x00007ffff01144b7 in QRhi::create(QRhi::Implementation, QRhiInitParams*, QFlags<QRhi::Flag>, QRhiNativeHandles*) () at /usr/lib64/libQt6Gui.so.6 #23 0x00007fffe3c1ebf0 in QtWebEngineCore::GPUInfo::GPUInfo() () at /usr/lib64/libQt6WebEngineCore.so.6 #24 0x00007fffffffa710 in ??? () #25 0xffffffffffffff88 in ??? () #26 0x0000000000000002 in ??? () #27 0x0000555555e93f40 in ??? () #28 0x00005555568190a0 in ??? () #29 0x0000000000000000 in ??? () Here ZSTD_decompress() is called from some function in /usr/lib64/dri/iris_dri.so. But still crash is the same. Ah, so the problem is that dev-python/zstandard exports symbols colliding with symbols from libzstd itself? As far as I understand yes. zstandard exports symbols from zstd using CFFI, and somehow it exports them with higher priority. Thus, we have two ZSTD_decompressDCtx() functions - from CFFI and zstd library. Now, instead of calling ZSTD_decompressDCtx() function from zstd, ZSTD_decompress()-call inside zstd library calls ZSTD_decompressDCtx() from CFFI and crashs there. |