У меня упал терминал

бережно накопленное за полгода работы состояние окон

Кошмар-то какой.

libvte

Зачем? Не проще ли использовать например st? Там нет привязки к libvte, соотвественно такая ошибка невозможна.

32-битный счётчик

Откуда он такой на 64-х битной системе?

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

Могу посоветовать тебе авесому. Там можно заранее прописать где какое окно будет расположено после запуска wm.

Обычный int остаётся 32-битным на 64-битной системе.

assertion failed (offset >= snake->tail)

У змейки хвост отвалился.

упавший xfce4-terminal похоронил бережно накопленное за полгода работы состояние окон, по которому я уже привык ориентироваться в текущих делах

полагаю, здесь сразу с медикаментозного надо начинать

обычный int платформозависимый, не?

Не до конца понял вопрос.

int соответствует int32 на 32-битной платформе и int64 на 64-битной платформе. Это означает, что если ваша программа работает на 32-битной архитектуре, то тип int будет соответствовать типу int32, а если на 64-битной платформе – int64.

Я имел в виду то, что в результате работы программы

#include <stdio.h>

int main( int argc, char* argv[], char* envp[] ){
	printf( "%lu\n", sizeof(int) );
	return 0;
}

на выхлопе будет 4 и на 32 и на 64 битных системах.

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

ты откуда и как к нам попал?
этот IT не для тебя

QsUPt7S, возможно, я не прав, но единственный сдучай, когда у меня int был не 4 байта - это на ардуинах. Там размер был 2 байта. На «обычных» процах я везде видел только 4 байта.

Есть платформы разных типов. https://archive.opengroup.org/public/tech/aspen/lp64_wp.htm
Линукс на x86_64/aarch64 - это LP64.

Мне не расположение окон нужно, а запущеные в них шеллы с длинными историями (лимит на скроллбак отключил), текстовые редакторы, просто открытые директории в mc (посмотрел - вспомнил что я тут что-то хотел сделать), и ещё что-то.

А вот это фатально, да. Высад.

бережно накопленное за полгода работы состояние окон

Здесь проблема.

Комп включается утром и выключается вечером. Полность, без трюков со сном. Всё остальное это сорта локалхостного админства с дрочкой на аптайм.

Ты какую-то чушь несёшь. Нафиг мне терять состояние каждый день? А тем более, нафиг мне его вечером выключать если он может в любое время суток пригодиться? Это у тебя дрочка на какие-то правила полувековой давности про обесточивание техники.

Здесь проблема.

Это не проблема, а единственное на сейчас решение для сохранения рабочей сессии. Мне что каждое утро 100500 окон раставлять на нужных местах, открывать заново терминалы и все проги? Только s3 ram и спасает.

У меня на aarch64 sizeof(int) выдаёт 4

А отправь им баг, очень хочется почитать там каменты.

Это у тебя дрочка на какие-то правила полувековой давности про обесточивание техники.

Обесточить могут и против твоего желания 😊

А у меня tilix в последнее время чудит. Даже перечислять не стану. Но пока всё равно его использую, такого удобного разделения окон нигде нет, терминатор есть, но такое себе.

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

Открой для себя уже тайловые WM. Вы всё ещё расставляете окошки вручную? Тогда мы идём к вам.

тайловые WM

Это про терминалы ведь? Придумали-же screen, tmux - они не решают проблему с состоянием многих терминалов?

Эта груда костылей может в любой момент с грохотом развалиться

Бхггг. Пришло время ребутать линукс! Ребутни линукс, пока всё не успело развалиться само!

Это про окружение рабочего стола: gnome, kde и т.д.

Я так понимаю ты работаешь с live cd? Ну а чё, перезагрузка всё равно не нужна же. Стейт на диске лишний.

На всех нормальных платформах int всегда 32 битный. На x86_64 именно так.

здесь сразу с медикаментозного

принудительного усыпления

надо начинать

xfce4-terminal

А не надо этим пользоваться.

Что за бред? Это для какого жавоскрипта так? В си-подобных инт приклеен к 32 битам.

возможно, я не прав, но единственный сдучай, когда у меня int был не 4 байта - это на ардуинах. Там размер был 2 байта. На «обычных» процах я везде видел только 4 байта.

Ты прав.

Размеры базовых математических типов int, long в различных ОС в зависимости от битности

Какой ты злой.

упавший xfce4-terminal похоронил бережно накопленное за полгода работы состояние окон, по которому я уже привык ориентироваться в текущих делах

Не могу формализовать почему именно, но я совсем не удивлен.

У ноута есть аккум и аварийный сон при 20% (если я сам вовремя не предприму ничего). Если этих 20% не хватит переждать отключение то плохо да.

А зачем они используют int и не используют ssize_t ?

Я не знаю, что они используют. Я просто написал пример, как может быть на 64 битной системе 32 битный счётчик.

Они не думали, что найдется фанат их терминала, который будет держать терминал открытым полгода и поставит бесконечный буфер прокрутки.

ещё не все time_t are 64bits, в тестинге была акция последние полгода по переводу счётчиков времени на 64 бита, т.е. фиксили и пересобирали всё что использует time_t, всё прикладное и системное ПО.
недавно только успокоились, с другой стороны - всё работает.

ps. fyi - https://wiki.debian.org/ReleaseGoals/64bit-time

https://github.com/GNOME/vte/blob/0d393b6cd6a24f53eaefa16764b9453a1483acf5/src/vtestream-file.h#L350

typedef struct _VteSnake {
        GObject parent;
        int fd;
        int state;
        struct {
                gsize st_tail;  /* Stream's logical tail offset. */
                gsize st_head;  /* Stream's logical head offset. */
                gsize fd_tail;  /* FD's physical tail offset. */
                gsize fd_head;  /* FD's physical head offset. One of these four is redundant, nevermind. */
        } segment[3];           /* At most 3 segments, [0] at the tail. */
        gsize tail, head;       /* These are redundant too, for convenience. */
} VteSnake;

Теперь знаешь.

Судя по официальной документации,
https://docs.gtk.org/glib/types.html#gsize
на 64-х битной платформе gsize должен быть 64 бита.

4294901760 (0xFFFF0000)

Надо выяснить, откуда берётся эта константа. А то может поле-то и 64-х битное, а вот значение в нём - маленькое.

Поле 32-битное, у меня 32-битная система. То что гномокодеры не знают стандартов и считают что size всегда 64 - плохо говорит только о них. Но дело даже не в этом, битность не важна, если у тебя скользящий буфер то врап всегда надо предусматривать, а не делать предположений «да наверно не дойдём до него».

0xFFFF0000 это последний 64кб блок из возможных, после него идёт нулевой.

у меня 32-битная система

ой, всё.

накопленное за полгода работы состояние окон

И ты не ребутал комп ни разу? И систему обновлял при этом?

у меня 32-битная система.

А вот и вторая проблема вскрылась.

С тех пор как выявил и ликвидировал единственную критичную проблему (сон во время висящего fuse-запроса не просыпается и приходится ребутать) - не ребутал. Ядро, очевидно, не обновлял (5.10.197 запущено).

Ядро, очевидно, не обновлял

А мог бы. Там для этого специальный механизм есть. Мы бы все обзавидовались и слюной истекли.

не ребутал

А не мешало бы. Прикалываешься?.. Софт, либы обновляются, а он сидит и в ус не дует. Вообще удивляюсь, как все остальное у тебя работает.

И да, велкам сюда, если проблема реально существует (после ребута и тестов): https://gitlab.gnome.org/GNOME/vte/-/issues