Thursday, 11 March 2010
О разнообразии управляющих систем
Выдающийся кибернетик У. Р. Эшби сформулировал фундаментальный закон управления, названный им «принципом необходимого разнообразия» (сегодня часто упоминается под названием «теорема Эшби о необходимом разнообразии»). Закон этот гласит, что разнообразие управляющей системы должно быть не меньше разнообразия управляемого объекта. Другими словами, если объект управления представляет собой сложную систему, то и его управляющая система должна иметь не меньшую сложность (зачастую — бо́льшую).
«Только разнообразие может уничтожить разнообразие».
(c) http://users.livejournal.com/_darkus_/455320.html
Wednesday, 10 March 2010
Господа, а кто какие BPM порекомендует?
Сабж. Для тех, кто не понял аббревиатуру - http://en.wikipedia.org/wiki/Business_process_management
РИТ 2010: Российские Интернет Технологии 12, 13, 14 апреля
Все гоу: http://www.ritconf.ru/ ! До 19 марта цена 12 000 рублей, торопимся урвать подешевле :)
Sun Tech Days 2010 йоу!
Еще инфа: http://www.opennet.ru/openforum/vsluhforumID3/63802.html#3
А вот офсайтко: http://developers.sun.ru/techdays2010/
Кто как, а я за авиабилетами :)
UPDATE:
А вот и программа опубликована: http://developers.sun.ru/techdays2010/agenda-ru
UPDATE:
А вот офсайтко: http://developers.sun.ru/techdays2010/
Кто как, а я за авиабилетами :)
UPDATE:
А вот и программа опубликована: http://developers.sun.ru/techdays2010/agenda-ru
UPDATE:
Большой удачей для российского сообщества разработчиков станет появление в качестве ключевого докладчика в первый день конференции Джеймса Гослинга — автора и ведущего архитектора языка программирования Java.
Tuesday, 9 March 2010
BlueBream
Не совсем понял, что это, но по первым впечатлениями что-то типа Zope light http://bluebream.zope.org/doc/1.0/introduction.html
О концентрации бабла в природе
По данным журнала Forbes суммарное состояние четырнадцати самых богатых граждан России составляет целых 26 % ВВП страны, суммарный капитал тридцати девяти самых богатых американцев не превышает 4,5 % от ВВП США.
стырено с: http://sontar.livejournal.com/97024.html
стырено с: http://sontar.livejournal.com/97024.html
Monday, 8 March 2010
Как найти memory leak в С / С++ приложении? Valgrind!
Ставим:
Создаем файл с намеренным мемликом: memleak.c
Компилруем:
Натравливаем на программу Valgrind:
Ну что же, мемлик успешно найден: definitely lost: 1,000 bytes in 1 blocks.
Теперь попробуем найти источник мемлика:
Теперь более ясно - потери памяти идут в вызове malloc из функции malloc. Но где именно - неясно.
Для того, чтобы узнать строку, на которой идут потери, необходимо собрать программу с отладочной информацией:
Повторно запускаем Valgrind:
И вуаля, утечка памяти на 5й строке нашего файла, как раз там, где мы ее осознанно сделали :)
apt-get install valgrind -y
Создаем файл с намеренным мемликом: memleak.c
#include <stdio.h>
#include <stdlib.h>
int main() {
char* memory_leak = (char*)malloc(1000 * sizeof(char));
return 0;
}
Компилруем:
gcc memleak.c
Натравливаем на программу Valgrind:
valgrind ./a.out
==20343== Memcheck, a memory error detector.
==20343== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==20343== Using LibVEX rev 1854, a library for dynamic binary translation.
==20343== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==20343== Using valgrind-3.3.1-Debian, a dynamic binary instrumentation framework.
==20343== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==20343== For more details, rerun with: -v
==20343==
==20343==
==20343== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 8 from 1)
==20343== malloc/free: in use at exit: 1,000 bytes in 1 blocks.
==20343== malloc/free: 1 allocs, 0 frees, 1,000 bytes allocated.
==20343== For counts of detected errors, rerun with: -v
==20343== searching for pointers to 1 not-freed blocks.
==20343== checked 74,896 bytes.
==20343==
==20343== LEAK SUMMARY:
==20343== definitely lost: 1,000 bytes in 1 blocks.
==20343== possibly lost: 0 bytes in 0 blocks.
==20343== still reachable: 0 bytes in 0 blocks.
==20343== suppressed: 0 bytes in 0 blocks.
==20343== Rerun with --leak-check=full to see details of leaked memory.
Ну что же, мемлик успешно найден: definitely lost: 1,000 bytes in 1 blocks.
Теперь попробуем найти источник мемлика:
valgrind --leak-check=full ./a.out
==21746== Memcheck, a memory error detector.
==21746== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==21746== Using LibVEX rev 1854, a library for dynamic binary translation.
==21746== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==21746== Using valgrind-3.3.1-Debian, a dynamic binary instrumentation framework.
==21746== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==21746== For more details, rerun with: -v
==21746==
==21746==
==21746== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 8 from 1)
==21746== malloc/free: in use at exit: 1,000 bytes in 1 blocks.
==21746== malloc/free: 1 allocs, 0 frees, 1,000 bytes allocated.
==21746== For counts of detected errors, rerun with: -v
==21746== searching for pointers to 1 not-freed blocks.
==21746== checked 74,896 bytes.
==21746==
==21746== 1,000 bytes in 1 blocks are definitely lost in loss record 1 of 1
==21746== at 0x4C2260E: malloc (vg_replace_malloc.c:207)
==21746== by 0x4004DD: main (in /root/a.out)
==21746==
==21746== LEAK SUMMARY:
==21746== definitely lost: 1,000 bytes in 1 blocks.
==21746== possibly lost: 0 bytes in 0 blocks.
==21746== still reachable: 0 bytes in 0 blocks.
==21746== suppressed: 0 bytes in 0 blocks.
Теперь более ясно - потери памяти идут в вызове malloc из функции malloc. Но где именно - неясно.
Для того, чтобы узнать строку, на которой идут потери, необходимо собрать программу с отладочной информацией:
gcc -g memleak.c
Повторно запускаем Valgrind:
valgrind --leak-check=full ./a.out
==22354== Memcheck, a memory error detector.
==22354== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==22354== Using LibVEX rev 1854, a library for dynamic binary translation.
==22354== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==22354== Using valgrind-3.3.1-Debian, a dynamic binary instrumentation framework.
==22354== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==22354== For more details, rerun with: -v
==22354==
==22354==
==22354== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 8 from 1)
==22354== malloc/free: in use at exit: 1,000 bytes in 1 blocks.
==22354== malloc/free: 1 allocs, 0 frees, 1,000 bytes allocated.
==22354== For counts of detected errors, rerun with: -v
==22354== searching for pointers to 1 not-freed blocks.
==22354== checked 74,896 bytes.
==22354==
==22354== 1,000 bytes in 1 blocks are definitely lost in loss record 1 of 1
==22354== at 0x4C2260E: malloc (vg_replace_malloc.c:207)
==22354== by 0x4004DD: main (memleak.c:5)
==22354==
==22354== LEAK SUMMARY:
==22354== definitely lost: 1,000 bytes in 1 blocks.
==22354== possibly lost: 0 bytes in 0 blocks.
==22354== still reachable: 0 bytes in 0 blocks.
==22354== suppressed: 0 bytes in 0 blocks.
И вуаля, утечка памяти на 5й строке нашего файла, как раз там, где мы ее осознанно сделали :)
Как указать путь ко своим .so файлам или "cannot open shared object file: No such file or directory"
Для этого есть переменная среды: LD_LIBRARY_PATH, которая указывает расположение пользовательских динамических библиотек. Также есть способ глобально добавить свою папку в путь поиска посредством ldconfig.
Имеем приложение, слинкованное с нашим кастомным cURL, которого система не видит:
Теперь добавляем свой путь поиска динамических библиотек и все работает нормально:
Запускать софт с кастомным путем до динамических библиотек аналогично:
Имеем приложение, слинкованное с нашим кастомным cURL, которого система не видит:
ldd a.out
libcurl.so.4 => not found
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00002b7bbd9e1000)
libm.so.6 => /lib/libm.so.6 (0x00002b7bbdced000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00002b7bbdf70000)
libc.so.6 => /lib/libc.so.6 (0x00002b7bbe188000)
/lib64/ld-linux-x86-64.so.2 (0x00002b7bbd7c4000)
Теперь добавляем свой путь поиска динамических библиотек и все работает нормально:
LD_LIBRARY_PATH=/opt/curl7_20_0/lib ldd a.out
libcurl.so.4 => /opt/curl7_20_0/lib/libcurl.so.4 (0x00002ac50ca84000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00002ac50ccdd000)
libm.so.6 => /lib/libm.so.6 (0x00002ac50cfe9000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00002ac50d26c000)
libc.so.6 => /lib/libc.so.6 (0x00002ac50d484000)
libssh2.so.1 => /usr/lib/libssh2.so.1 (0x00002ac50d7d7000)
libssl.so.0.9.8 => /usr/lib/libssl.so.0.9.8 (0x00002ac50d9fa000)
libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8 (0x00002ac50dc4c000)
librt.so.1 => /lib/librt.so.1 (0x00002ac50dfe7000)
libz.so.1 => /usr/lib/libz.so.1 (0x00002ac50e1f0000)
/lib64/ld-linux-x86-64.so.2 (0x00002ac50c867000)
libgcrypt.so.11 => /usr/lib/libgcrypt.so.11 (0x00002ac50e408000)
libgpg-error.so.0 => /usr/lib/libgpg-error.so.0 (0x00002ac50e66f000)
libnsl.so.1 => /lib/libnsl.so.1 (0x00002ac50e772000)
libdl.so.2 => /lib/libdl.so.2 (0x00002ac50e98b000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00002ac50eb8f000)
Запускать софт с кастомным путем до динамических библиотек аналогично:
LD_LIBRARY_PATH=/opt/curl7_20_0/lib ./a.out
Как добавить папку в путь поиск .so файлов для gcc/g++
Вот так, посредством ключа -L:
g++ test_curl.cpp -I /opt/curl7_20_0/include -L/opt/curl7_20_0/lib -lcurl
Subscribe to:
Posts
(
Atom
)

