Re: Мои п[р]оделки в виде Debian репозитория
> Я тут (и не только) несколько раз пытался пиарить свои и не только поделки.
> И пару раз меня останавливали словами "Товарищ, вот вы тут пиаретесь, а
> где же ваш репозиторий? 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 <vle@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:
user@host$ lmdbg-run -o /tmp/PROG.log PROG ARG1 ARG2 ... ARGN
user@host$ lmdbg-leak < /tmp/PROG.log > /tmp/PROG.log2
user@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.
Reply to: