> Я тут (и не только) несколько раз пытался пиарить свои и не только поделки. > И пару раз меня останавливали словами "Товарищ, вот вы тут пиаретесь, а > где же ваш репозиторий? 21-й век на дворе, мы че, собирать руками будем? ;-) " > Это не цитата, то мое прочтение, конечно :-).
> В общем, сделал я репозиторий для Debian/lenny/i386. Для других > архитектур и дистрибутивов можно собрать самому, у меня нет возможности > и времени собирать подо все, что движется. На etch точно собирается и > работает. Как я говорил, я не большой поклонник пакетной системы Debian, > поэтому не особенно большой в ней специалист. Так что если найдутся > ошибки в самих пакетах, милости просим, пишите багрепорты. Поливать > грязью тоже можно, если найдется за что, только желательно по делу ;-) > В sources.list нужно прописать такие строки > deb http://mova.org/~cheusov/pub/debian lenny main > deb-src http://mova.org/~cheusov/pub/debian lenny main > NOTE: именно lenny, а не stable. У меня время бежит по-своему. > Программы такие: Добавил в репозиторий еще одну свою погремушку. Package: lmdbg Version: 0.13.0-1 Architecture: i386 Maintainer: Aleksey Cheusov <v...@gmx.net> Size: 34468 Description: Lightweight malloc(3) debugger LMDBG is a collection of small tools for collecting and analyzing the logs of malloc/realloc/memalign/free function calls. Unlike many others, LMDBG does not provide any way to detect overruns of the boundaries of malloc() memory allocations, as this is not the goal. Like most other malloc debuggers, LMDBG allows detecting memory leaks and double frees. However, unlike others, LMDBG generates full stacktraces and separates the logging process from analysis, thus allowing you to analyze an application on a per-module basis. Если вооружиться разнообразными обвязками по анализу логов, можно использовать и для анализа узких мест в программе, например мест, где память выделяется слишком часто. В общем, UNIX way есть UNIX way. Собирается с помощью mk-configure. Кстати, хороший пример того, как можно кратко и понятно писать без autotools переносимый код, в этом проекте есть завязки на ОС и прочие вещи. Так что заодно с отладчиком этот проект еще и proof of concept для mk-configure. Чтобы быстро решить, стоит ли смотреть, скопирую README сюда. ==================================================================== DOCUMENTATION/TUTORIAL - Unlike many other malloc debuggers (electric-fence, dmalloc, valgrind etc.) LMDBG does *NOT* protect your memory in any way. It is just not a goal of LMDBG. - lmdbg-run is a main lmdbg utility. It runs an application and creates a log file (or fifo) where all called malloc/calloc/realloc/free/memalign/posix_memalign invocations are registered with their input (bytes count, pointer), output (pointer) and *FULL STACKTRACE* (pointers). Example: $ cat tests/test2.c #include <stdlib.h> int main () { void *p1 = NULL; void *p2 = NULL; p1 = malloc (555); p2 = realloc (p2, 666); p2 = realloc (p2, 777); p2 = realloc (p2, 888); return 0; } $ gcc -O0 -g -o _test2 tests/test2.c $ lmdbg-run -o _log ./_test2 $ cat _log malloc ( 555 ) --> 0xbb901400 0xbbbe58e8 0xbbbe5b03 0x8048738 0x8048584 0x80484e7 realloc ( NULL , 666 ) --> 0xbb901800 0xbbbe58e8 0xbbbe5a37 0x804874e 0x8048584 0x80484e7 realloc ( 0xbb901800 , 777 ) --> 0xbb901c00 0xbbbe58e8 0xbbbe5a37 0x8048764 0x8048584 0x80484e7 realloc ( 0xbb901c00 , 888 ) --> 0xbb901800 0xbbbe58e8 0xbbbe5a37 0x804877a 0x8048584 0x80484e7 $ NOTE: Full stacktrace allows you to analyse your application, i.e. you can detect what blocks/components require more memory than others and why. lmdbg-sym is a very important tool for this, see below. - lmdbg-leaks analyses a log file generated by lmdbg-run and output all found memory leaks Example: $ lmdbg-leaks _log realloc ( 0xbb901c00 , 888 ) --> 0xbb901800 0xbbbe58e8 0xbbbe5a37 0x804877a 0x8048584 0x80484e7 malloc ( 555 ) --> 0xbb901400 0xbbbe58e8 0xbbbe5b03 0x8048738 0x8048584 0x80484e7 $ - lmdbg-sym converts addresses to source.c:999 if it is possible Example (gdb(1) is in action): $ lmdbg-sym ./_test2 _log malloc ( 555 ) --> 0xbb901400 0xbbbe58e8 0xbbbe5b03 0x8048738 tests/test2.c:8 main 0x8048584 0x80484e7 realloc ( NULL , 666 ) --> 0xbb901800 0xbbbe58e8 0xbbbe5a37 0x804874e tests/test2.c:9 main 0x8048584 0x80484e7 realloc ( 0xbb901800 , 777 ) --> 0xbb901c00 0xbbbe58e8 0xbbbe5a37 0x8048764 tests/test2.c:10 main 0x8048584 0x80484e7 realloc ( 0xbb901c00 , 888 ) --> 0xbb901800 0xbbbe58e8 0xbbbe5a37 0x804877a tests/test2.c:11 main 0x8048584 0x80484e7 $ Example (addr2line(1) works here): $ lmdbg-sym -a ./_test2 _log malloc ( 555 ) --> 0xbb901400 0xbbbe58e8 0xbbbe5b03 0x8048738 tests/test2.c:8 0x8048584 0x80484e7 realloc ( NULL , 666 ) --> 0xbb901800 0xbbbe58e8 0xbbbe5a37 0x804874e tests/test2.c:9 0x8048584 0x80484e7 realloc ( 0xbb901800 , 777 ) --> 0xbb901c00 0xbbbe58e8 0xbbbe5a37 0x8048764 tests/test2.c:10 0x8048584 0x80484e7 realloc ( 0xbb901c00 , 888 ) --> 0xbb901800 0xbbbe58e8 0xbbbe5a37 0x804877a tests/test2.c:11 0x8048584 0x80484e7 $ - lmdbg-sysleaks - greps or skips system memory leaks found in libc, libdl, C++ stl etc. See tests/lmdbg*.conf files. The default config files are: ~/.lmdbg.conf and /etc/lmdbg.conf - lmdbg = lmdbg-run + lmdbg-leaks + lmdbg-sym + lmdbg-sysleaks That is lmdbg is all-in-one higher level tool. Example: $ lmdbg -v -o _log ./_test2 Memory leaks were detected and saved to file '_log' $ cat _log realloc ( 0xbb901c00 , 888 ) --> 0xbb901800 0xbbbe58e8 0xbbbe5a37 0x804877a tests/test2.c:11 main 0x8048584 0x80484e7 malloc ( 555 ) --> 0xbb901400 0xbbbe58e8 0xbbbe5b03 0x8048738 tests/test2.c:8 main 0x8048584 0x80484e7 $ ==================================================================== QUICK GUIDE lmdbg-run --help lmdbg-leaks --help lmdbg-sym --help lmdbg --help Sample of usage: u...@host$ lmdbg-run -o /tmp/PROG.log PROG ARG1 ARG2 ... ARGN u...@host$ lmdbg-leak < /tmp/PROG.log > /tmp/PROG.log2 u...@host$ lmdbg-sym PROG \ < /tmp/PROG.log2 > /tmp/PROG_LEAKS_SRC.log3 ==================================================================== LICENSE: MIT ==================================================================== ACKNOWLEDGEMENTS Idea to use full stacktraces was stolen from YAMD by Nate Eldredge Idea to use gdb(1) for resolving symbols was stolen from ccmalloc by Armin Biere stacktrace(3) API is compatible with glibc's backtrace(3) -- Best regards, Aleksey Cheusov. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87tys9zu2k....@asrock.chizhovka.net