Кто-нить пробовал breakpad с yocto интегрировать?

Ох, боюсь уже год не трогал OE/Yocto, скоро я буду спрашивать совета... :)

Вообще говоря, если пакет зависит от конкретных репозиториев, для которых указана ревизия или версия, то оно само и качает именно их и именно таких версий.

Если проблема решена, то как? Если нет, подробнее бы, какие ошибки вываливаются или что не верно?

Если проблема решена, то как? Если нет, подробнее бы, какие ошибки вываливаются или что не верно?

Проблема в том, что breakpad использует depot_tools, это гуглонадстройка на пистоне на гитом.. =) В смысле проблема не решена, я понял в какую сторону копать надо. Ладно, на следующей неделе попробую разгрести )

ха у вас тоже yocto )

ха у вас тоже yocto )

«тогда мы идем подальше от вас»?

З.Ы. У меня тоже yocto

а тебе от этого брейкпада осмысленные дампы приходят?

Мне приходилось на одном проекте, где он был внедрён, разбирать их, в большинстве случаев почему-то неадекватные стектрейсы приходят, с 200-300 вызовами всяких левых функций, чего в норме не должно быть. Проще было отказаться от него и выяснять причины сегфолтов традиционными методами

Всегда были осмысленные. В предыдущей конторе его на x86 использовали. Поймали два бага в boost'e.

Как вариант, ты использовал символы не от той сборки?

Кстати, про embedded world тебе напомнить? :)

Как вариант, ты использовал символы не от той сборки?

от той

А как ты вообще это себе представляешь, программа на девайсе сегфолтится, девайс становится неюзабелен до перезагрузки, при этом он должен быть подключён к интернетам, чтобы отправлять тебе стектрейсы? :) Не та уже нынче эмбедщина, не та )

ну мне и сам эмбеддед ворлд напомнил уже :)

Ога, т.е. по пивцу? )

программа на девайсе сегфолтится, девайс становится неюзабелен до перезагрузки

Это ж не ведро, а userspace программа.

Я только за :)

У нас, кстати, QtMeetup :D

https://www.meetup.com/Qt-Munich-Meetup/events/236789583/

ведро само по себе полезную для юзера работу не выполняет

Давай ещё раз. К чему ты клонишь? Приложение упало и сохранило дамп. Что не так в этом сценарии?

Я на Qt Summit поеду.

Эмбедщина должна работать идеально и без багов! Тщательно протестирована должна быть перед релизом!

Или ты в релиз это не планируешь совать?

Эмбедщина должна работать идеально и без багов! Тщательно протестирована должна быть перед релизом!

Ну да, и всё баги от этого исчезнут.

Все нет, но сегфолты очень желательно до релиза исправлять

Безусловно, но если есть возможность получить stack trace, то почему нет?

Все нет, но сегфолты очень желательно до релиза исправлять

Но ведь это же скучно.

Проблема в том, что breakpad использует depot_tools, это гуглонадстройка на пистоне на гитом.. =)

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

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

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

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

А что принципиально мешало залогиниться на тот сервер и использовать gdb? Если софтинка у хомячка юзера запущена, тогда понятно, ему сложно это всё организовать, лучше автоматизировать, а на сервере какой смысл

какой gdb? на рабочем сервере, где в риалтайме висят миллионы юзеров? ну да. расскажи об этом админам, дежурным и всей техподдержке. и узнаешь, в каком направлении надо двигаться :)

у breakpad есть ещё одно хорошее свойство: у него бинари стрипнутые юзеру поставляются. а файлы с символами остаются у программиста. бинарь не жиреет, дамп очень компактный.

ну core файл тогда

если процесс упал, то миллионы юзеров в реалтайме всё равно уже не висят :)

юзеров сразу перебрасывают на другой сервер, а упавший софт сразу рестартует. но дело не в том. просто редко проявляющиеся ошибки или отладка на серверах, где идёт продакшн, или когда куча юзеров с разными конфигурациями - тогда breakpad удобен. например, мозилла отлаживается именно так.

