Что больше deadbeef или abadbabe
обсуждение deadbeef
Данная тема посвящена обсуждению проекта deadbeef player.
нет. для wildmidi есть весомые причины тащить с собой — лицензия и критические баги. в gtk нет ни того, ни другого.
Что не так с лицензией и какие конкретно баги?
ты еще gstreamer предложи использовать, ага..
Не аргумент. И мы про ffmpeg говорим вроде. Зачем передёргивать?
запили морду на EFL
Что не так с лицензией и какие конкретно баги?
она gpl3. а плеер gpl2.
баги давно пропатчены, и подробностей не помню. помню только что было несколько сегфолтов, несколько утечек памяти, и как минимум 1 срыв стека.
Не аргумент. И мы про ffmpeg говорим вроде. Зачем передёргивать?
ffmpeg не предоставляет нужных функций и достаточной стабильности для данного проекта. он изначально использовался только как временная мера для поддержки новых либо экзотических форматов, для которых еще не успели написать плагины.
я собирался это сделать. причем несколько раз.
1й раз был еще в самом начале проекта, но оказалось, что EFL ни у кого не установлен, и релизов нет (только сборки из VCS).
2й раз был когда они релизнули 1.0
оказалось, что тулкит больше ориентирован на мобильные платформы, а для десктопа слишком примитивен. (впрочем, для мобильных он тоже далек от моего идеала)
LGPLv3, если быть точным. В чём проблема?
ffmpeg не предоставляет нужных функций и достаточной стабильности для данного проекта. он изначально использовался только как временная мера для поддержки новых либо экзотических форматов, для которых еще не успели написать плагины.
О каких функциях и какой стабильности идёт речь? Уже лет 8 использую mplayer. Серьёзных проблем со звуком не встречал.
Не тролинга ради, можешь расписать его примитивность и недостатки по сравнению с тем же гтк2?
LGPLv3, если быть точным. В чём проблема?
значит еще раз лицензию поменяли. я точно помню, что было GPL3.
версия 0.2, которую я использую, под GPL2. не LGPL.
проблема в том, что я не использую код под [L]GPL3 в своем проекте.
О каких функциях и какой стабильности идёт речь? Уже лет 8 использую mplayer. Серьёзных проблем со звуком не встречал.
функции: sample accurate seeking, gapless playback, complete tagging support, cuesheet support
стабильность: ffmpeg вылетает при попытке играть многие (кривые) файлы.
Не тролинга ради, можешь расписать его примитивность и недостатки по сравнению с тем же гтк2?
Существует какой-нибудь менеджер плейлистов для Deadbeef? При количестве больше 15-20 становится неудобно выбирать плейлист.
в git есть виджет playlist browser. показывает плейлисты в виде списка (с поиском).
На curses морду не хочешь сделать? А то мутит уже от этого блевотного GTK. Хорошо хоть, что не кути…
хочу. причем уже давно. но времени нет, к сожалению. и даже не знаю, будет ли на это время когда либо.
значит еще раз лицензию поменяли. я точно помню, что было GPL3.
проблема в том, что я не использую код под [L]GPL3 в своем проекте.
Это и не требуется.
функции: sample accurate seeking, gapless playback, complete tagging support, cuesheet support
Это функции плеера, а не библиотеки с кодеком. И да, в mad, vorbis, flac этого тоже нет.
стабильность: ffmpeg вылетает при попытке играть многие (кривые) файлы.
В компьютерном программировании термин « магическое число» имеет несколько значений. Это может относиться к одному или нескольким из следующего:
СОДЕРЖАНИЕ
Безымянные числовые константы
Это предпочтительно по нескольким причинам:
Допустимые виды использования
В некоторых контекстах общепринято использование безымянных числовых констант (и, возможно, «не магия»). Хотя такое принятие является субъективным и часто зависит от индивидуальных привычек программирования, ниже приведены общие примеры:
Индикаторы формата
Источник
В файлах
В протоколах
В интерфейсах
Другое использование
Ограничения типа данных
Это список ограничений типов хранения данных:
Можно создать или изменить глобальные уникальные идентификаторы (GUID), чтобы они были запоминающимися, но это крайне не рекомендуется, поскольку это ставит под угрозу их силу в качестве почти уникальных идентификаторов. Спецификации для генерации GUID и UUID довольно сложны, что делает их практически уникальными при правильной реализации. Они должны создаваться только надежным программным средством.
Идентификационные номера продуктов Microsoft Windows для продуктов Microsoft Office иногда заканчиваются на 0000-0000-0000000FF1CE («ОФИС»), например < 90160000-008C-0000-0000-0000000FF1CE >, идентификатор продукта для «Office 16 нажми и работай. Компонент расширяемости «.
Значения отладки
Известные и распространенные примеры включают:
Так как они часто использовались для обозначения областей памяти, которые были по существу пустыми, некоторые из этих терминов стали использоваться во фразах, означающих «пропал, прерван, стерто из памяти»; например, «Ваша программа DEADBEEF».
Эксперимент: ищем int i = 0xDEADBEEF в дампе физической памяти
Изучение виртуального адресного пространства и алгоритма преобразования адресов заметно упростится, если начать с несложного практического примера. Для этого напишем простую программу, выводящую адрес локальной переменной:
Затем попробуем найти физический адрес и просмотреть значение по этому адресу.
Будем рассматривать 32-битную Windows (без всяких Physical Address Extension), потому что 64-битная сложнее. Описание преобразования упрощено, но достаточно для нашего эксперимента. Рекомендую проверять в виртуалке. Неважно в какой, но в конце я покажу как выгрузить дамп памяти в VirtualBox.
Основы
В моем случае адрес получился равным 0x22FF2C. Вообще, он может различаться при каждом запуске программы (см. ASLR). У других процессов по этому адресу могут находиться какие-то свои значения, потому что это не физический, а виртуальный адрес. Пожалуй, основное предназначение виртуального адресного пространства – возможность предоставлять каждому процессу собственное адресное пространство, в котором он бы не мешал другим. Размер виртуального адресного пространства зависит от платформы. Для x86 теоретический максимальный размер составляет 4 Гб. По умолчанию, первая половина (0 – 0x7FFFFFFF) является пространством процессов пользователя, в котором располагается образ исполняемого файла текущего процесса, его стек, куча и прочее. Вторая половина (0x80000000 – 0xFFFFFFFF) – системным. С некоторыми оговорками можно считать, что пространство процессов пользователя уникально для каждого процесса, а системное только одно. Адрес 0x22FF2C, очевидно, попал в первую половину.
Виртуальное адресное пространство разбито на 0x100000 (1048576) страниц размером 4096 байт каждая. Физическая память также разбита на страницы такого же размера, называемых страничными блоками. Страницы (не все, конечно) отображаются на страничные блоки, поэтому для каждой страницы нужна информация о ее расположении в физической памяти. Всем 0x100000 страницам соответствует столько же 4-байтовых записей, называемых PTE (page table entry – запись таблицы страниц). В виртуальном пространстве они расположены в диапазоне адресов 0xC0000000 — 0xC03FFFFF, и занимают 1024 страницы, называемых таблицами страниц. Получить запись просто: k-й странице соответствует k-я запись.
Оранжевым отмечены таблицы страниц.
Умножение на 4 потому что PTE – 4-байтовые. Получаем, что в нашем случае pte_addr = 0xC00008BC
Наивная попытка
Адрес PTE есть, пробуем узнать что там:
Ну, ой. Аппаратное исключение. А все потому, что мы пытались читать из системного пространства. ReadProcessMemory тоже не поможет. Вызов VirtualQuery скажет нам PAGE_NOACCESS. Получить доступ можно только получив привилегии режима ядра. Пожалуй, самый простой способ для нашей исследовательской задачи — использовать отладчик ядра.
Использование отладчика ядра
Ставим KD и LiveKd. LiveKD позволяет запускать отладчики ядра Microsoft Kd и Windbg, входящие в пакет инструментов отладки для Windows, в действующей системе в локальном режиме. По последней ссылке также небольшая справка по установке и справке.
Нас интересует адрес после слова PROCESS (это адрес на структуру EPROCESS, содержащей атрибуты процесса). Подключаемся к процессу:
Проверяем содержимое по адресу 0x22FF2C, чтобы убедиться, что все сделали правильно:
По умолчанию используются шестнадцатеричные числа. Команда dd выводит несколько 4-байтовых значений, начиная с указанного виртуального адреса. L1 – вывод только одного значения.
Чтение PTE
Можно было самим не считать:
В значении PTE записи 6612f847 первые 20 бит (5 hex-цифр) – индекс страничного блока, остальное – различные флаги. Чтобы получить адрес страничного блока, нужно индекс умножить на размер блока – 4096 байт.
Порядок байтов внутри страницы и страничного блока совпадает, поэтому необходимо рассчитать смещение внутри страницы и прибавить к адресу страничного блока:
Мы выяснили, что наш адрес можно представить так:
Но еще заметьте, что найденная PTE находится в 0-й таблице страниц с индексом 0x22F внутри нее. И наш адрес может быть представлен так:
We need to go deeper (PDE)
Пользоваться виртуальными адресами PTE неспортивно. Ведь они тоже являются обычными страницами которым нужно найти страничные блоки. А раз так, то просто найдем свои PTE для этих страниц. Всего у нас 1024 таких страниц (называемых таблицами страниц) и все PTE для них помещаются в одной странице. Эту страницу называют каталогом страниц и она содержит 1024 записи (называемых PDE – page directory entry, запись каталога страниц) с адресами на таблицы страниц.
Синим отмечен каталог таблиц, оранжевым – таблицы страниц.
Поступаем точно так же, как уже делали:
Получили адрес PDE = 0xC0300000 (все PDE хранятся в странице по адресу 0xC0300000, мы попали в нулевую PDE). Проверяем содержимое:
Полностью аналогично: PDE, содержащая 0b21d867, дает нам адрес 0x0B21D000 страничного блока с таблицей страниц. Осталось найти в ней нужную PTE. Вспомним, что адресу 0x22FF2C соответствует PTE с индексом 0x22F в 0-й таблице (со смещением 0x22F * 4). Значит, PTE находится по адресу 0x0B21D000 + 0x22F * 4.
С адресом 6612f847 мы уже работали.
Итоговая формула
Ищем в дампе
Думаю, снять дамп с работающей системы несколько проблематично, поэтому снимем с VirtualBox. Для этого нужно запустить в режиме отладки:
Открываем файл (я пользуюсь HxD), переходим на 6612ff2c:
Зная DirBase и виртуальный адрес можно искать значение сразу в дампе, без отладчика. Вообще, в дампе можно найти значение DirBase по имени процесса, но это уже другая история.
История потерянного коммита
Был уже вечер, когда ко мне обратился разработчик. Из мастер-ветки пропал патч — коммит deadbeef.
Мне показали доказательства: вывод двух команд. Первая из них —
— показывала изменения файла, назовём его Page.php. В него добавились метод canBeEdited и его использование.
А в выводе второй команды —
— коммита deadbeef не было. Да и в текущей версии файла Page.php не было метода canBeEdited.
Не найдя решения быстро, мы сделали ещё один патч в мастер, разложили изменения — и я решил, что вернусь к проблеме на свежую голову.
Это сделали специально? Файл переименовали?
Поиск проблемы я начал с обращения за помощью в чат команды релиз-инженеров. Они среди прочего отвечают за хостинг репозиториев и автоматизацию процессов, связанных с Git. Честно говоря, они, наверное, и патч могли удалить, но сделали бы это без следов.
—follow
Continue listing the history of a file beyond renames (works only for a single file).
(Показывать историю файла после его переименований (работает только для одиночных файлов))
К сожалению, рассматриваемый репозиторий — один из самых больших у нас. С момента внесения первого патча и до его исчезновения была совершена 21 000 коммитов. Повезло ещё, что нужный файл правился только в десяти из них. Я изучил их все и не нашёл ничего интересного.
Ищем свидетелей! Нам нужен livebear
Стоп! Мы же только что искали deadbeef? Давайте рассуждать логически: должен быть некий коммит, назовём его livebear, после которого deadbeef перестал отображаться в истории файла. Возможно, это нам ничего не даст, но натолкнёт на какие-то мысли.
Для поиска в истории Git есть команда git bisect. Согласно документации, она позволяет найти коммит, в котором впервые появился баг. На практике её можно использовать для поиска любого момента в истории, если знать, как определить, наступил ли этот момент. Нашим багом было отсутствие изменений в коде. Я мог это проверить с помощью другой команды — git grep. Ведь мне достаточно было знать, есть ли метод canBeEdited в Page.php. Немного отладки и чтения документации:
livebear [build]: Merge branch origin/XXX into build_web_yyyy.mm.dd.hh
Выглядит как обычное слияние (merge commit) ветки задачи с веткой релиза. Но с этим коммитом удалось воспроизвести проблему:
Правда, ничего интересного в livebear я не нашёл, а его связь с нашей проблемой осталась неочевидна. Подумав немного, я отправил результаты своих поисков разработчику: мы сошлись на том, что, даже если доберёмся до истины, схема воспроизведения будет слишком сложной и мы не сможем подстраховаться от чего-то подобного в будущем. Поэтому официально мы решили прекратить поиски.
Однако моё любопытство осталось неудовлетворённым.
Упорство не порок, а большое свинство
Ещё несколько раз я возвращался к проблеме, прогонял git bisect и находил всё новые и новые коммиты. Все — подозрительные, все — слияния, но это ничего мне не дало. Мне кажется, что один коммит тогда попадался мне чаще других, но я не уверен, что именно он оказался виновником в итоге.
Конечно, я пробовал и другие методы поиска. Например, несколько раз перебирал 21 000 коммитов, которые были сделаны на момент возникновения проблемы. Это было не очень увлекательно, но мне попалась интересная закономерность. Я запускал одну и ту же команду:
Оказалось, что «плохие» коммиты, в которых не было нужного кода, были в одной и той же ветке! И поиск по этой ветке быстро привёл меня к разгадке:
changekiller Merge branch ‘master’ into TICKET-XXX_description
Это тоже было слияние двух веток. И при попытке повторить его локально возникал конфликт в нужном файле — Page.php. Судя по состоянию репозитория, разработчик оставил свою версию файла, выбросив изменения из мастера (а именно они и потерялись). Прошло много времени, и разработчик не помнил, что именно произошло, но на практике ситуация воспроизводилась простой последовательностью:
Осталось понять, как легитимная последовательность действий могла привести к такому результату. Не найдя ничего про это в документации, я полез в исходники.
Убийца — Git?
В документации было сказано, что команда git log получает на вход несколько коммитов и должна показать пользователю их родительские коммиты, исключая родителей коммитов, переданных с символом ^ перед ними. Выходит, что git log A ^B должен показать коммиты, которые являются родителями A и не являются родителями B.
Код команды оказался достаточно сложным. Там в изобилии были разные оптимизации для работы с памятью, да и в целом читать код на С никогда не казалось мне очень приятным занятием. Основную логику можно представить вот таким псевдокодом:
Здесь функция get_revision принимает на вход revs — набор управляющих флагов. Каждый её вызов как будто должен отдавать следующий коммит для обработки в нужном порядке (или пустоту, когда мы дошли до конца). Ещё есть функция setup_revisions, которая заполняет структуру revs и log_tree_commit, которая выводит информацию на экран.
У меня было ощущение, что я понял, где искать проблему. Я передавал команде конкретный файл (Page.php), потому что меня интересовали только его изменения. Значит, в git log должна быть какая-то логика фильтрации «лишних» коммитов. Функции setup_revisions и get_revision использовались во многих местах — вряд ли проблема была в них. Оставалась log_tree_commit.
К моей несказанной радости, в этой функции и правда нашёлся код, вычисляющий, какие изменения были сделаны в том или ином коммите. Я думал, что общая логика должна выглядеть как-то так:
Но чем дольше я всматривался в настоящий код, тем больше понимал, что ошибся. Эта функция лишь выводила сообщения. Вот и верь после этого своим ощущениям!
Я вернулся к функциям setup_revisions и get_revision. Логику их работы было сложно понять — мешал «туман» из вспомогательных функций, часть из которых нужна была для правильной работы с указателями и памятью. Всё выглядело так, словно основная логика — это простой обход дерева коммитов «в ширину», то есть достаточно стандартный алгоритм:
Заводится список (revs->commits), туда помещается первый (самый верхний) элемент дерева коммитов. Затем постепенно из этого списка забираются коммиты с начала, а их родители добавляются в конец.
Вчитываясь в код, я обнаружил, что среди «тумана» из вспомогательных функций встречается сложная логика фильтрации коммитов, которую я так долго искал. Это происходит в функции get_revision_1:
В случае когда происходит слияние нескольких веток, если состояние файла осталось таким же, как в одной из них, нет смысла рассматривать другие ветки. Если же состояние файла не менялось нигде, мы оставим только первую ветку.
Пример. Обозначим нулём коммиты, в которых файл не менялся, единицей — те, в которых файл изменился, и X — слияние веток.
В этой ситуации код не станет рассматривать ветку feature — в ней и изменений нет. Если файл там всё-таки изменили, то в X изменения «выкинули», а значит, их история не очень релевантна: этого кода уже нет.
Что-то похожее произошло и у нас. Два разработчика сделали изменения в одном файле — Page.php, один — в ветке мастера, в коммите deadbeef, второй — в ветке своей задачи.
Когда второй разработчик сливал изменения из ветки мастера в ветку задачи, произошёл конфликт, в процессе разрешения которого изменения из мастера он просто выбросил. Прошло время, работу над задачей он завершил, и ветку задачи залили в мастер, удалив таким образом изменения из коммита deadbeef.
Сам коммит при этом остался. Но если запустить git log с параметром Page.php, коммита deadbeef в выводе видно не будет.
Оптимизация — дело неблагодарное
Я бросился внимательно изучать правила отправки изменений и багов в сам Git. Ведь я думал, что нашёл действительно серьёзную проблему: подумать только, часть коммитов просто пропадает из вывода — и это поведение по умолчанию! К счастью, правила оказались объёмными, время было позднее, а на следующее утро мой запал улетучился.
Я понял, что эта оптимизация сильно ускоряет работу Git на больших репозиториях, таких как наш. А ещё для неё нашлась документация в man git-rev-list, и это поведение можно очень легко отключить.
На самом деле, есть много способов повлиять на работу этой логики. Конкретно про флаг follow в коде Git нашёлся комментарий 13-летней давности:
Can’t prune commits with rename following: the paths change.
(Перевод: Не получится выбрасывать коммиты, когда обрабатываются переименования: пути могут меняться)
P. S.
Сам я работаю в команде релиз-инженеров Badoo уже несколько лет, и многие в компании считают, что мы разбираемся в Git.
(Перевод. Оригинал: xkcd.com/1597)
В связи с этим нам приходится разбираться с проблемами, возникающими в этой системе, и некоторые из них мне кажутся достаточно любопытными — как, например, описанная в этой статье. Очень часто проблемы решаются быстро: со многим мы уже сталкивались, что-то хорошо описано в документации. Этот случай был исключением.
На самом деле, в документации действительно был раздел History Simplification, но он был только для команды git rev-list и заглянуть туда я не догадался. Полгода назад этот раздел включили и в мануал команды git log, но наш случай произошёл несколько раньше — я просто не успевал дописать эту статью. (*)
И напоследок у меня остался небольшой бонус для тех, кто дочитал до конца. У меня есть очень маленький репозиторий, где проблема воспроизводится:
Спасибо за внимание!
(*) UPD: Оказалось, что раздел History Simplification был в документации команды git log намного дольше, чем полгода, а я его просто пропустил. Спасибо youROCK, что обратил на это внимание!
Обсуждение DeaDBeeF
Доступны исходники deadbeef 0.7.0 beta1
В ближайшее время будет beta2, постараюсь успеть сделать к нему бинарные сборки.
2mods: Новую тему пришлось создать, т.к. старая почему-то уползла в архив. Возможно ли как-то предотвратить это в будущем?
Возможно ли как-то предотвратить это в будущем?
прикрепить надо, странно что прошлую так и не прикрепили
Сразу не догнал, что разговариваю с автором, так что даже не знаю, стОит ли идти со своими вопросами куда-то еще. Вот мои настройки, всё точно так же: http://fastpic.ru/view/76/2016/0105/e132ed1ab1cc6878333d9de6ebce5307.png
Тогда такой вопрос: в каком конфиге в команде «Seek 1s Backward» изменить значение 1 на большее, а то часто приходится по 2-3 раза нажимать? Одной секунды мало, а один процент даже на 15-минутном файле уже перебор. P.S. Посмотрел файлы в каталоге программы, догадываюсь, что ни в каком.
в каком конфиге в команде «Seek 1s Backward» изменить значение 1 на большее
такого нет, но можно выбрать один из вариантов 1sec, 5sec, 1%, 5%.
это есть в свежих сборках (в т.ч. в 0.7.0-beta2)
может, мне новую тему открыть?
в новой теме нет необходимости.. эта тема как раз для подобных вопросов.
Так вон оно чо! Я-то изначально просил
помещает в клипборд время от начала
и делает Ctrl+V
и ожидал, что по хоткею таймкод сам вставится. Ну, это непринципиально.
Извиняюсь за свою тупость и ваше время ) Большое спасибо.
Как обстоят дела с обновлением плейлистов? Тема вот нашлась на форуме: Обновление плейлистов в DeadBeef
Так вон оно чо! Я-то изначально просил
Как обстоят дела с обновлением плейлистов? Тема вот нашлась на форуме: Обновление плейлистов в DeadBeef
никаких работ в этом направлении не велось, и не ведется (кроме регулярных обсуждений).
А будет ли debubuntu package как в стабильных релизах? Или его не ты собираешь?
для бета-версий никогда не собирал, для релиза будет.
Помню, ты активно фронтенд на кокоауи пилил. Как оно поживает?
ему по прежнему далеко до GTKUI, работы непочатый край, но для моих нужд хватает (у меня это основной плеер, и макось основная ось уже больше года)
а когда примерно планируешь выпустить релиз?
Надеюсь что не позднее чем через месяц.
А сборки на drone.io тоже 0.7+?
Кстати, у меня на ноуте такая странная фигня, хотя на десктопе это же самое работает.
Не знаю, баг это или фича, но пока вместо симлинка сделал скрипт /usr/local/bin/deadbeef:
fixed volume control via mouse scroll when using GTK3
по-моему это где-то обсуждалось уже, но я не помню чем закончилось.
drone.io — это CI. он собирает после каждого коммита из веток 0.7 и master.
Как настроить внешний вид спектроанализатора? Эта могильная чернота, когда ничего не воспроизводится, действует мне на нервы.
Как настроить внешний вид спектроанализатора? Эта могильная чернота, когда ничего не воспроизводится, действует мне на нервы.
это референсный плагин, типа прототипа для написания собственных.
в нем все цвета настраиваются.
сейчас поздно уже искать баги в 0.6.2 — этот релиз вышел полтора года назад, через месяц будет 0.7.
upd: проверил, в 0.7 это работает.
Я его поставил, как теперь включить?
Я его поставил, как теперь включить?
если ты как-то смог включить встроенный, то и до этого сможешь дойти самостоятельно.
зы: ты хоть прочитай сообщения по своей же ссылке, что ты его пытаешься скачать с gitorious, который давно рипнулся.
