голый gdb и плюсы

каким таким? гдб работает на любой программе

Совсем не понял, что значит «голый gdb» и какие должны быть приёмы. Компилирую g++ -g ..., после, при необходимости, отладка в gdb. Всё работает как должно.

Первым делом берешь и ставишь pretty printer для C++ std::*. Его можно взять, например, из QtCreator. Как прикручивать - легко гуглится.

layout src очень помогает. А вообще предпочитаю не использовать отладчик. Имхо, проще assert и отладочная печать. А gdb — максимум, backtrace в корке посмотреть.

А вообще предпочитаю не использовать отладчик. Имхо, проще assert и отладочная печать.

Это все замечательно для кода, который не слишком длинный и который ты сам писал.

Обычно использую морду типа qtcreator'оа или nemiver'a и дополняю коммаендной строкой для анализа, типа «p someObj.someMethod()» и т.п.

Приём один - gdb <path to binary>, run, bt full. В 90% этого достаточно, в оставшихся 10% нужно ещё пару переменных посмотреть. Больше ни за чем отладчик не нужен, ни для своего, ни для чужого кода.

А где изврат?

break, watch, continue, step и всё такое.

Интересно, как милорд планирует дебажиться не у себя на рабочей тачке.

Pretty printers - поставил официальные, gdb'шные.

Я хочу автоматизации.

Например, есть корка, в ней есть десять очередей. В каждой очереди n обьектов разных типов, с разными родителями (или не с разными).

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

Хочется уметь это делать легко и непринуждённо.

А иначе действительно, непонятно, зачем нужен гольный gdb.

Для дебага не у себя на рабочей тачке бог придумал gdbserver.

А я хочу дополнительных плюшек по сравнению с gui.

Очень спорный вопрос. Бывают сложные системы со сложным состоянием.

Пока ты компилируешь g++ -g скорее всего твоя система слишком проста что бы вообще её отлаживать надо было :)

Есть кто-то занимающийся таким извратом?

Обычно оно проще и внятнее чем «gdb интегрированный в $IDE_NAME» :) В $IDE_NAMEах gdb может молча и внезапно умереть :)

Поделитесь списком основных приёмов.

bt по крэшдампу :)

bt наше всё, спору нет. Однако, иногда хочеться обозреть картинку, да ещё и погрепать её :)

Ну это обычно происходит, когда бестолковый крэшдамп на 500 Мб — и надо немного ограничить размер картинки :)

Это обычно происходит, когда ковыряешься в чьей то масштабной поделке с метапрограммированием, type erasure и потоками.

Pretty printers - поставил официальные, gdb'шные.

Если это то, что я думаю, то оно старое и не умеет в С++11.

У меня старый кодебейз, он тоже не умеет в c++11 :)

Меня более интересует наличие более продвинутых либ, для автоматизации задач отладки.

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

Для дебага не у себя на рабочей тачке бог придумал gdbserver.

... к которому подключаются через ... ?

А я хочу дополнительных плюшек по сравнению с gui.

Это врядли, нужно рассматривать конкретный фронтенд.

Через gdb или любой вменяемый фронтэнд. Возможно я просто не понял суть твоего предыдущего высказывания.

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

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

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

Аля пройтись по всем потокам, посмотреть на имя потока, прыгнуть в нужный фрейм, распечатать состояние

это все умеет gdb ручками, пару команд

Кому то не нужна. Мне нужна.

а чтение и понимание всех сорсов надо начинать до компиляции

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

Я, всё нормально работает

В терминах того про что gdb знает - несомненно. threads apply all и всё такое, а вот применить тут действия по условию типа в этом потоке в фрейме 5 печатаем одну фигну а в том во фрейме 2 другую.

а вот применить тут действия по условию типа в этом потоке в фрейме 5 печатаем одну фигну а в том во фрейме 2 другую.

Я думаю, что всё это и больше можно сделать через Guile или Python API.

Как оно?

Нормально. Недавно нашёл как не заходить в inline функции стандартной библиотеки по step (тут внизу).

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

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

threads apply all и всё такое, а вот применить тут действия по условию типа в этом потоке в фрейме 5 печатаем одну фигну а в том во фрейме 2 другую.

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

Лол, звучит как повод выучить лиспик таки. emacs меня в своё время не сподвиг в силу своей кроссплатформы.

В чем разница между guile и python api?

Мне первый раз потребовалось. Ну, или скорее захотелось.

У меня условие не для стейта в памяти, а для номера потока.

Просто хочется в n временных точек распечатать картину мира с теми деталями которые нужны для осознания что пошло не так.

Не влияло бы сброс дампа в ручную во время выполнения (читай лог) на картину, вопроса бы не возникало.

Ну, то что ты ужасно крут и обозреваешь такие вещи во всех деталях(в которых дьявол кроется) одним взором это я уже понял :)

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

