[arm][C] Отлов утечек памяти.

valgrind же

Под arm же...
http://valgrind.org/info/platforms.html
я так понял, что arm у них только в планах..

В порядке бреда: пустить под отладчиком, поставить брякпойнты на *alloc и free, снимать стековый след и адреса размещенных блоков (это скриптуется в gdb). После завершения программы проанализировать, какие блоки не освобождены и в каких местах программы они были размещены.

Не сказал сразу... приложение крутится на embedded. Там места маловато. Хотелось бы что-нибудь полегковеснее, чем gdb. Сколько бинарник gdb будет весить - не в курсе?

> риложение крутится на embedded. Там места маловато.

Тогда только wetware emulation ;)

Сколько бинарник gdb будет весить - не в курсе?

Я с ARM не работаю.

> Тогда только wetware emulation ;)
С помощью гугла я, кажется, понял шутку :)

Если ничего не найду, похоже придётся самому писать простенькую либу.

> Если ничего не найду, похоже придётся самому писать простенькую либу.

У тебя настолько мелкая система, что в нее даже gdbserver не влезает?

Может dmalloc ?

> У тебя настолько мелкая система, что в нее даже gdbserver не влезает?

Не знаю - не пользовал gdbserver ни разу. Возможно стоит попробовать.

> Может dmalloc ?
Во, похоже подойдёт - буду смотреть.

напейши свой аллокатор!

Если в устройстве есть сетевой интерфейс, можно положить корень на nfs. Тогда места для gdb точно хватит. Иначе, можно написать врапперы для *alloc и free.

>Если ничего не найду, похоже придётся самому писать простенькую либу.

Как же вы ищите ? duma, mtrace, и потом зачем отлаживать на реальном железе юзерспейс, qemu для чего придумали ?

> и потом зачем отлаживать на реальном железе юзерспейс , qemu для чего придумали ?

Часто юзерспейс взаимодействует с внешним миром, который не эмулируется на qemu.

Неужели для подобных приложений нет тестового окружения, которое работает на x86, и в котором его можно запустить под валгриндом, эмулируя ввод-вывод (или используя реальный через какие-нибудь адаптеры)?

>Часто юзерспейс взаимодействует с внешним миром, который не эмулируется на qemu.

Я конечно понимаю что вероятность имеется, но чтобы _часто_ ?? Хоть один пример можно привести ?

> Хоть один пример можно привести ?

Из последнего: наплатный считыватель сматркарт (работает через userspace-драйвер поверх libusb), дерганье gpio из юзерспейса для включения-выключения некоторой переферии, отладка гуя на маленьком дисплее, который тоже на плате стоит, отладка программы для dsp, который тоже на плате. И т.д.

>>Часто юзерспейс взаимодействует с внешним миром, который не эмулируется на qemu.

Я конечно понимаю что вероятность имеется, но чтобы _часто_ ?

А это разве не _всегда_ так?

>работает через userspace-драйвер поверх libusb

usb есть на любой системе - абсолютно не привязано к железу.

дерганье gpio из юзерспейса для включения-выключения некоторой переферии

это 2 строчки кода через mmap регистров - если на таком коде у тебя память течет - это хреново пахнет :)

отладка гуя на маленьком дисплее

хз - тут тоже непонятно - интерфейс дисплея какой ? если подключение как sram и фрэймбуфер, никаких проблем с этим нет, фреймбуфер на любой системе одинаково работает

отладка программы для dsp, который тоже на плате.

подозреваю это к юзерспейсу никакого отношения имеет.

В каком смысле _всегда_ так ? Твой юзерспейс всегда напрямую работает с железом а не через интерфейс ядра ?

> Твой юзерспейс всегда напрямую работает с железом а не через интерфейс ядра ?

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

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

Я не совсем понял - у тебя система прямо на этом сложнейшем железе стоит или оно подключено по какой-то шине к процессорному блоку ? А то я подозреваю ты свое сложнейшее железо сейчас только придумал :)

> система прямо на этом сложнейшем железе стоит или оно подключено по какой-то шине к процессорному блоку ?

Как звучит настоящий вопрос?

А то я подозреваю ты свое сложнейшее железо сейчас только придумал :)

