А ни у кого tmux не сегфолтится? (ncurses гадит)

Версию тмукса указывать ты конечно же не будешь.

★★★★★

Ни номера версии, ни дистрибутива…

Паника и отчаяние.

У меня не воспроизводится. Версию tmux и название дистрибутива я тоже разглашать не буду. Сделаем эту ветвь максимально бесполезной.

Так и у меня не воспроизводится на соседних устройствах с аналогичными версиями приложений.

tmux-3.3a:

• libevent-2.1.12
• ncurses-6.4_p20230415
• libutempter-1.1.6

Ещё:

• кеды у меня 5.25.5
• видео 530.41.03
• рост 185, вес 90

Ничего из этого во время появления проблемы не обновлялось.

В vim никаких проблем нет?

Тестируй память

Сборка ядра - хороший тест? Если да, то проблем нет. Если я правильно понимаю выхлоп dmesg, то проблема не в памяти, а в том, что tmux лезет туда, куда ему не положено.

Нет, сборка ядра не тест. Тест — memtest86 например. Попробуй побисектить, по крайней мере станет яснее, память или нет. Удали половину планок. Проверь. Если крашится — проверь со второй половиной, без первой. Если ВНЕЗАПНО краш при удалении половины мозгов исчезнет — это память. Маловероятно конечно что это она, но если у тебя одинаковый софт везде, а проблема только на одной машине — я предполагаю проблему с самой машиной.

Тест — memtest86 например

Что он покажет для ECC памяти?

Ну, что то да покажет, но яж не знал что она у тебя ECC. Ты же инфу по чайной ложке из себя выдавливаешь.

Ты же инфу по чайной ложке из себя выдавливаешь.

Всё работает, кроме тмукса. Всё от компиляции тяжестей в 25 потоков - ядро, файрфокс, клиент телеги, до кейсов когда выбирается вся оперативка. Всё это работает, крашится только tmux и только при определённых действиях.

Какая информация кроме этой, которая дублирует ОП ещё может подсказать причину?

Автобиография может? )

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

Я выше написал почему я грешу на железо. И кроме памяти легко и непринуждённо ничего особо и не проверишь. Но с ECC да, вряд ли это она, ты бы ругань на ECC в dmesg видел. Хотя говорят нынче десктопные платформы в ECC умеют, а вот в MCE\RAS\EDAC (наплодили аббревиатур) — нет, так что ты об ошибках и сбоях и не узнаешь, потому что железо не расскажет. Но опять таки я не знаю что у тебя за железо.

Есть ещё хороший совет из разряда «по колёсам попинать, капот открыть\закрыть». Попробуй воспроизвести в новом чистом юзерском профиле. Да, бред, но ты попробуй. KDE оно такое...

В общем и целом согласен.

Из всей этой ситуации есть один положительный момент, раз уж я открыл системник, пришлось его «пропылесосить».

Т.е. перестановка планок и игры с профилем никак не повлияли - всё работает, включая и тмукс, но если вдруг понадобилось поскролить и случайно зажал ЛКМ, то тмукс роняется (воспроизводится и на дефолтном конфиге).

Продолжаю наблюдения, но идей нет.

В gdb надо продолжать наблюдения.

Падает исключительно в режиме mouse on если случайно или специально с зажатой ЛКМ что-то выделить

А если mouse off и выделять хоткеями?

Во всяком случае есть tmux crashes when selecting text #3549, открытый 9 часов назад, и закрытый без всякого рассмотрения (No logs, no description.). Но там же ссылка и на похожий issues.

А не у кого

Правильно писать «А нИ у кого».

Мало того, что я троешник по-русскому, я ещё и не внимательный (не отдельно, правильно?).

А если mouse off и выделять хоткеями?

Суть в том, что при mouse on выделение не нужно и я им не пользуюсь, только переключение. А упс происходит, если случайное палец на ЛКМ задержался и дёрнул мышкой.

Если нужно текст из консоли скопировать, то я по хоткею переключаюсь в mouse off, а теперь вот несколько дней как это мой основной режим.

Ещё наблюдения показали:

• что версия ядра не влияет
• железо не причём, потому что в systemrescue всё ок

Т.е. проблема в системе, осталось выяснить, кто гадит. Пока на подозрении qtdeclarative.

Буквально как пару дней падает на ровном месте …

Что 2 дня назад поменялось? (обновления, мышку почистили, пыль смахнули, …?) Можно ли запустить систему на другом железе и воспроизвести ошибку?

Ситуация воспроизводимая, ломается после обновления пакетов из этого списка:

go-1.20.3
ncurses-6.4_p20230424
readline-8.2_p1
json-c-0.16_p20220414-r1
bluez-5.66
setuptools-67.7.2
libusb-1.0.26
harfbuzz-7.2.0
fribidi-1.0.12
trove-classifiers-2023.4.25
cpupower-6.3
pango-1.48.11
dhcpcd-10.0.1
libpcap-1.10.4
yarl-1.9.2
poppler-23.04.0
qtdeclarative-5.15.2_p20230421
libmypaint-1.6.1

ncurses и readline откатывал, они похоже не причём. Выдастся время буду проверять остальные.

Возможно ты откатился просто к другой бажной версии ncurses. Чекни вот этот баг: https://bugs.gentoo.org/904263

Я знал, я верил в ЛОР. По своей самоуверенности я откатывался до версии ncurses-6.4_p20230418 в которой вроде как всё пропатчили и с которой я апгрейдился в момент когда заметил баг.

Остановился на ncurses-6.4_p20230401 странное поведение из ОП ушло.

Спасибо.

Час назад новый коммит вышел, возможно это краем касается и проблемы этой темы?

Начиная с 39d41d0, tmux будет использовать ncurses’ tiparm_s функция, которая ThomasDickey добавлено, позволяющее ему обрабатывать неизвестные возможности с помощью строковых параметров (tmux может сообщать ncurses, что он получает).
Вам нужно будет обновить ncurses до версии 6.4-20230424 или более поздней и собрать tmux из master.
https://github.com/tmux/tmux/issues/3539#issuecomment-1527026935

Да, похоже что это оно.