конечно, пистон надо от него отрезать беспощадно, без него он прекрасно работал, не знаю, занафига его туда впарили. он там не нужен чуть более, чем нигде.

конечно, пистон надо от него отрезать беспощадно, без него он прекрасно работал, не знаю, занафига его туда впарили. он там не нужен чуть более, чем нигде.

Он для сборки только нужен.

ну core файл тогда

Который по размеру равен res mem...

А что принципиально мешало залогиниться на тот сервер и использовать gdb

Таймеры и таймауты, используемы в софте, которые срабатывают при первой остановке в отладчике. Ну это так, к примеру. Короче я до сих пор не пойму, почему ты споришь =)

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

О, а вот об этом не знал, спасибо за наводку, как раз искал эту фичу недавно =)

ещё бывает фигня, когда сервис вроде работает, но как-то странно. начинают копиться сессии или как-то подозрительно он себя ведёт при наблюдении счётчиков. тогда тоже удобно иметь возможность снять дамп. у нас были такие контрольные дампы, которые показывали состояние сервиса, снятые в разное время. это помогало в анализе. потому что когда в софте очень много разных веток, отладить всё становится почти невозможно. смоделировать трафик GSM и LTE тоже никак. поэтому конечная доработка всегда происходит в продакшне.

там просто вешаешь вызов обработчика на любое событие - и вуаля. дамп по любому требованию. иногда очень удобно, чтобы прояснять ситуации, когда софт не упал, а завис или как-то странно себя ведёт и непонятно, что случилось.

раньше точно не был нужен. там плюсы сплошные. я помню, я там руками код правила, чтобы размер стека побольше выставить. он там зашит был в константу. зачем там пистон? он там вообще нигде точно не нужен. на 150%.

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

в общем, влепили туда лишнюю ненужную и очень тяжёлую зависимость. за такое надо руки отрубать.

Смысл не в сборке, а в VCS. Т.е. они используют git, но зависимости прописывают не сабмодулями, а в пистоновском формате. Потом они прогоняют этот пистоновский скрипт и кладут зависимости в нужное место. Я согласен, что это велосипед, и в связи с этим просто положить это в yocto немного проблематично.

Как вариант, конечно, закачать всё и положить в своё локальное зеркало, а потом просто использовать git...

что им мешало этот велосипед написать на перле или ваще на баше? перл есть в лине по умолчанию, на маздай ставится без проблем. работает быстрее и не весит мегатонны.

такие вещи надо сразу под корень вырубать. собсна, я это всё на баше и писала для своих нужд. скрипт пишется за пять минут.

Я не против пистона в данном случае. Скорее я даже против перла и/или баша. Если есть git, то можно было всё сделать средствами git, imho.

Кастану всех причастных... cast Harald, I-Love-Microsoft, Pavval, invy Поругайте:

S = "${WORKDIR}/git/src"
BREAKPAD_DIR = "${WORKDIR}/git"
DEPOT_TOOLS = "${WORKDIR}/depot_tools"

do_fetch() {
    rm -fr ${BREAKPAD_DIR}
    rm -fr ${DEPOT_TOOLS}
    git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git ${DEPOT_TOOLS}
    mkdir -p ${BREAKPAD_DIR}
    cd ${BREAKPAD_DIR}
    export PATH="${DEPOT_TOOLS}:$PATH"
    fetch breakpad
}

Остальное в принципе то же самое, что и в лежащем в master breakpad_svn.bb, разве что SRCREV и SRC_URI там больше нет, ибо руками делаю.

Руг1: разве из git-а не одной строкой можно стянуть? Не расписывая так подробно do_fetch?

Руг1: разве из git-а не одной строкой можно стянуть?

Как бы можно через SRCREV и SRC_URI, но я сливаю depot_tools, а это не совсем breakpad, поэтому я думаю, что это было бы концептуально неправильно. Сам breakpad же сливается в последней строке fetch breakpad.

Вообще это рецепт для внешней сборки. А так я ща зеркало breakpad в локальную репу скопирую и попробую упростить это дело...