Created attachment 17648 [details] скрипт запуска для успешной отладки после запуска `gbd` перед командой `start` надо выполнить ``` set env LD_PRELOAD <повторить $LD_PRELOAD> set env LD_LIBRARY_PATH <повторить $LD_LIBRARY_PATH> set libthread-db-search-path /tmp ``` (переменные окружения "LD_*" сбрасываются gdb при старте) у меня падает при любом запросе к любой таблице любой БД, прилагаю скорректированный скрипт запуска (там выводится подсказка) и стек при получении SIGSEGV
Created attachment 17649 [details] стек
Created attachment 17650 [details] вот это работает (через epm repack)
пробными инсталляциями разных версий дистрибутивов через epm repack выявил рабочий вариант (fedora, см. вложение) ``` epm install --repack ./mysql-workbench-community-8.0.38-1.fc39.x86_64.rpm ``` с этой версией ошибок нет
Попробуйте apt-repo test 373005 Убрал лишнее, выставил rpath и, главное, поднял версию libantlr4.
Воспроизвёл в Sisyphus.
> apt-repo test 373005 не помогло, так же валится
Воспроизводится на mysql-workbench-community-8.0.47-alt5 (Sisyphus, задание https://packages.altlinux.org/tasks/432481/, 2026-09-10). Стенд: клон шаблона poligon sisyphus-workstation-11.2, `apt-get dist-upgrade` до Sisyphus от 2026-09-15, перезагрузка; x86_64, GNOME 50 / Wayland (Workbench сам выставляет GDK_BACKEND=x11, работает через XWayland), mariadb-server-12.3.3-alt1, БД test с таблицей test_table. Шаги: открыть подключение Local instance 3306, в SQL-редакторе набрать `SELECT * FROM test.test_table;` и выполнить (Ctrl+Enter). Фактический результат: окно Workbench исчезает, в журнале: kernel: GRTDispatcher[5435]: segfault at 7fc1664ce000 ip 00007fc1664ce000 ... in libsqlparser.so.8.0.47 audit: ANOM_ABEND ... comm="GRTDispatcher" exe="/usr/bin/mysql-workbench-bin" sig=11 Падает выполнение любого запроса к любой таблице, как и у репортёра. Остальное при этом работает: сохранение скриптов, схемы, административные разделы — SIGSEGV только на выполнении SQL. Заодно, раз уж про этот же пакет: Scripting Shell при закрытии выводит ModuleNotFoundError: No module named 'imp' — /usr/share/mysql-workbench/libraries/grt_python_debugger.py:29 делает `import imp`, а в python3 3.14 модуль imp удалён (выкинут в 3.12); замена — importlib.
(Ответ для Anton Farygin на комментарий #7) > Воспроизводится на mysql-workbench-community-8.0.47-alt5 (Sisyphus, задание > https://packages.altlinux.org/tasks/432481/, 2026-09-10). > > Стенд: клон шаблона poligon sisyphus-workstation-11.2, `apt-get > dist-upgrade` до Sisyphus от > 2026-09-15, перезагрузка; x86_64, GNOME 50 / Wayland (Workbench сам > выставляет GDK_BACKEND=x11, > работает через XWayland), mariadb-server-12.3.3-alt1, БД test с таблицей > test_table. > > Шаги: открыть подключение Local instance 3306, в SQL-редакторе набрать > `SELECT * FROM test.test_table;` и выполнить (Ctrl+Enter). А если отключить автодополнение? (Поскольку парсер ломается при анализе синтаксиса в редакторе, отключение фоновой обработки текста полностью решает проблему: 1. Запустите MySQL Workbench (не заходя в подключение, чтобы программа не успела упасть). 2. Откройте верхнее меню: Edit -> Preferences (Правка -> Настройки). 3. В левой колонке выберите Query Editor (Редактор запросов). 4. В блоке справа найдите раздел Code Completion и снимите галочку с пункта Enable Code Completion (Включить автодополнение кода). 5. Нажмите OK, перезапустите Workbench и попробуйте выполнить запрос снова. )
Проверил на mysql-workbench-community-8.0.47-alt5 (Sisyphus от 2026-09-17, x86_64, mariadb-server-12.3.3-alt1). Отключение автодополнения не помогает. Контроль, настройки по умолчанию: SELECT * FROM test.test_table; + Ctrl+Enter → kernel: GRTDispatcher[8257]: segfault at 7f3b97259000 ip 00007f3b97259000 error 15 in libsqlparser.so.8.0.47[0,7f3b97259000+2e000] audit[7403]: ANOM_ABEND comm="GRTDispatcher" exe="/usr/bin/mysql-workbench-bin" sig=11 Дальше по вашим шагам: Edit → Preferences → SQL Editor → Query Editor, снята галка «Enable Code Completion in Editors». В ~/.mysql/workbench/wb_options.xml после штатного выхода из программы: <value type="int" key="DbSqlEditor:CodeCompletionEnabled">0</value> <value type="int" key="DbSqlEditor:AutoStartCodeCompletion">0</value> <value type="int" key="DbSqlEditor:CodeCompletionUpperCaseKeywords">0</value> (второй ключ выставил в 0 отдельно — в интерфейсе он просто становится неактивным; заодно это показывает, что весь блок Code Completion выключен). Перезапустил Workbench, тот же запрос, Ctrl+Enter: kernel: GRTDispatcher[8536]: segfault at 7fe0721cf000 ip 00007fe0721cf000 error 15 in libsqlparser.so.8.0.47[0,7fe0721cf000+2e000] Падение то же самое. Заодно уточнил границы: - набор текста запроса без выполнения программу не роняет (подсветка синтаксиса отрабатывает, процесс жив) — и с включённым автодополнением тоже; - SELECT 1; без обращения к таблицам падает так же; - тот же запрос через консольный mariadb к тому же серверу отрабатывает нормально. Стек (gdb, подключение к работающему процессу; debuginfo для пакета в репозитории нет): Thread 10 "GRTDispatcher" received signal SIGSEGV #0 0x00007fd7e0a69000 in ?? () #1 0x00007fd7e0aac1a8 in ?? () from libsqlparser.so.8.0.47 #2 mysql_parser::myx_process_sql_statements(char const*, mysql_parser::charset_info_st*, int (*)(mysql_parser::MyxStatementParser const*, char const*, void*), void*, int) #3 Mysql_sql_script_splitter::process(...) [db.mysql.sqlparser.grt.so] #4 MysqlSqlFacadeImpl::splitSqlScript(...) [db.mysql.sqlparser.grt.so] #5 SqlEditorForm::do_exec_sql(...) [libwbprivate.so.8.0.47] #6 bec::GRTTask::execute() / bec::GRTDispatcher::worker_thread(void*) То есть ломается не фоновый разбор текста в редакторе, а разбиение скрипта на запросы прямо на пути выполнения (do_exec_sql → splitSqlScript → myx_process_sql_statements), и настройками редактора этот путь не отключается. Ещё одна деталь: PC (0x7fd7e0a69000) в точности равен базе отображения libsqlparser.so.8.0.47, а error 15 — это выборка инструкции с нарушением защиты. Управление уходит по указателю со значением base+0, то есть вызывается функция по указателю, в котором лежит нулевое смещение (неинициализированный указатель либо неприменённая релокация). Смещение вызывающего кадра в разных прогонах одно и то же — libsqlparser+0x431a8. Библиотека собрана статически (из зависимостей только libstdc++/libgcc/libc), так что разбираться, видимо, придётся в сборке парсера; для этого очень пригодился бы debuginfo-пакет.
Сначала поправка: в прошлом сообщении я написал, что debuginfo для пакета в репозитории нет. Это неверно, пакет есть — mysql-workbench-community-debuginfo-8.0.47-alt5, просто отладочные пакеты лежат в отдельном компоненте репозитория: rpm http://ftp.altlinux.org/pub/distributions/ALTLinux Sisyphus/x86_64 debuginfo Прошу прощения. С ним снял нормальный символьный бэктрейс (Сизиф от 2026-09-17, x86_64, mysql-workbench-community-8.0.47-alt5, gdb 17.2, запуск через WB_DEBUG). Thread 15 "GRTDispatcher" received signal SIGSEGV, Segmentation fault. #0 0x00007fffaa4b0000 in ?? () #1 0x00007fffaa4f31a8 in memcpy (...) at /usr/include/bits/string_fortified.h:29 #2 std::char_traits<char>::copy (...) at /usr/include/c++/15/bits/char_traits.h:429 #3 std::__cxx11::basic_string<...>::_S_copy (...) at .../basic_string.h:453 #5 std::__cxx11::basic_string<...>::_S_copy_chars<char const*> (...) at .../basic_string.h:489 #6 std::__cxx11::basic_string<...>::_M_construct<char const*> ( __beg=0x7fff84001810 "SELECT * FROM test.test_table") at .../basic_string.tcc:253 __dnew = 29 #7 std::__cxx11::basic_string<...>::basic_string (__s=0x7fff84001810 "SELECT * FROM test.test_table") #8 mysql_parser::myx_process_sql_statements (sql=0x7fff84001810 "SELECT * FROM test.test_table", ...) at library/sql.parser/source/myx_statement_parser.cpp:457 #9 Mysql_sql_script_splitter::process (...) at modules/db.mysql.sqlparser/src/mysql_sql_script_splitter.cpp:45 #10 MysqlSqlFacadeImpl::splitSqlScript (...) at modules/db.mysql.sqlparser/src/mysql_sql_facade.cpp:53 #11 SqlEditorForm::do_exec_sql (...) at backend/wbprivate/sqlide/wb_sql_editor_form.cpp:2024 #24 bec::GRTTask::execute (...) at backend/wbpublic/grt/grt_dispatcher.cpp:239 #26 bec::GRTDispatcher::worker_thread (...) at backend/wbpublic/grt/grt_dispatcher.cpp:498 Падает на строке 457 myx_statement_parser.cpp — std::istringstream tmp(sql, ...), то есть на обычном копировании текста запроса в std::string. Регистры это подтверждают: rdi — свежий буфер, rsi — текст запроса, rdx = 0x1d = 29 = длина строки. si_code = 2 (SEGV_ACCERR), si_addr = 0x7fffaa4b0000 — это в точности база отображения libsqlparser.so.8.0.47. Причина видна в дизассемблере. Переход идёт НЕ по указателю (не call *reg и не call *(%rip)), а прямым call rel32 на адрес 0: 431a0: 4c 89 c6 mov %r8,%rsi 431a3: e8 58 ce fb ff call 0 <-- сюда, rel32 = -0x431a8 431a8: 48 8b 4c 24 10 mov 0x10(%rsp),%rcx Это вызов memcpy. И такой вызов не один: $ objdump -d /usr/lib64/mysql-workbench/libsqlparser.so.8.0.47 | grep -cE '\s(call|jmp)\s+0 <' 65 # 64 call + 1 jmp $ readelf -sW --dyn-syms /usr/lib64/mysql-workbench/libsqlparser.so.8.0.47 | grep -Ei ' memcpy| memset| memmove' 79: 0000000000000000 0 FUNC GLOBAL DEFAULT UND __memcpy_chk@GLIBC_2.3.4 Обычных memcpy/memset/memmove в .dynsym нет вообще, при том что strlen, strcmp, strdup, memcmp и т.д. импортируются нормально, а в соседней библиотеке того же пакета (db.mysql.sqlparser.grt.so) есть штатный "UND memcpy@GLIBC_2.14". Остальные 64 перехода сидят в my_strnxfrm_*, my_like_range_*, my_vsnprintf, memdup_root, my_fill_8bit, get_hash_symbol — то есть ровно там, где компилятор порождает блочные пересылки. Гипотезу про неприменённую релокацию проверил — она не подтверждается: TEXTREL и BIND_NOW нет, и в .text вообще нет ни одной релокации, для прямого call rel32 она и не нужна. Неверный адрес зашит в машинный код на этапе линковки библиотеки, динамическому компоновщику исправлять нечего. Поэтому падение детерминированное и настройками редактора не обходится. Дефект не только в Сизифе: в p11 (8.0.47-alt2) в той же библиотеке 63 таких вызова и тоже нет memcpy в .dynsym. Проверил и свежую сборку 8.0.47-alt6 из задания 433338 (взял пакет прямо из http://git.altlinux.org/tasks/archive/done/_423/433338/build/100/x86_64/rpms/): дефект на месте, objdump -d libsqlparser.so.8.0.47 | grep -cE '\s(call|jmp)\s+0 <' -> 65 readelf --dyn-syms -> только __memcpy_chk и байты по тому же смещению 431a3 те же самые. Это ожидаемо: в alt6 менялись зависимость на evince, ярлык и патчи, а сборка sqlparser не трогалась. Почему так слинковалось — по бинарнику не восстановил. Библиотека собрана с LTO (символы с суффиксом .lto_priv), но LTO есть и у соседних библиотек пакета, где всё в порядке, так что одним LTO это не объясняется; минимальные примеры (-flto, -fvisibility=hidden, version-script, --gc-sections, -Bsymbolic) на текущем gcc 15 такого кода не дают. Видимо, надо смотреть реальную строку линковки цели sqlparser (CMakeFiles/sqlparser.dir/link.txt) при сборке. Проверить результат будущей пересборки можно одной командой, без запуска GUI: objdump -d /usr/lib64/mysql-workbench/libsqlparser.so.8.0.47 | grep -cE '\s(call|jmp)\s+0 <' Сейчас 65, должно быть 0.
Поковырял лог сборки из задания — извините, что не догадался посмотреть туда сразу, это было очевидное место. Причина нашлась, и она не в коде парсера, а в флагах сборки: виноват LTO. В задании 433338 (8.0.47-alt6) cmake вызывается так: -DCMAKE_C_FLAGS:STRING=-pipe -frecord-gcc-switches -Wall -g -O2 -flto=auto -std=c++17 ... -DCMAKE_CXX_FLAGS:STRING=-pipe -frecord-gcc-switches -Wall -g -O2 -flto=auto -std=c++17 ... `-flto=auto` приходит из общих флагов сборки, в спеке пакета его нет (grep по гиру: единственное упоминание flto — чужой makefile в ext/scintilla/win32). Сравнил три сборки одного и того же пакета: сборка LTO call/jmp на 0 memcpy/memset/memmove в .dynsym p10 8.0.25-alt2, задание 277474 нет 0 есть (3 символа) p11 8.0.47-alt2, задание 416369 есть 63 нет sis 8.0.47-alt6, задание 433338 есть 65 нет Проверял так (пакеты брал прямо из заданий и из p10): $ objdump -d ./usr/lib64/mysql-workbench/libsqlparser.so.8.0.25 | grep -cE '\s(call|jmp)\s+0 <' 0 $ readelf --dyn-syms -W ./usr/lib64/mysql-workbench/libsqlparser.so.8.0.25 | grep -cE ' memcpy| memset| memmove' 3 $ objdump -d ./usr/lib64/mysql-workbench/libsqlparser.so.8.0.47 | grep -cE '\s(call|jmp)\s+0 <' # alt6 65 Логи заданий: в 277474 в CMAKE_C_FLAGS ровно `-pipe -frecord-gcc-switches -Wall -g -O2`, без LTO; в 416369 и 433338 — с `-flto=auto`. То есть пока LTO не было, библиотека линковалась нормально, с LTO сломалась в обеих ветках одинаково. Механизм укладывается в известную проблему LTO: обращения к memcpy/memset компилятор порождает на этапе кодогенерации, уже после того как плагин компоновщика разрешил символы, поэтому ссылка не попадает ни в .dynsym, ни в PLT, и прямой call rel32 остаётся с нулевой целью. Именно поэтому пострадала libsqlparser (сишный код кодировок MySQL: my_strnxfrm_*, my_vsnprintf, memdup_root, my_fill_8bit), а соседняя db.mysql.sqlparser.grt.so, где нет таких блочных пересылок, собралась штатно и имеет нормальный UND memcpy@GLIBC_2.14. Предлагаемое лечение: отключить LTO для этого пакета в спеке (для всего пакета или хотя бы для цели sqlparser) и пересобрать. Проверка результата по-прежнему в одну команду, без запуска GUI: objdump -d /usr/lib64/mysql-workbench/libsqlparser.so.8.0.47 | grep -cE '\s(call|jmp)\s+0 <' Сейчас 65, после исправления должно быть 0. Если соберёте задание — прогоню на нём сценарий с запросом и отпишусь.
Собрано с отключенным LTO в задании #433356 objdump -d usr/lib64/mysql-workbench/libsqlparser.so.8.0.47 | grep -cE '\s(call|jmp)\s+0 <' 0
Спасибо, проверил сборку 8.0.47-alt7 из задания https://packages.altlinux.org/tasks/433356/ — падение ушло. Стенд: Sisyphus x86_64 на 2026-09-18, ядро 6.12.103-6.12-alt1, mariadb-server-12.3.3-alt1, пакеты взяты прямо из задания (mysql-workbench-community-8.0.47-alt7 и -data). Профиль чистый (rm -rf ~/.mysql), автодополнение НЕ отключал — то есть ровно сценарий репортёра с настройками по умолчанию. Local instance 3306 → SQL-редактор → `SELECT * FROM test.test_table;` + Ctrl+Enter: результат выводится в Result Grid («1 one», «2 two»), статус «Query Completed», процесс тот же самый (PID не менялся за весь сеанс). $ journalctl -k | grep -i segfault # ничего, rc=1 $ journalctl | grep ANOM_ABEND | grep -i workbench # пусто $ coredumpctl # No coredumps found Статика на установленной системе: $ objdump -d /usr/lib64/mysql-workbench/libsqlparser.so.8.0.47 | grep -cE '\s(call|jmp)\s+0 <' 0 # было 65 $ readelf -sW --dyn-syms /usr/lib64/mysql-workbench/libsqlparser.so.8.0.47 | grep -E ' memcpy| memset| memmove' 24: ... UND memset@GLIBC_2.2.5 37: ... UND memcpy@GLIBC_2.14 78: ... UND memmove@GLIBC_2.2.5 $ readelf -sW /usr/lib64/mysql-workbench/libsqlparser.so.8.0.47 | grep -c lto_priv 0 # на alt5 было 529 Переходов по нулевому адресу нет ни в одной библиотеке пакета. Прогнал заодно то, что рядом, 18 наборов результатов подряд в одной сессии без единого падения: `SELECT 1;`; таблица с кириллицей (это важно, потому что на alt5 битые вызовы сидели в том числе в my_strnncoll_tis620, my_like_range_*, my_strnxfrm_*); COUNT, LIKE, UPPER с ORDER BY, JOIN; два скрипта через Execute All на 6 и 4 оператора — самая показательная проверка, потому что падал именно splitSqlScript, и здесь ему на вход идёт несколько операторов; автодополнение (после «SELECT * FROM test.» всплыл список таблиц, подстановка сработала, запрос выполнился); вкладка схемы с колонками, индексами и внешними ключами; сохранение скрипта в файл. Два замечания к закрытию: 1. В Сизифе на момент проверки ещё alt6 (apt-cache policy: candidate 8.0.47-alt6, sisyphus+433338). Закрывать FIXED с версией 8.0.47-alt7 и ссылкой на задание логично после того, как оно доедет до репозитория. 2. p11 остаётся сломанным: там 8.0.47-alt2, в libsqlparser 63 перехода по нулевому адресу и нет memcpy в .dynsym. В ветку тоже нужна пересборка без LTO, иначе тот же SIGSEGV останется у пользователей p11.
mysql-workbench-community-8.0.47-alt7 -> sisyphus: Thu Sep 17 2026 Andrew A. Vasilyev <andy@altlinux> 8.0.47-alt7 - NMU: disable LTO (Closes: #52901).
Спасибо за исправление
