У меня возникла проблема при программировании на C++.
Я пишу серверное приложение-демон. Оно имеет многопотоковую
клиент-серверную архитектуру и реализовано с помощью posix-нитей. В
главном цикле слушается сокет, и при новом поступлении запроса выделяется
память под элемент класса, в котором запускается нить, обслуживающая
запрос.
А также в приложении используется динамическая библиотека ( *.so ),
подгружаемая с помощью функции dlopen(). ( Мне кажется, что для решения
проблемы это важно учесть ).Создавал я приложение под Linux SUSE 10.0. uname -a:
Linux linux 2.6.13-15-default #1 Tue Sep 13 14:56:15 UTC 2005 i686 i686
i386 GNU/LinuxВерсия компилятора. g++ -v:
Using built-in specs.
Target: i586-suse-linux
Configured with: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib
--enable-languages=c,c++,objc,f95,java,ada --disable-checking
--with-gxx-include-dir=/usr/include/c++/4.0.2 --enable-java-awt=gtk
--disable-libjava-multilib --with-slibdir=/lib --with-system-zlib
--enable-shared --enable-__cxa_atexit --without-system-libunwind
--host=i586-suse-linux
Thread model: posix
gcc version 4.0.2 20050901 (prerelease) (SUSE Linux)
Компиляция проходит успешно, и приложение работает.
Теперь же мне нужно перенести код на FreeBSD. uname -a:
FreeBSD sj2d59.svwh.net 4.10-RELEASE FreeBSD 4.10-RELEASE #1: Thu Sep 23
06:40:05 PDT 2004 admin@sj2d59.svwh.net:/usr/src/sys/compile/J i386Компилятор. g++ -v:
Using builtin specs.
gcc version 2.95.4 20020320 [FreeBSD]
Теперь при компиляции возникла ошибка: неизвестный ключ -ldl
Он был необходим для работы функций dlopen и так далее.
Этот ключ я убрал, и компиляция прошла успешно.Теперь сама суть проблемы:
В программе стал появляться сигнал SIGBUS. Он возникает в конструкторе
класса, обслуживающего нить. Проверял отладчиком. Процесс заходит в
конструктор без ошибок. И на первом же присваивании приватному полю Status
значения STATUS_INIT, процесс получает сигнал SIGBUS. Программа аварийно
завершается.
Я не могу понять в чем тут ошибка. В Linux SUSE всё работало, и подобных
сигналов не возникало.Вот участок отладки программы:
Breakpoint 1, addThread () at phpDaemon.cpp:437
437 Thread = new DaemonThread ( ServerSocket );
(gdb) step
DaemonThread::DaemonThread (this=0x80d2000, ServerSocket=6) at
phpDaemon.cpp:163
163 DaemonThread::DaemonThread ( int ServerSocket ){
(gdb) step
166 Status = STATUS_INIT;
(gdb) stepProgram received signal SIGBUS, Bus error.
DaemonThread::DaemonThread (this=0x80d2000, ServerSocket=6) at
phpDaemon.cpp:166
166 Status = STATUS_INIT;
(gdb)
/*======================================*/Пояснения:
#define STATUS_INIT 1
class DaemonThread{
private:
int Status;
...
};В чем здесь ошибка? Помогите, пожалуйста, решить проблему.
>У меня возникла проблема при программировании на C++.
>Я пишу серверное приложение-демон. Оно имеет многопотоковую
>клиент-серверную архитектуру и реализовано с помощью posix-нитей. В
>главном цикле слушается сокет, и при новом поступлении запроса выделяется
>память под элемент класса, в котором запускается нить, обслуживающая
>запрос.
>А также в приложении используется динамическая библиотека ( *.so ),
>подгружаемая с помощью функции dlopen(). ( Мне кажется, что для решения
>
>проблемы это важно учесть ).
>
>Создавал я приложение под Linux SUSE 10.0. uname -a:
>Linux linux 2.6.13-15-default #1 Tue Sep 13 14:56:15 UTC 2005 i686 i686
>
>i386 GNU/Linux
>
>Версия компилятора. g++ -v:
>Using built-in specs.
>Target: i586-suse-linux
>Configured with: ../configure --enable-threads=posix --prefix=/usr
>--with-local-prefix=/usr/local --infodir=/usr/share/info
>--mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib
>--enable-languages=c,c++,objc,f95,java,ada --disable-checking
>--with-gxx-include-dir=/usr/include/c++/4.0.2 --enable-java-awt=gtk
>--disable-libjava-multilib --with-slibdir=/lib --with-system-zlib
>--enable-shared --enable-__cxa_atexit --without-system-libunwind
>--host=i586-suse-linux
>Thread model: posix
>gcc version 4.0.2 20050901 (prerelease) (SUSE Linux)
>
>
>Компиляция проходит успешно, и приложение работает.
>
>
>Теперь же мне нужно перенести код на FreeBSD. uname -a:
>FreeBSD sj2d59.svwh.net 4.10-RELEASE FreeBSD 4.10-RELEASE #1: Thu Sep 23
>06:40:05 PDT 2004 admin@sj2d59.svwh.net:/usr/src/sys/compile/J i386
>
>Компилятор. g++ -v:
>Using builtin specs.
>gcc version 2.95.4 20020320 [FreeBSD]
>
>
>Теперь при компиляции возникла ошибка: неизвестный ключ -ldl
>Он был необходим для работы функций dlopen и так далее.
>Этот ключ я убрал, и компиляция прошла успешно.Здесь это не существенно. dl входит в libc.
>Теперь сама суть проблемы:
>В программе стал появляться сигнал SIGBUS. Он возникает в конструкторе
>класса, обслуживающего нить. Проверял отладчиком. Процесс заходит в
>конструктор без ошибок. И на первом же присваивании приватному полю Status
>значения STATUS_INIT, процесс получает сигнал SIGBUS. Программа аварийно
>завершается.В тех скудных случаях, в которых мне доводилось нарываться на SIGBUS - это была неверная работа приложения с динамической памятью. Обычно именно этим страдают программы переносимые с Linux'a и имеющие неверную логику работы с heap.
>Здесь это не существенно. dl входит в libc.Хорошо. Значит, проблема не тут.
>
>>Теперь сама суть проблемы:
>>В программе стал появляться сигнал SIGBUS. Он возникает в конструкторе
>>класса, обслуживающего нить. Проверял отладчиком. Процесс заходит в
>>конструктор без ошибок. И на первом же присваивании приватному полю Status
>>значения STATUS_INIT, процесс получает сигнал SIGBUS. Программа аварийно
>>завершается.
>
>В тех скудных случаях, в которых мне доводилось нарываться на SIGBUS -
>это была неверная работа приложения с динамической памятью. Обычно именно этим
>страдают программы переносимые с Linux'a и имеющие неверную логику работы с
>heap.
Так а есть какой-нибудь конкретный совет есть?Код-то на Linux был рабочий.
...
DaemonThread *Thread;
Thread = ( DaemonThread * ) new DaemonThread ( ServerSocket );
...Вроде бы ничего подозрительного: выделение памяти под новый объект класса.
Куда копать?
>>Здесь это не существенно. dl входит в libc.
>
>Хорошо. Значит, проблема не тут.
>
>>
>>>Теперь сама суть проблемы:
>>>В программе стал появляться сигнал SIGBUS. Он возникает в конструкторе
>>>класса, обслуживающего нить. Проверял отладчиком. Процесс заходит в
>>>конструктор без ошибок. И на первом же присваивании приватному полю Status
>>>значения STATUS_INIT, процесс получает сигнал SIGBUS. Программа аварийно
>>>завершается.
>>
>>В тех скудных случаях, в которых мне доводилось нарываться на SIGBUS -
>>это была неверная работа приложения с динамической памятью. Обычно именно этим
>>страдают программы переносимые с Linux'a и имеющие неверную логику работы с
>>heap.
>Так а есть какой-нибудь конкретный совет есть?
>
>Код-то на Linux был рабочий.
>...
>DaemonThread *Thread;
>Thread = ( DaemonThread * ) new DaemonThread ( ServerSocket );
>...
>
>Вроде бы ничего подозрительного: выделение памяти под новый объект класса.
>Куда копать?У меня такая же проблема =)).
Это кривой БСД!!На линухе норм, на БСД 5.4, 6.1 - норм, а вот на 4.7 - вываливается.
Что ни пробовал.
Вываливается и все.У меня не было времени заниматься этой проблемой очень приближенно - я попросил начальство, чтоб они обновили ОС, но можете попробовать обновить glibc.
>Это кривой БСД!!Обосновать сможешь? Или первым на запись в ряды пустознонов?
>У меня не было времени заниматься этой проблемой очень приближенно - я
>попросил начальство, чтоб они обновили ОС, но можете попробовать обновить glibc.glibc есть только в GNU/Linux. В FreeBSD libc.
>
>>Это кривой БСД!!
>
>Обосновать сможешь? Или первым на запись в ряды пустознонов?
>
>>У меня не было времени заниматься этой проблемой очень приближенно - я
>>попросил начальство, чтоб они обновили ОС, но можете попробовать обновить glibc.
>
>glibc есть только в GNU/Linux. В FreeBSD libc.>>Обосновать сможешь? Или первым на запись в ряды пустознонов?
Да. При создании нити(потока) бьется стек/динамическая область и последующие операции с памятью могут вызывать проблемы.
Но это не всегда - как повезет, раз запустишь - норм, второй раз - вылетает.Эта проблема наюлбдается с библиотеками lthread, c_r. С thr - все норм, но она присутсвует с 5й версии ОС.
>>glibc есть только в GNU/Linux. В FreeBSD libc.
Им-то(FreeBSD) хуже =).
>>
>>>Это кривой БСД!!
>>
>>Обосновать сможешь? Или первым на запись в ряды пустознонов?
>>
>>>У меня не было времени заниматься этой проблемой очень приближенно - я
>>>попросил начальство, чтоб они обновили ОС, но можете попробовать обновить glibc.Пересобрал компилятор.
Using built-in specs.
Target: i386-portbld-freebsd4.10
Configured with: ./..//gcc-4.2-20060923/configure --disable-libgomp --disable-nls --with-system-zlib --with-libiconv-prefix=/usr/local --program-suffix=42 --libdir=/usr/local/lib/gcc-4.2.0 --with-gxx-include-dir=/usr/local/lib/gcc-4.2.0/include/c++/ --infodir=/usr/local/info/gcc42 --disable-rpath --prefix=/usr/local i386-portbld-freebsd4.10
Thread model: posix
gcc version 4.2.0 20060923 (experimental)
Теперь пишу не g++ ... а gcc.добавил ключ -lstdc++
Заработало.
Теперь же такая проблема:
terminate called after throwing an instance of 'std::bad_alloc'
what(): St9bad_alloc
Где и почему возникает?
У меня выделяется память под новый объект класса путем new, а под элемент списка - malloc.
Видимо в new проблема. Почему? Как лечить?
>>glibc есть только в GNU/Linux. В FreeBSD libc.
>
>>>Обосновать сможешь? Или первым на запись в ряды пустознонов?
>Да. При создании нити(потока) бьется стек/динамическая область и последующие операции с памятью
>могут вызывать проблемы.
>Но это не всегда - как повезет, раз запустишь - норм, второй
>раз - вылетает.
>
>Эта проблема наюлбдается с библиотеками lthread, c_r. С thr - все норм,
>но она присутсвует с 5й версии ОС.Что дает -lpthread ?
>
>>>glibc есть только в GNU/Linux. В FreeBSD libc.
>Им-то(FreeBSD) хуже =).Плохо знаю FreeBSD. Но пока Linux устраивает.
>>
>>>Это кривой БСД!!
>>
>>Обосновать сможешь? Или первым на запись в ряды пустознонов?
>>
>>>У меня не было времени заниматься этой проблемой очень приближенно - я
>>>попросил начальство, чтоб они обновили ОС, но можете попробовать обновить glibc.
>>
>>glibc есть только в GNU/Linux. В FreeBSD libc.
>
>>>Обосновать сможешь? Или первым на запись в ряды пустознонов?
>Да. При создании нити(потока) бьется стек/динамическая область и последующие операции с памятью
>могут вызывать проблемы.
>
>Эта проблема наюлбдается с библиотеками lthread, c_r. С thr - все норм,
>но она присутсвует с 5й версии ОС.PR в студию.
>
>>>glibc есть только в GNU/Linux. В FreeBSD libc.
>Им-то(FreeBSD) хуже =).Да ты ч0, а мужики-то и не знают.
>>>
>>>>Это кривой БСД!!
>>>
>>>Обосновать сможешь? Или первым на запись в ряды пустознонов?
>>>
>>>>У меня не было времени заниматься этой проблемой очень приближенно - я
>>>>попросил начальство, чтоб они обновили ОС, но можете попробовать обновить glibc.
>>>
>>>glibc есть только в GNU/Linux. В FreeBSD libc.
>>
>>>>Обосновать сможешь? Или первым на запись в ряды пустознонов?
>>Да. При создании нити(потока) бьется стек/динамическая область и последующие операции с памятью
>>могут вызывать проблемы.
>>
>>Эта проблема наюлбдается с библиотеками lthread, c_r. С thr - все норм,
>>но она присутсвует с 5й версии ОС.
>
>PR в студию.
>
>>
>>>>glibc есть только в GNU/Linux. В FreeBSD libc.
>>Им-то(FreeBSD) хуже =).
>
>Да ты ч0, а мужики-то и не знают.>>chip
Что-то ты эмоционаотно неуравновешенный, бросаешся на людей =).
Ты-то предложил что-то дельное??Я рассказал свою ситуацию и высказал свое предложение для решения проблемы.
ЗЫ. GNU утилиты лучше, чем *nix утилиты. Тем паче, что все-таки БСД-то юзает гнушный компилятор. ИМХО: могли бы уже перевести все утилиты на gnu.
>>>>
>>>>>Это кривой БСД!!
>>>>
>>>>Обосновать сможешь? Или первым на запись в ряды пустознонов?
>>>>
>>>>>У меня не было времени заниматься этой проблемой очень приближенно - я
>>>>>попросил начальство, чтоб они обновили ОС, но можете попробовать обновить glibc.
>>>>
>>>>glibc есть только в GNU/Linux. В FreeBSD libc.
>>>
>>>>>Обосновать сможешь? Или первым на запись в ряды пустознонов?
>>>Да. При создании нити(потока) бьется стек/динамическая область и последующие операции с памятью
>>>могут вызывать проблемы.
>>>
>>>Эта проблема наюлбдается с библиотеками lthread, c_r. С thr - все норм,
>>>но она присутсвует с 5й версии ОС.
>>
>>PR в студию.
>>
>>>
>>>>>glibc есть только в GNU/Linux. В FreeBSD libc.
>>>Им-то(FreeBSD) хуже =).
>>
>>Да ты ч0, а мужики-то и не знают.
>
>>>chip
>Что-то ты эмоционаотно неуравновешенный, бросаешся на людей =).
>Ты-то предложил что-то дельное??
>
>Я рассказал свою ситуацию и высказал свое предложение для решения проблемы.Молодец, можешь взять пирожок с полки с гвоздями.
>ЗЫ. GNU утилиты лучше, чем *nix утилиты. Тем паче, что все-таки БСД-то
>юзает гнушный компилятор.Кто мешает использовать купить и использовать icc?
> ИМХО: могли бы уже перевести все утилиты на
>gnu.займёшься?
А Вы решили эту проблему?? Потму как меня интересует исход.Я заметил, что и std:map в freeBSD4.7 страдает очень сильно.
Нельзя сказать, что это проблема конечного программиста.Ставил разные версии компиляторов(плоть до 4го). Не помогает. Что-то в корне. Мне кажется, что какие-то нелады с памятью. Тут даже не с потоками дело, ибо в безпоточном приложении некорректно работает std:map.
>
>А Вы решили эту проблему?? Потму как меня интересует исход.Общепринятой практикой является оповещение разработчиков о проблемах. Я уже упоминал - где Problem Report? Нет PR - нет проблемы (решать-то собственно и нечего).
>Ставил разные версии компиляторов(плоть до 4го). Не помогает. Что-то в корне. Мне
>кажется, что какие-то нелады с памятью. Тут даже не с потоками
>дело, ибо в безпоточном приложении некорректно работает std:map.Так может быть как раз проблема в реалазации std:map? Учитывая что STL приняло более менее человеческое обличие совсем недавно (а 4.7 это ого-го когда было).
>>
>>А Вы решили эту проблему?? Потму как меня интересует исход.
>
>Общепринятой практикой является оповещение разработчиков о проблемах. Я уже упоминал - где
>Problem Report? Нет PR - нет проблемы (решать-то собственно и нечего).
>
>
>>Ставил разные версии компиляторов(плоть до 4го). Не помогает. Что-то в корне. Мне
>>кажется, что какие-то нелады с памятью. Тут даже не с потоками
>>дело, ибо в безпоточном приложении некорректно работает std:map.
>
>Так может быть как раз проблема в реалазации std:map? Учитывая что STL
>приняло более менее человеческое обличие совсем недавно (а 4.7 это ого-го
>когда было).>>Problem Report? Нет PR - нет проблемы (решать-то собственно и нечего).
Составлю.>>Так может быть как раз проблема в реалазации std:map? Учитывая что STL
>>приняло более менее человеческое обличие совсем недавно (а 4.7 это ого-го
>>когда было).
Тоесть Вы предлагаете как вариант просто обновить систему и не поддерживать ниже какой-то.ЗЫ. Глючки в 6й проскакивают =(.
>Так может быть как раз проблема в реалазации std:map? Учитывая что STL
>приняло более менее человеческое обличие совсем недавно (а 4.7 это ого-го
>когда было).Оный map<> - составная часть GCC. Со сменой компилятора меняется и libstdc++ - если не принимать специальных извращенных мер :)
>
>А Вы решили эту проблему?? Потму как меня интересует исход.Повторяю:
Пересобрал компилятор.
Using built-in specs.
Target: i386-portbld-freebsd4.10
Configured with: ./..//gcc-4.2-20060923/configure --disable-libgomp --disable-nls --with-system-zlib --with-libiconv-prefix=/usr/local --program-suffix=42 --libdir=/usr/local/lib/gcc-4.2.0 --with-gxx-include-dir=/usr/local/lib/gcc-4.2.0/include/c++/ --infodir=/usr/local/info/gcc42 --disable-rpath --prefix=/usr/local i386-portbld-freebsd4.10
Thread model: posix
gcc version 4.2.0 20060923 (experimental)
Теперь пишу не g++ ... а gcc.добавил ключ -lstdc++
Заработало.В смысле SIGBUS пропал.
>
>Я заметил, что и std:map в freeBSD4.7 страдает очень сильно.
>Нельзя сказать, что это проблема конечного программиста.
>
>Ставил разные версии компиляторов(плоть до 4го). Не помогает. Что-то в корне. Мне
>кажется, что какие-то нелады с памятью. Тут даже не с потоками
>дело, ибо в безпоточном приложении некорректно работает std:map.Теперь же new выделяет огромное количество памяти. (потому что класс СЛИШКОМ велик по размеру, хотя ничего сложного в нем нет. Подозрительно много памяти он требует...) И в чем тут проблема понять не могу. Приложение вываливается из-за нехватки при выделении...
Переписывал код на Си. На структуры... Размер тот же... огромный. Но не может же быть такого! Тут проблема или FreeBSD или gcc
Вобщем, проблема не решилась
>
>Переписывал код на Си. На структуры... Размер тот же... огромный. Но не
>может же быть такого! Тут проблема или FreeBSD или gcc
>
>Вобщем, проблема не решилась
А покажите переписанный на C на структуры.
>>
>>Переписывал код на Си. На структуры... Размер тот же... огромный. Но не
>>может же быть такого! Тут проблема или FreeBSD или gcc
>>
>>Вобщем, проблема не решилась
>А покажите переписанный на C на структуры.
Основное:
============================ Так было на С++ ========================class DaemonThread{
private:
pthread_t Thread;
int Socket;
struct sockaddr_in Addr;time_t StartTime;
time_t Timeout;char Module[NAMELEN];
/* TMP_MAX are defined into stdio.h */
char Name[TMP_MAX]; //NAMELEN];int Status;
int FileDescriptor;
static void *Exec ( void * );
public:
char Buffer[BUFSIZE];
DaemonThread ();
void Init ( int );int Start ( void );
/* Get private data */
int getStatus ( void );
void getStringStatus ( char * );
pthread_t getThread ( void );
int getSocket ( void );
char *getName ( void );
int getFileDescriptor ( void );
time_t getStartTime ( void );
time_t getTimeout ( void );char *ParseBuffer ( char * );
void getInfo ( char * );
~DaemonThread ( void );
};============================ Так стало на Си ========================
struct TDaemonThread{
pthread_t Thread;
int Socket;
struct sockaddr_in Addr;time_t StartTime;
time_t Timeout;char Module[NAMELEN];
/* TMP_MAX are defined into stdio.h */
char Name[TMP_MAX]; //NAMELEN];int Status;
int FileDescriptor;
char Buffer[BUFSIZE];
};
typedef struct TDaemonThread DaemonThread;
void *Exec ( void * );
void Init ( DaemonThread *, int );
int Start ( DaemonThread * );
int getStatus ( DaemonThread * );
void getStringStatus ( DaemonThread *, char * );
pthread_t getThread ( DaemonThread * );
int getSocket ( DaemonThread * );
char *getName ( DaemonThread * );
int getFileDescriptor ( DaemonThread * );
time_t getStartTime ( DaemonThread * );
time_t getTimeout ( DaemonThread * );char *ParseBuffer ( DaemonThread *, char * );
void getInfo ( DaemonThread *, char * );
void Destroy ( DaemonThread * );
========================
Теперь просто нужно каждый раз передавать указатель на структуру, чтобы знать с каким "объектом" идет работа. Например обращение Socket превращается в Th->Socket, а вызов из метода другого метода типа getName() превращается в getName ( Th ), где Th - это DaemonThread *.
Вот и всё.Кто-нибудь решил проблему с сигналом и выделением памяти?
Q: сколько это: NAMELEN, BUFSIZE, TMP_MAX?
Q: а не стоит ли в классик запихнуть вместо буфера std::string?
Q: а не стоит ли в структурке оставить указатель, и память под буфера
malloc()ить по мере надобности и в точности нужного размера?
>Q: сколько это: NAMELEN, BUFSIZE, TMP_MAX?
#define NAMELEN 50
#define BUFSIZE 1024
TMP_MAX описан в stdio.h#define TMP_MAX 308915776
аааааааааааа! ВОТ ОНО!!!!!!!! Убийцы! Зачем же столько памяти в пустую жрать?
Не помню какой man я курил, но где-то я эту константу откопал... и не поинтересовался ее значением. Она нужна была вроде для какой-то функции с созданием tmp-файлов.
Срочно иду исправлять! =)>Q: а не стоит ли в классик запихнуть вместо буфера std::string?
Хм... А это зачем? В чем плюсы? (зы: не люблю с чужими классами возиться..)>Q: а не стоит ли в структурке оставить указатель, и память под
>буфера
> malloc()ить по мере надобности и в точности нужного размера?
>
Лишней мороки много... И segmentation fault потом отлавливать еще пару часиков =) Хотя я не против. Люблю экономить память.
>>Q: а не стоит ли в классик запихнуть вместо буфера std::string?
>Хм... А это зачем? В чем плюсы? (зы: не люблю с чужими
>классами возиться..)С STL не надо возиться. STL надо юзать. Польза в данном случае
простая - отсутствие мороки с управлением памятью, выделенной
под строку. И отсутствие буферов фиксированного размера,
размером "по максимуму".
>ЗЫ. GNU утилиты лучше, чем *nix утилиты. Тем паче, что все-таки БСД-то
>юзает гнушный компилятор. ИМХО: могли бы уже перевести все утилиты на
>gnu.(а) лицензия гнусная - гнусна воистину
(б) про BSD не знаю, а в Solaris, Tru64 и HP-UX утилиты в основном, скажем так, не хуже гнусных. Ничем не хуже.
>У меня возникла проблема при программировании на C++.
>
>Теперь сама суть проблемы:
>В программе стал появляться сигнал SIGBUS. Он возникает в конструкторе
>класса, обслуживающего нить. Проверял отладчиком. Процесс заходит в
>конструктор без ошибок. И на первом же присваивании приватному полю Status
>значения STATUS_INIT, процесс получает сигнал SIGBUS. Программа аварийно
>завершается.
>Я не могу понять в чем тут ошибка. В Linux SUSE всё
>работало, и подобных
>сигналов не возникало.
>
>В чем здесь ошибка? Помогите, пожалуйста, решить проблему.А что говорит valgrind на линуксе?
>А что говорит valgrind на линуксе?Кстати, резоннейший вопрос. valgrind рулит.