Ты вообще много глупостей подозреваешь.

>Как звучит настоящий вопрос?

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

> В подавляющем большинстве случаев достаточно эмулятора.

Значит, мне не везет.

На эмуляторе сложно эмулировать периферию

Вот именно. То, что я пишу, как раз сильно завязано на периферию. И написать эмулятор этой периферии можно, но профит сомнителен.

>То, что я пишу, как раз сильно завязано на периферию.

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

> Если этим «что-то» ты управляешь из юзерспейс - даю 100% гарантию что ничего сложного там быть не может

O_O

даже в ядре ты тайминги строго не выдержишь

Зависит от того, что называть «строго».

и к тому же ты вполне там справляешься без аппаратных прерываний ?

А это ты с чего взял? O_O Ну да не важно, ты и здесь не прав.

>Зависит от того, что называть «строго».

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

А это ты с чего взял? O_O Ну да не важно, ты и здесь не прав.

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

> Ты это в юзерспейсе сделаешь ?

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

Хватит бредить.

Вообще то бредишь ты, утверждая что для отладки прикладного ПО _всегда_ нужно именно то железо на котором будет работать это ПО. Ты хотя хотя бы на минуту задумайся чего ты несешь ?

> Вообще то бредишь ты, утверждая что для отладки прикладного ПО _всегда_ нужно именно то железо на котором будет работать это ПО.

Ты это выдумал.

ПНХ

> ПНХ

Достойное завершение дискуссии :)

> usb есть на любой системе - абсолютно не привязано к железу.

Конечно есть, только картридера такого нет. Или предлагаешь купить контроллер и спаять?

это 2 строчки кода через mmap

регистров - если на таком коде у тебя память течет - это хреново пахнет :)

У меня лично не течет, но это не значит, что такого невозможно в принципе. И это вовсе не всегда «2 строчки кода через mmap регистров».

хз - тут тоже непонятно -

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

Не важно какой интерфейс, важно то, что после отладки на commom-фреймбуфере ты потратишь еще половину времени (если не столько-же), на отладку на родном дисплее.

подозреваю это к юзерспейсу

никакого отношения имеет .

Твои подозрения беспочвенны.

PS: если есть возможность работать непосредственно на железе, то так и надо делать, даже имея симулятор. Поверь, времни на разработку потратишь в разы меньше.

Грузи embedded по nfs, тогда проблем с местом не будет.

>Конечно есть, только картридера такого нет.

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

И это вовсе не всегда «2 строчки кода через mmap регистров».

fd = open(«/dev/mem», O_RDWR | O_SYNC); base = mmap(0, MAP_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, addr & ~MAP_MASK);

важно то, что после отладки на commom-фреймбуфере ты потратишь еще половину времени (если не столько-же), на отладку на родном дисплее.

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

> Ты уж определись - есть он у тебя или нет

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

fd = open(«/dev/mem»,....

А как же расширители gpio, которые на i2c или spi (или еще чего похуже)? Тоже две строчки? Да и дело-то не в том, что дергать, а в том как дергать (и что ждать от дерганья). Отлаживается не дерганье, а логика этого дерганья. При чем тут две строчки-то?

это так и не понял - чем отличаются фреймбуферы одних и тех же режимов

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

Ты мне лучше скажи, в чем преимущество работы на эмуляторе, если есть возможность работать на железе? А то мне так кажется, что тебе пофиг, лишь бы потроллить.

>Ты мне лучше скажи, в чем преимущество работы на эмуляторе, если есть возможность работать на железе?

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

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

Троллишь как раз ты с гарри потером (таиганером) о невъебенно хитром железе котрым вы управляете в юзерспейс.

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

Ошибаетесь, уважаемый. Топикстартер сказал, что «приложение крутится на embedded. Там места маловато. Хотелось бы что-нибудь полегковеснее, чем gdb.». Другими словами, работать не «невозможно», а просто затруднительно, ввиду маловатости места. Потому я ему и предложил завести корень на nfs, если есть сетевой интерфейс.

Ну да ладно, чего зря языком трепать? человек получил ответ на свой вопрос, думаю обсасывать больше нечего. Не будем уподоБЛЯтья...