NamedPipe и отжор памяти

← →
Alkid © (2005-12-01 13:49) [0]

Вопрос высокоучёному сообществу: организуется связь между двумя компьютерами путём NamedPipe. Сервер создаёт у себя пайп, а клиент открывает его как файл. Если сервер недоступен, то клиент циклически пытается его открывать.

При всём при это наблюдается интерсное явление: если в ДРУГОМ процессе (наприер IE, WinCommander, etc.) делать что-то с сетью (лазить по локалке, шариться по интернету), то начинается резкий и дикий отжор памяти в КЛИЕНТСКОМ приложении.

Если не шариться по сети, то утечек памяти не наблюдается.

Вопрос: кто-нибудь сталкивался с чем-нибудь подобным и вообще, какие мысли есть у высокоучёного сообщества?

← →
Lamer@fools.ua © (2005-12-01 14:51) [1]

> какие мысли есть у высокоучёного сообщества?

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

← →
Alkid © (2005-12-01 14:56) [2]

Вот код, который производит открытие пайпа. Он выдран из
одной процедуры, которая крутится в специальном потоке.

FIP - поле, содержащее IP-адрес сервера

begin pipename := "\\" + FIP + "\pipe\SMI2SERVER"; FPipe := CreateFile( PChar(pipename), // pipe name GENERIC_READ or GENERIC_WRITE, 0, // no sharing Nil, // no security attributes OPEN_EXISTING, // opens existing pipe 0, // default attributes 0); // no template file if(FPipe = INVALID_HANDLE_VALUE) then begin sleep(10000); exit; end else begin dwMode := PIPE_READMODE_MESSAGE or PIPE_NOWAIT; SetNamedPipeHandleState(FPipe,dwMode,nil,nil); FConnState := CS_Connected; end; end;

← →
Digitman © (2005-12-01 16:20) [3]

> Вот код, который производит открытие пайпа

и это ВСЁ, что делает клиентское приложение ?

нахрен такое нужно, спрашивается ?)

← →
Alkid © (2005-12-01 16:48) [4]

> и это ВСЁ, что делает клиентское приложение ?
>
> нахрен такое нужно, спрашивается ?)

Нет, не всё. Но когда мы искали утечку памяти, то методом "дихотомического обрезания кода" :) выяснили, что там сама утечка происходит если работает только вот этот код. Постить сюда ВСЮ программу я не буду (большая) и не могу (секретность - это не шутки).

← →
Digitman © (2005-12-01 16:54) [5]

дурь это "дихотомическая", скажу я тебе.

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

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

← →
Джо © (2005-12-01 17:02) [6]

Отжор памяти - это в смысле утечка (забираем, но не отдаем)? Пробовал с альтернативными менеджерами памяти гонять? Например, MemCheck.pas (http://v.mahon.free.fr/pro/freeware/memcheck).

← →
Alkid © (2005-12-01 17:06) [7]

> дурь это "дихотомическая", скажу я тебе.

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

Здесь речь идёт именно о том, напортачил ли я что-то в самом процессе открытия пайпа как файла или это особенности реализации именованных каналов в виндовс вообще или в Win2000 PRO SP4 в частности.

← →
Alkid © (2005-12-01 17:11) [8]

> Отжор памяти - это в смысле утечка (забираем, но не отдаем)?
> Пробовал с альтернативными менеджерами памяти гонять? Например,
> MemCheck.pas

Да, пробовал я MemCheck, только он делает программу неработоспособной. Лезет ошибка. Вроде сделал всё, как написано в инструкции. Кроме того, когда понял, что надо искать вручную, стал жёстко отсекать все части программы, где есть размещение памяти и дошёл до того, что этот отрывок когда даёт прирост памяти, причём строго при наличии сетевой активности у ДРУГОГО процесса. Этот факт меня и смутил.

← →
Digitman © (2005-12-01 17:12) [9]

> вызывается не один раз

вот именно.

и где у тебя там закрывается хэндл трубы в случае успешного его получения - это страшная буратинская тайна.

← →
Игорь Шевченко © (2005-12-01 17:12) [10]

> или это особенности реализации именованных каналов в виндовс
> вообще или в Win2000 PRO SP4 в частности.

Это вряд ли. Пардон, немалая часть Windows построена на именованых каналах (свясь с сервисами и т.д.), поэтому в реализации самих каналов все хорошо. Скорее, некоторая особенность есть в реализации конкретной программы. Я бы попробовал посмотреть в сторону Process Explorer c www.sysinternals.com, оно много всего интересного про конкретный процесс рассказывает.

← →
Alkid © (2005-12-01 17:19) [11]

> вот именно.
>
> и где у тебя там закрывается хэндл трубы в случае успешного
> его получения - это страшная буратинская тайна.

А кто сказал, что во время этого теста есть успешное получение хэндла? Тест проходит специально при отсутсвии сервера как класса (указывается несуществующий ip). Так что закрытия хэндла в тесте нету, и это не есть страшная буратинская тайна :)

> Это вряд ли. Пардон, немалая часть Windows построена на
> именованых каналах (свясь с сервисами и т.д.), поэтому в
> реализации самих каналов все хорошо. Скорее, некоторая особенность
> есть в реализации конкретной программы. Я бы попробовал
> посмотреть в сторону Process Explorer c www.sysinternals.
> com, оно много всего интересного про конкретный процесс
> рассказывает.

Спасибо, гляну туда.

а что за блажь - ожидать доступности экз-ра пайпа комбинацией CreateFile+sleep ? причем - в рамках алгоритма, в задачи которого явно не входит какое-то бестолковое ожидание у моря погоды после отказа в коннекте ?

WaitNamedPipe со встроенным механизмом таймаута уже упразднили ?

> А попробовать покрутить этот код в основном потоке в цикле
> ?

Ты угадал мой следующий шаг в этом направлении. Просто вообще всё это живёт в DLL-ке, которая ко всем её недостаткам ещё и COM :-)
Сейчас я готовлю тестбед конкретно для неё.

> Alkid © (01.12.05 17:41) [15]

Выдернуть из DLL, сделать тестовое приложение и проверить, чего будет. Если память будет жрать, то придется слушать
> Digitman © (01.12.05 17:37) [13]
. Если нет - значит проблема не в этом коде, а в потоке.

NamedPipe и отжор памяти Найти похожие ветки