В чем разница между guile и python api?

У них написано:

Guile support in gdb follows the Python support in gdb reasonably closely, so concepts there should carry over. However, some things are done differently where it makes sense.

Так что особой разницы по функциональности быть не должно, просто Guile это официальный язык расширения для GNU-проектов, а Python более популярен, видимо, поэтому и два интерфейса.

а если код чужой?

Оно примерно как работа в обычной консольке, только хуже (слишком тупые автокомплит и повторение последней команды по вводу) но есть ещё всякие плюшки в виде pretty printer-ов и возможности писать скрипты на питоне. В большинстве обхожусь коробочным вариантом и на случаи копания в адских корках за годы накодил себе небольшой инструментик автоматизации этого процесса на питоне.

просто Guile это официальный язык расширения для GNU-проектов

Интересный факт, не знал, спасибо :)

Это обычно происходит, когда чью-то масштабную поделку жадные манагеры отдали на сапорт пионерам... А кто-то из их руководятлов вспомнил, что ты немного помогал автору поделки, который уже где-то делся по тихой грусти, а пионеры отломили все, что не поняли, как работает (типа автособиралки зависимостей созданой беглым пахарем с галеры в качестве дембельского аккорда, из-за чего специальный землекоп занят очень важным делом — понять как собирать это чудо), и рванулись чинить вообще ни разу не сломаное, допуская «интересные косяки» типа внезапного выделения памяти на пол-гига (и в замапленый файл тоже внезапно валится пол-гига... нулей :))

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

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

У меня пока что нет задачи разобраться почему оно не работает(это обычно в разы проще), есть задача разобраться, почему, иногда, при определённом стечении обстоятельств оно работает не так хорошо как могло бы :)

А чего есть в инстументе? И есть ли оно в открытом виде?

Мне собственно и хотелось потырить идеи, кто, что и как автоматизирует.

уровень размера сыцов линукс ядра или куте фреймворка это много? по моему средне

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

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

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

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

кстати, есть офигенное средство для анализа всякой такой шняги. правда, код закрытый и оно небесплатное. но нарыть старые версии, которые раньше были бесплатны для опенсорца, в сети, наверное, можно. Intel Parallel Studio. там есть очень детальные и очень графически наглядные профайлеры, всякие анализаторы кода, отладчик (правда, под icc, но обычно это проблем не вызывает, он с gcc практически на 100% совместим по параметрам). вещь хорошая. в принципе, стоит не так уж дорого для частного использования, если очень нужно.

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

Тыкать в каждый элемент n-сотенной хотя бы очереди, довольно таки не удобно.

Снятие дампа с помощью кода во время работы, довольно занимательное занятие, и с 90% вероятностью нивелирует конкретно это проблему и, скорее всего испортит картинку. А вот то что снимается gcore, подозрительно похоже на правду.

Хочется просто иметь возможность такие дампы красиво распечатывать написав минимум кода.

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

снять стектрейс недолго. это не разрушит работу. а зачем дампы печатать? (пардон, вдруг вспомнился случай на огромной машине Hitachi, которая стояла в одном ВЦ. кто-то сдуру нажал вывод дампа на принтер. и принтер за несколько часов усиленной печати наполнил огромный машинный зал бумагой с этим дампом :) бумага была в таких складчатых стопках, с перфорацией по краям, но когда на неё печатали, она из принтера вылезала как попало. я зашла в машинный зал и увидела там бумагу до потолка).

с очередями, обычно разрушает их нормальную работу.

проблема проявляется довольно длительный момент времени.

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

Есть мнение, что при определённом стечении обстоятельств, имеет место быть ситуация, когда поток данных таков, что один или несколько родителей заблокированны на запись статистически в те моменты, когда на подходе свежие детки в большом числе, и соответсвенно, не могут получать детей. А к тому моменту, как очередь переходит к следующему родителю, его тоже ожидает множество детей, а он заблокирован. Дети живут в одной из очередей, и, если не удалось подцепить дитя к родителю, перекладываются в хвост. Соответсвенно, когда ситуация повторяется n раз за момент времени, очередь начинает расти. Чем больше очередь, тем больше шанс нарваться на заблокированного родителя и потратить время на переброс в хвост. А т.к. порядок не меняется, сиё действо заходит в цикл. По одному два элемента конечно убирается но подавляющее большинство просто постоянно тасуется с головы в хвост.

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

а зачем дампы печатать

Случай про машину улыбнул :) Но я говорил про печать в стандартный выход, с целью сделать grep | sort | uniq.

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

Про инструмент слышу впервые. Спасибо, потыкаю :)

Я так понимаю он использует strace в каком то виде? Возможно интрузивные варианты тут скорее всего будут полезнее, хотя по сути разница на вызов функции.

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