Created attachment 8266 [details] Crash info Стал стабильно падать apt-indicator-checker. apt-indicator-0.3.12-alt4.x86_64 apt-0.5.15lorg2-alt71.x86_64
Подтверждаю. Воспроизводится хорошо, буду смотреть.
Просто пересборка apt-indicator исправила проблему для меня. Вчера apt-indicator собирался с apt-0.5.15lorg2-alt70, а затем был собран ещё apt-0.5.15lorg2-alt71. Возможно, что-то отвалилось при этом. Попробуй задание #236911.
Задание #236911 с пересобранным apt-indicator ушло в Сизиф.
(In reply to comment #2) > Просто пересборка apt-indicator исправила проблему для меня. Вчера > apt-indicator собирался с apt-0.5.15lorg2-alt70, а затем был собран ещё > apt-0.5.15lorg2-alt71. Возможно, что-то отвалилось при этом. Попробуй задание > #236911. Так что по сути это проблема в сборке apt -- что мы недоглядели, что существующий ABI поменялся и нужно было менять soname. Хотел бы лучше понять, в чём тут была причина и -- на будущее -- на что смотреть ещё, если я не понимал раньше, что это относится к случаям, когда необходимо менять soname. Мне при том просмотре изменений в 0.5.15lorg2-alt71 показалось, что там только добавляются новые функции (так что нестрашно: зависимости с set-versions у пакетов клиентов всё равно не позволят подсунуть им неподходящий libapt). Но теперь вижу, что в класс pkgCacheFile в cachefile.h добавилось поле (pkgSourceList *SrcList), не в конец структуры (если смотреть на порядок объявления). (По крайней мере иногда добавление поля в конец структуры не приводит к слому ABI для старых клиентов, как известно. Например, если они передают в API указатели на одиночные структуры, но не указатели на массивы этих структур или просто копии. Правда, новых клиентов, использующих это поле, всё же можно сломать, подсунув старый libapt и никто ничего не заметит.) Могло ли именно это вызвать это падение apt-indicator?.. Там в dist-upgrade.cpp в функции update на строчке 252 и в функции dist_upgrade на строчке 267 действительно заводятся локальные переменные pkgCacheFile Cache. Так что этот хедер и класс вполне себе публичные (кто-то из клиентов их использует), и такое изменение должно было сопровождаться сменой soname. Правда, в crash log-е падение не совсем в этом месте: #0 pkgSourceList::~pkgSourceList (this=0x7fffffffd8a0, __in_chrg=<optimized out>) at /usr/include/c++/8/bits/stl_iterator.h:796 #1 0x0000000000407fb1 in DistUpgrade::update (this=0x42f000) at dist_upgrade.cpp:190 #2 0x0000000000408e08 in DistUpgrade::start (this=0x42f000) at dist_upgrade.cpp:400 а в функции update в строчке пораньше. Правда, уже не очень хочется разбираться дальше, как это падение произошло. Возможно, действительно, из-за изменения класса pkgCacheFile; а каким образом оно повлияло и привело к падению именно здесь, затрудняюсь сказать. В остальном (помимо этого поля) в изменениях в хедерах в alt71 нет ничего страшного, что могло бы привести к падению: добавление функций или невиртуальных митодов (что то же самое) -- они на вид структуры не должны повлиять. * * * Конечно, если какие-то клиенты libapt после alt71 всё же не были экстренно пересобраны, то им угрожает опасность падения. (Есть подозрения на счёт непересборки apt-repo-tools, но возможно, оно и так работает, если там не используются изменённые ABI.)
цифирек не жалко, можно увеличивать soname при любом изменении ABI. Бинарная совместимость нам тут ни с кем не нужна.
(In reply to comment #5) > цифирек не жалко, можно увеличивать soname при любом изменении ABI. > Бинарная совместимость нам тут ни с кем не нужна. Вот бы ещё был упрощённый путь получения approve на чистый rebuild, более автоматический.
(В ответ на комментарий №6) > (In reply to comment #5) > > цифирек не жалко, можно увеличивать soname при любом изменении ABI. > > Бинарная совместимость нам тут ни с кем не нужна. > > Вот бы ещё был упрощённый путь получения approve на чистый rebuild, более > автоматический. Проблема в том, как определить, rebuild чистый или нет. Простая пересборка пакета с новыми версиями зависимостей или сборочной инфраструктуры может дать другой результат. Простой пример: тихо перестанет находиться какая-то зависимость по неопределённой причине, и вот уже пересобранный пакет будет без некоторых фич. А пересобрался пакет без видимых при беглом просмотре проблем. Приходилось уже видеть такое.
(In reply to comment #4) > смотреть ещё, если я не понимал раньше, что это относится к случаям, когда > необходимо менять soname. > > Мне при том просмотре изменений в 0.5.15lorg2-alt71 показалось, что там только > добавляются новые функции (так что нестрашно: зависимости с set-versions у > пакетов клиентов всё равно не позволят подсунуть им неподходящий libapt). > > Но теперь вижу, что в класс pkgCacheFile в cachefile.h добавилось поле > (pkgSourceList *SrcList), не в конец структуры (если смотреть на порядок > объявления). (По крайней мере иногда добавление поля в конец структуры не > приводит к слому ABI для старых клиентов, как известно. Например, если они > передают в API указатели на одиночные структуры, но не указатели на массивы Если подумать, то разрешённое напрвление другое: если библиотека клиенту отдаёт указатель на структуру, то в библиотеке можно добавить поле и не сломать старого клиента. > этих структур или просто копии. Правда, новых клиентов, использующих это поле, > всё же можно сломать, подсунув старый libapt и никто ничего не заметит.)
(In reply to comment #7) > (В ответ на комментарий №6) > > (In reply to comment #5) > > > цифирек не жалко, можно увеличивать soname при любом изменении ABI. > > > Бинарная совместимость нам тут ни с кем не нужна. > > > > Вот бы ещё был упрощённый путь получения approve на чистый rebuild, более > > автоматический. > > Проблема в том, как определить, rebuild чистый или нет. Простая пересборка > пакета с новыми версиями зависимостей или сборочной инфраструктуры может дать > другой результат. Простой пример: тихо перестанет находиться какая-то > зависимость по неопределённой причине, и вот уже пересобранный пакет будет без > некоторых фич. А пересобрался пакет без видимых при беглом просмотре проблем. > Приходилось уже видеть такое. Согласен, что такая проблема есть.
(In reply to comment #4) > Конечно, если какие-то клиенты libapt после alt71 всё же не были экстренно > пересобраны, то им угрожает опасность падения. (Есть подозрения на счёт > непересборки apt-repo-tools, но возможно, оно и так работает, если там не > используются изменённые ABI.) Даже неэкстренно, пересобрать сейчас (если вдруг что-то не пересобрали) -- вполне уместно и невредно. Потому что alt70 (soname change) и alt71 (слом ABI) были собраны в один день (во все бранчи), поэтому у людей под последним soname могла оказаться только libapt из alt71. С ней и должны правильно работать клиенты, а про поддержку правильно работы с alt70 можно забыть.
(В ответ на комментарий №7) > (В ответ на комментарий №6) > > (In reply to comment #5) > > > цифирек не жалко, можно увеличивать soname при любом изменении ABI. > > > Бинарная совместимость нам тут ни с кем не нужна. > > > > Вот бы ещё был упрощённый путь получения approve на чистый rebuild, более > > автоматический. > > Проблема в том, как определить, rebuild чистый или нет. Простая пересборка > пакета с новыми версиями зависимостей или сборочной инфраструктуры может дать > другой результат. Простой пример: тихо перестанет находиться какая-то > зависимость по неопределённой причине, и вот уже пересобранный пакет будет без > некоторых фич. А пересобрался пакет без видимых при беглом просмотре проблем. > Приходилось уже видеть такое. ну у нас же сизиф, всем очевидно что тут переодически может что-то взрываться. Такое надо проверять тестированием и желательно автоматическим.
Для этого пакета у меня есть идея перманентного фикса, расскажу по возвращении.
Проверил по индексу репозиториев, какие пакеты не пересобирались после apt (скриптом http://git.altlinux.org/people/imz/public/postgirar.git?p=postgirar.git;a=commit;h=429e4cf33587898ce0bce91b4dd5c62eab18c2ee ). Только apt-repo-tools в sisyphus. Отправил пересобраться (на всякий случай). Задание 237834; прошу одобрить (Глеба, в первую очередь).
(In reply to comment #13) > Проверил по индексу репозиториев, какие пакеты не пересобирались после apt > (скриптом > http://git.altlinux.org/people/imz/public/postgirar.git?p=postgirar.git;a=commit;h=429e4cf33587898ce0bce91b4dd5c62eab18c2ee > ). $ ./postgirar-built-earlier sisyphus apt apt-indicator apt-repo-tools aptitude packagekit perl-AptPkg synaptic apt-repo-tools $ ./postgirar-built-earlier p9 apt apt-indicator apt-repo-tools aptitude packagekit perl-AptPkg synaptic $ > Только apt-repo-tools в sisyphus. Отправил пересобраться (на всякий случай). > Задание 237834; прошу одобрить (Глеба, в первую очередь).
