Сервер сокетов перестает работать

[Mikl]

Уважаемые, подскажите ЕСЛИ кто сталкивался.

Есть набор клиент-серверных приложений собственной разработки. Для связи используются сокеты в виде  классов в которых реализовна и клиентская и серверная части. Вся часть ПО ответственная за связь вынесена в отдельную DLL.

Сервер запускается, клиенты к нему подключаются, отключаются и т.д. и т.п.
Все нормально работало неделями - дольше не получалось тестировать непрерывно - приходилось перезапускать.
Клиентов было штук 20.

Сейчас клиентов увеличил до 150. Теперь все работает но 2,5 дня. Может и дольше - до недели, но не меньше точно.
Потом происходит следующая ситуация. Сервер видит подключения клиентов, новые подключаются, старые отключаются, но данные не пересылаются ни в одну сторону.

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

Перезапускаешь приложение - все опять работает.
Понятно, что где-то что-то переполняется, но вот что и где?

Идеи есть какие-нибудь?
Спасибо.

[Finch]

А есть ли освобождение сокетов на серверной части, после окончание сессии с клиентом?

[Mikl]

Да, конечно.
Потом, даже если бы и не было - перезапуск класса связи - это delete, затем new со всеми вытекающими.
В конструкторе/деструкторе класса используются фукнции WSAStartup/WSACleanup.
Так что с МОЕЙ точки зрения - все начинается с нуля с перезапуском класса связи.
НО я где-то ошибаюсь.

[Finch]

Mikl, не пробовал ли прогонять свое приложение через программы по отлову утечек и тому подобное?

[Mikl]

Нет. Не силен я в этом. В Visual Stiduo есть механизм контроля утечек памяти и протоколирования всех исключений. Вот его я задействовал - там чисто.

[Finch]

Хорошо. С другой стороны зайдем. Когда твое приложение зависло. В диспетчере задач. Сколько памяти выделено для твоего приложения. Также, сколько нитей?  Также эти цифри в рабочем состоянии.

Также программа netstat. Сколько открытых сокетов показано, которые принадлежат твоему приложению?

Кстати, у Виндовс есть лимит открытых сокетов. И по умолчанию он довольно маленький. Не превышаеш ли ты его?

[Mikl]

Приложение НЕ зависло. Оно как работало - так и работает. Срабатывают функции перезапуска модуля связи.
Дальше я жду - ничего нет (в смысле данные не идут) и нажимаю в приложении кнопку выход - все КОРРЕКТНО завершается без каких-либо утечек чего-либо .

Памяти сколько выделено и нитей - столько же, сколько и при старте программы.

А вот насчет netstat - сказать ничего не могу - я только что про нее узнал - пока есть данные только ДО падения связи. Жду когда упадет - с учетом запланированного на завтра перезапуска - где-то в понедельник, не раньше.


Добавлено через 1 минуту и 15 секунд:
Да, еще забыл добавить интересное наблюдение - перезапуск класса связи искусственно срабатывает 101 раз. А потом надо один фиг перезагружать всю программу целиком.

[Finch]

Можно увидеть код создания нитки, после получения от клиента запроса на открытие сессии. Также саму нить. Логику самого приложение можеш убрать. Меня интересует, как именно ты работаеш с сокетом только.

[Mikl]

Да нет проблем. Так как классы связи вынесены в отдельную DLL - то....куда выслать проект?

[Finch]

Меня проект не интересует. Да и я не смогу его запустить у себя. Код просто здесь выложи мест которые я указал.

[Mikl]

Хорошо. Выкладываю. Это поток, в котором сервер ждет запросы клиентов на присоединения.
Вы это имели в виду?

Код:

UINT Potok(LPVOID pParam)
{
	SOCKADDR_IN saddr;
	WSADATA data;

	//
	char hostname[20];
	nomer_soketa=0; for(DWORD i=0;i<Max_Chislo_Klients;i++) {SocketUsed[i]=FALSE;}

	if (WSAStartup(0x202,&data)) {Fl_Err=2;return 0;}
	if (gethostname(hostname,sizeof(hostname))) {Fl_Err=2;return 0;}
start:
	mainSocket=WSASocket(AF_INET,SOCK_STREAM,0,NULL,0,WSA_FLAG_OVERLAPPED);
	if (mainSocket==INVALID_SOCKET) {Fl_Err=3;return 0;}
	saddr.sin_family=AF_INET;
	saddr.sin_addr.S_un.S_addr=INADDR_ANY;
	saddr.sin_port=htons(PortServer);

	int optval = 1;
	int rc;
	rc = setsockopt(mainSocket, SOL_SOCKET, SO_REUSEADDR,
		(char *)&optval, sizeof(optval));

	if (bind(mainSocket,(PSOCKADDR) &saddr,sizeof(SOCKADDR_IN))) 
	{
		DWORD mmm999=GetLastError();
		Fl_Err=3;return 0;
	}
	Fl_Err=1;
	if (listen(mainSocket,Max_Chislo_Klients)) {Fl_Err=3;return 0;}
	if (PotokMastExit) return 0;
	slaveSocket[nomer_soketa]=WSAAccept(mainSocket,NULL,NULL,NULL,0);
	if (PotokMastExit) return 0;
	if (slaveSocket[nomer_soketa]==INVALID_SOCKET) {Fl_Err=3;return 0;}
	if (closesocket(mainSocket)) {Fl_Err=3;return 0;}
	if (WSAAsyncSelect(slaveSocket[nomer_soketa],MainHandle,WM_TRANSACT,FD_READ || FD_CLOSE))
		{Fl_Err=3;return 0;}
	SocketUsed[nomer_soketa]=TRUE;
	Massiv_Klients[nomer_soketa].Klient_To_Server=Massiv_Klients[nomer_soketa].Server_To_Klient=
		Massiv_Klients[nomer_soketa].Byte_From_Klient_Soket_Service=
		Massiv_Klients[nomer_soketa].Byte_From_Klient=0;
	EventTotal[nomer_soketa]=0;
    EventArray[nomer_soketa][EventTotal[nomer_soketa]] = WSACreateEvent();
    ZeroMemory(&AcceptOverlapped[nomer_soketa], sizeof(WSAOVERLAPPED));
    AcceptOverlapped[nomer_soketa].hEvent = EventArray[nomer_soketa][EventTotal[nomer_soketa]];
    DataBuf[nomer_soketa].len = DATA_BUFSIZE;
    DataBuf[nomer_soketa].buf = buffer[nomer_soketa];
	RecvBytes[nomer_soketa]=BytesTransferred[nomer_soketa]=CallBack[nomer_soketa]=
		Flags[nomer_soketa]=0;
    EventTotal[nomer_soketa]++;
	DataBuf[nomer_soketa].len = DATA_BUFSIZE;
	DataBuf[nomer_soketa].buf = buffer[nomer_soketa];
	Schitano[nomer_soketa]=true;
	KolvoUsedSockets++;
	if (nomer_soketa==Max_Chislo_Klients-1) nomer_soketa=0;
	else nomer_soketa++;
m1:
	if (SocketUsed[nomer_soketa]==TRUE)
	{
		if (nomer_soketa==Max_Chislo_Klients-1) nomer_soketa=0;
		else nomer_soketa++;
		goto m1;
	}
	//PostMessage(MainHandle,WM_PAINT,0,0);
m2:
	if (KolvoUsedSockets==Max_Chislo_Klients)
	{
		Sleep(1000);
		goto m2;
	}
	goto start;
	return 0;
}

[Finch]

У тебя не правильная логика серверного приложения. Попробую сейчас поправить. Предупреждаю сразу. Что могут быть ошибки в моем коде.

[Mikl]

Лучше на словах. Т.к. здесь почти все взято с примеров MSDN

[Finch]

Код:

DWORD WINAPI SessionThread( LPVOID lpParam )
{
   //lpParam у нас будет номер сокета   
   SOCKET socket = (SOCKET) lpParam;
   // Тут логика работы твоего приложения с клиентом
   closesocket(socket);
   return 0;
}


UINT Potok(LPVOID pParam)
{
   SOCKADDR_IN saddr;
   WSADATA data;
   SOCKET mainSocket=INVALID_SOCKET;
   SOCKET slaveSocket=INVALID_SOCKET;
   HANDLE dwThread;

   if (WSAStartup(0x202,&data)) 
   {
      Fl_Err=2;
      return 0;
   }
   mainSocket = WSASocket(AF_INET,SOCK_STREAM,0,NULL,0,WSA_FLAG_OVERLAPPED);
   if (mainSocket==INVALID_SOCKET) Fl_Err=3;
   else
   {
   	saddr.sin_family=AF_INET;
	saddr.sin_addr.S_un.S_addr=INADDR_ANY;
	saddr.sin_port=htons(PortServer);

	int optval = 1;
	int rc;
	rc = setsockopt(mainSocket, SOL_SOCKET, SO_REUSEADDR, (char *)&optval, sizeof(optval));

	if (bind(mainSocket,(PSOCKADDR) &saddr,sizeof(SOCKADDR_IN))) 
	{
		DWORD mmm999=GetLastError();
		Fl_Err=3;
		PotokMastExit = true;
	}
        Fl_Err=1;
	if (listen(mainSocket,Max_Chislo_Klients)) 
	{
	   Fl_Err=3;
	   PotokMastExit = true;
	}
	while (!PotokMastExit) 
	{
	    slaveSocket = WSAAccept(mainSocket,NULL,NULL,NULL,0);
	    if (slaveSocket != INVALID_SOCKET) 
	    {
	         dwThread = CreateThread(NULL, 0, SessionThread, (void *)slaveSocket, 0, &dwThread);  
	         CloseHandle(dwThread);  // Закрываем хендл нити, так как с серверной части он нас больше не интересует 
	    }
	}
	closesocket(mainSocket);
   }
   WSACleanup();
   return 0;
}

Вот так примерно должно выглядеть серверная часть приложения. Могут быть ошибки. Не компилировал и не проверял.

[Mikl]

спасибо, попробую завтра разобраться на свежую голову.

Добавлено через 7 часов, 18 минут и 52 секунды:
Попробовал.
Согласен с тем, что Вы более изящно оформили код в плане обработки ошибок.
Но в том то и дело, что их нет - даже когда связь валится - соединения с клиентом происходят нормально, т.е. в ветви обработки ошибок программа не попадает.

Принципиальное отличие только в том, что Вы создаете отдельный поток на каждого подключенного клиента. Для меня это не нужно да и нежелательно. Т.к. ожидание соединений вынесено в поток, то обработчик событий в сокетах я оставил в самом классе. И он один.

Так что где у меня неправильная логика - не понимаю. И потом, все это не объясняет почему возможен только 101 перезапуск (удаление и создание вновь) класса связи.

[Finch]

Код:

	slaveSocket[nomer_soketa]=WSAAccept(mainSocket,NULL,NULL,NULL,0);
	if (PotokMastExit) return 0;
	if (slaveSocket[nomer_soketa]==INVALID_SOCKET) {Fl_Err=3;return 0;}
	if (closesocket(mainSocket)) {Fl_Err=3;return 0;}

Зачем например закрывать главный сокет? А потом его заново пересоздавать? В моем коде он создается один раз. И до тех пор пока приложение не будет закрыто. Кстати, та логика, что я привел. Это стандартная логика серверных приложений.  В твоей логике. Если например клиент начнет тупить, и не отсылать запрос сразу. Сервер повиснит и не будет принимать последуюшие запросы. Т.е убить твое приложение можно просто, открыть соединение и держать его открытым.

И кстати эти return 0 везде по коду, явная утечка. Текут у тебя зомби-сокеты.

[Mikl]

Зачем например закрывать главный сокет? - Честно? А фиг его знает. Даже не задумывался.
Совет дельный - сейчас переделаю, но не совсем как ты предлагаешь - просто в своем коде перенесу метку
start:
  к коду
   slaveSocket[nomer_soketa]=WSAAccept(mainSocket,NULL,NULL,NULL,0);

Насчет "клиент начнет тупить" - проверено неоднократно - ничего не виснет. Серверу пофиг на этого клиента. Все работает с остальными дальше.

Выяснил еще один интересный факт. Сейчас  усиленно гоняю приложение  в режиме постоянных перезапусков класса связи и обнаружил, что ИНОГДА:
1. Перезапускаю класс связи. Ни одна из функций класса сервера НЕ возвращает ошибку.
2. netstat -n НЕ показывает что на таком-то порту что-то кем-то слушается.
3. клиент естественно говорит - сервер не найден.
4. после нескоьких(1-n) перезапусков все работает опять.

По этому поводу наткнулся на

http://forum.vingrad.ru/forum/topic-99522/unread-1.html

там описаны параметры

TcpTimedWaitDelay,TcpNumConnections,MaxUserPort.

У меня их в реестре нет. Может создать?

Добавлено через 3 минуты и 16 секунд:
Да, а насчет потоков и дескрипторов - пытаюсь понаблюдать, но толку мало - в приложении десятка 2 потоков, все постоянно "шевелится" и уловить что-то трудновато. Но устойчивого роста какого-либо показателя нет.
А виртуальная память вообще подупала .

[Finch]

Я не разбирался как именно ты работаеш с клиектом при открытии сессии. Поэтому не могу ничего сказать. Но можно проверить кстати. Просто на клиенте открой соединение. И ничего не посылай серверу.
А вот то, что netstat тебе показывает, что сервер ничего не слушает. Вот это есть очень плохо. Сервер должен постоянно прослушивать порт, когда приложение запушено в рабочее состояние.

[Mikl]

поотключал все что смог - счетчик дескрипторов подрастает.
Сейчас переделаю по твоему совету, а заодно добавлю параметров в реестр, а затем снова погоняю.

[Finch]

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

[Mikl]

да немного штук 40 мне пока хватит, просто некоторые клиенты очень специфичны и считать их в нагрузке один к одному нельзя.

Я думал про другое - там указан максимальный порт в системе 5000. У меня в реестре таких параметров нет, а порт как раз 5001.
Ну и время когда сокет в TIME_WAIT я бы сократил ниже плинтуса. Кстати вопрос до скольки? Сеть локальная, клиентов с инета нет.

[Finch]

Ты не правильно понял. Это не максимальный порт. А количество открытых портов одновременно. Т.е. это количество открытых соединений одновременно. Например порт у аськи 5190. А на твоей стороне порт обязательно будет выше 32536. Кстати настоятельно не рекомендуется открывать порты на прослушивание выше чем 32536. Порты от 32536 и до 65535 предназначены для автоматической биндовки.

Кстати обрати внимание на return 0 в своем коде. Почти всегда это чревато не закрытием сокетов у тебя. 

[Mikl]

MaxUserPort - максимально доступный открываемый № порта, по умолчанию 5000.

как раз написано порт пользователя, а не используемые (USED). Ну да это не важно и без них все работает до определенного момента.

Сокеты закрываются в деструкторе класса.

[Finch]

Вот здесь тоже не правильная логика. При программировании надо почти всегда придерживаться принципа. "Где открыл, там и закрыл."

[Mikl]

согласен. Туговато у меня с логикой ООП. И всякие "goto" тоже не есть гуд. Но т.к. первый язык был ассемблер - никак не могу переучиться.

Добавлено через 9 минут и 28 секунд:
>Просто на клиенте открой соединение. И ничего не посылай серверу.

Попробовал. Все отлично работает - следующий спокойно цепляется и работает, а тестовый так и висит, пока сервер его сам не прибьет по другим факторам.

Добавлено через 4 часа, 30 минут и 51 секунду:
to Finch

> поотключал все что смог - счетчик дескрипторов подрастает.
>С ейчас переделаю по твоему совету, а заодно добавлю параметров в реестр, а затем снова погоняю.

Реестр пока решил для чистоты эксперимента не трогать.
Погонял. Решились (кажется) 2 проблемы сразу - счетчик дескрипторов расти перестал.
И перестала уменьшаться выделенная приложению память - раньше сползала с 600 до 300 мб.

Сейчас попробую повключать нагрузки сколько смогу, а на рабочей системе запущу в понедельник.

Спасиобо огромное.

Добавлено через 19 дней, 5 часов, 58 минут и 44 секунды:
Еще раз  спасибо!

Проблема решена. Сервер проработал 2 недели вывалившись по совершенно иной причине.

Вот только сомнения остались - в чем была причина?!?! Что "крамольного" в закрытии и открытии главного сокета вновь, что приводило к таким последствиям?

Но в принципе тема закрыта.

[Finch]

Ну скорее всего в подвисании ресурсов. 

[Mikl]

Как теперь выяснилось (спустя почти 2 года) проблема не решена. Опять все повторилось. Поэтому вопрос снова открыт - какие могут быть варианты? библиотеку которая содержит классы по работе с потоками я это время не трогал. Менял только код основного приложения. Все работало. Сейчас переехал на другое железо - вылезла старая проблема. Дистрибутивы ОС и VS один и тот же.

[RXL]

Делай проверки, лови исключения. Отладить по фотографии нельзя.


Серверный сокет вполне можно закрыть. Открывая его вновь не забудь REUSE.

[Mikl]

Про фотографии я в курсе . Пока рою землю.
Дело в том что сервер работает под отладчиком - и никаких проблем не возникает - студия не ругается ни на что.
REUSE - поподробнее можно?
У меня при детекте потери связи класс отвечающий за связь уничтожается и создается заново. Единственное что до меня дошло - надо попробовать делать WSACleanup и затем WSAStartup. Но этот вариант означает - есть грабли в библиотеке WSA. В подтверждение этого

http://muforum.info/forums/index.php?showtopic=1586

Не кто не сталкивался с заплатками от MS для WinSocket?

[RXL]

Опция сокета - port reuse. Чтобы система не отвергала попытку bind на сокет, пока еще существуют соединения на этот порт (активные или в финишных стадиях).

[Mikl]

Система не отвергает. т.е. что до перезапуска класса связи сервера, что после клиенты подключаются. А вот команды не ходят. Так что bind не причем.

Добавлено через 47 минут и 9 секунд:
Обнаружил еще интересную фишку. В диспетчере задач приложение жрет гиг памяти и 1,5 виртуальной. Память у меня программа берет при старте и отдает в конце работы. А в диспетчере задач через какое-то(произвольное) время вместо гига появляется 420 мегабайт. При этом все еще несколько часов продолжает работать.

Добавлено через 1 день, 11 часов и 59 секунд:
Всем спасибо, думаю что тему можно закрывать. Перенес программу на старый сервер - все работает - память из программы не пропадает. Видимо что-то в ОС.

Добавлено через 47 дней, 10 минут и 59 секунд:
Как оказалось дело не совсем в винде. Или в какой-то комбинации - так и не пойму.
Есть сервер где программа работает уже 3 года месяцами (иногда по нескольку - как новая версия появится).
Но сколько не беру новых серваков с теми же дистрибутивами везде получаю одно и тоже. Через сутки выделение памяти падает с 1,1 Гб, до 400 Мб а затем падает библиотека WSA. Если ее перезапустить, заново создать класс отвечающий за связь - все работает.
Стал копать дальше. Методом глубоко научного тыка выяснил что все сводится к одному блоку кода.  Данный код работает в потоке. Поток запускается раз в 10 минут, отрабатывает примерно 1-2 минуты и закрывается. Код того места в потоке где возникает ошибка

if (CopyFile(FileNameIst,FileNamePri,false)==0)
   m_pUkaz->StrPotok2="Ошибка копирования файла "+str1.Mid(1,str1.GetLength())+" .";
else m_pUkaz->StrPotok2="Файл "+str1.Mid(1,str1.GetLength())+" скопирован.";

Вариантов остается 2 - либо проблемы из-за функции CopyFile, либо из-за операций со строками. Сейчас выясняю. Но логичного объяснения пока так и не нахожу. Идеи есть?

[RXL]

А проблем с выделением/освобождением памяти в потоке нет? Если, к примеру, поток не создавать и убивать каждый раз, а создать один раз и запускать/замораживать по необходимости?

[Mikl]

В потоке память не выделяется и не освобождается.
А зачем мне его держать, если он не нужен? Можно конечно "пинать" его по необходимости. Но проблема не в этом. Проблема именно в тех строках кода что я писал.

[RXL]

Код:

m_pUkaz->StrPotok2="Ошибка копирования файла "+str1.Mid(1,str1.GetLength())+" .";

Это не что иное, как выделение памяти.

[Mikl]

Согласен, но не мной явно. Тем более что переменные объявлены ранее, а одна так вообще вне потока. И используются в потоке много где еще - и никаких проблем. Но тем не менее как раз сейчас и выясняю - не в строках ли дело. Пото, если выделение памяти неявно мной, то по завершении потока все должно возвращаться в исходное состояние. Да и утечек нет (VS молчит об этом). И если нет обращений со стороны клиентов все работает трое суток (больше не проверял).

[RXL]

При общих межпоточных данных обязательно нужно использовать блокировки. Сбои без блокировок как раз редки и непонятны.

[Mikl]

И это я в курсе. нет общих межпоточных данных. Та переменная что относится к классу используется ТОЛЬКО этим потоком. Сбои теперь как раз более менее стабильны, но тем не менее непонятны.

[RXL]

Тем более что переменные объявлены ранее, а одна так вообще вне потока.

[Mikl]

и что? Переменные объявлены ранее но в потоке. Соответственно при закрытии потока они удаляются. А та что объявлена вне потока - повторюсь используется только в этом потоке и нигде более.

[RXL]

Вот это: m_pUkaz->StrPotok2
Переменная создается в потоке или вне?

[Mikl]

Вне потока. она описана как член класса, соответственно создается при создании класса.

[RXL]

И синхронизировать это не надо?

[Mikl]

Что с чем синхронизировать?
Объяснения на самом деле мне видится 2 - некорректная работа класса CString при каких-то условиях, либо некорректная работа функции CopyFile.
Поскольку проблема наблюдается только при использовании и этого кода в потоке и класс отвечающего за связь. Они никак не связаны и единственное где могут пересекаться как я думаю - куча и стек.

[Алексей++]

Mikl, не бывает ничего "вне потока". Если логику своей программы знаешь, подумай, могут ли два потока одновременно заходить в некую функцию ? Если могут, то смотри в этой функции использование членов класса или других не локальных или статических объектов. Их использование нужно синхронизировать

[RXL]

Вопрос на проверку: как CString выделяет память и является ли это thread safe?

[Mikl]

Насколько я знаю CString всего лишь указатель, а память под данные динамически изменяется по мере надобности. Насчет thread safe - не знаю. Буду признателен если отправите где это можно прочитать.

[Алексей++]

Насколько я знаю CString всего лишь указатель

да

и синхронизировать конечно же надо

[Mikl]

Проясните мне бестолковому, пожалуйста, что с чем я должен синхронизировать? объект CString? С чем? Если он используется только в потоке? Я понимаю, что если бы к данной переменной обращался в разных местах программы, то да - без флагов и Interlocked не обойтись.

[Алексей++]

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

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

Синхронизация вводится для того, чтобы свести эту вероятность к нулю.

Предполагаю, что ты уже читал и работал с синхронизацией, но если это не так, то, на всякий случай, вот:

к примеру, в ОС Windows для этого используется критическая секция, которая оборачивает защищаемый (синхронизируемый) участок кода. Работает это так:

S - объект для синхронизации (хендл критической секции)
O - защищаемый ресурс

Код:

//первый поток
func1()
{
    S.lock();

   работа с O

    S.unlock();
}

Код:

//второй поток
func2()
{
    S.lock();

   работа с O

    S.unlock();
}

когда один поток вошёл в секцию (вызвал lock() ), то второй поток при попытке войти в секцию будет заблокирован в методе lock() до тех пор, пока первый поток не вызовет unlock()

[RXL]

Mikl, попробуй просто закомментировать этот участок с присвоением. Для тестов.

[Mikl]

Уважаемые, это все я в курсе. И мне просто нечего сихронизировать,т.к. данная переменная используется только в этом потоке, а вынесена она из него по другой причине (скорее дял эксперимента).
Разбираться в коде и не надо. Закоментировать - уже сделал - тест идет. В течении недели должен выяснить окончательно и разобратьяс во всем сам. Проблемы то теперь в другом - либо CString не всегда корректно работает, либо CopyFile. А самое плохое то, что на одном компьютере (точнее на еще одном тоже, но я его уже разобрал) работает месяцами, а на других 3 дня. С тем же самым дистрибутивом ОС и прочего. Не хочу кидать камень в сторону MS, но мысли сами понимаете...
И цель теперь разобраться в чем грабли и больше на них не наступать ни мне ни другим, т.к. самое веселое в нашей работе - пытаться исправить/обойти чужие ошибки.

[RXL]

Сравнение железа делал? Нет случайно разницы в количестве ядер?

[Mikl]

Железо несравнимое абсолютно.
Работало на Phenom II-X4 4ГБ мать Gigabyte винты SATA на 750 и RAID-0 из SATA на 250 4 шт.
Не работало на виртуалке под WMWare - что там за железо без понятия но ядер было 2.
Не работает на Opteron 8 ядер 4Гб сервер Supermicro винты SATA по 250 в RAID-10 4 шт.

[RXL]

Странно выходит: если я правильно понял, падает у тебя winsock, а инициирует это копирование файла или присвоение CString.

[Mikl]

странно - верно подмечено.

[RXL]

Пока идеи кончились. Ждем результата теста.

[ezus]

Может  здесь какая-нибудь глупость типа той, что была причиной моего предыдущего поста "DLL и память"?
memcpy из CString?
Грешил на все, что только можно было.

[RXL]

Тест что-нибудь показал уже?

[Mikl]

Вторник. Раньше врядли попаду на работу

[Алексей++]

а во всех потоках есть в начале вызов AfxSocketInit() ?

(говорю только за MFC, ибо упомянут CString. Для АПИ это вроде WSAStartup )

[Mikl]

AfxSocketInit нет вообще нигде. WSAStartup есть. Естественно не во всех потоках а в основном теле программы один раз - перед созданием объекта класса связи.

[Алексей++]

Естественно не во всех потоках а в основном теле программы один раз - перед созданием объекта класса связи.

а надо в каждом потоке. Я натыкался уже на этот фокус

[Mikl]

А зачем? Если  эти потоки о сокетах вообще понятия не имеют?

[Алексей++]

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

[Mikl]

Ясно. Нет, дело не в этом.

[Алексей++]

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

а коды ошибок какие возвращаются ?

[Mikl]

Нету их. Как ни бредово звучит но....
Сокеты на клиентах открываются, первую команду клиент отсылает, но сервер ее не получает.

Добавлено через 13 часов, 19 минут и 38 секунд:
первая половина эксперимента закончена. Со строками проблем нет. Осталось выяснить с CopyFile.

Добавлено через 1 день, 23 часа, 35 минут и 10 секунд:
Выяснил. Дело именно в CopyFile. Причем т.к. функция выполняется от неск. секунд до минуты для каждого файла (их около 10), то видно что во время ее работы при подключении новых клиентов сокращается выделение памяти.
Есть какие нибудь идеи?
У меня только одна - в функция CopyFile я передаю в качестве параметров объекты типа CString, создаваемые внутри потока. Может создавать их в классе, который вызывает поток?

Добавлено через 1 день, 5 минут и 42 секунды:
Идея не удалась...

[RXL]

Какая идея? Насчет "создавать в классе"?

[Mikl]

да.

[RXL]

Причем т.к. функция выполняется от неск. секунд до минуты для каждого файла (их около 10), то видно что во время ее работы при подключении новых клиентов сокращается выделение памяти.

Поясни, пожалуйста, что ты имел в виду.

[Mikl]

Перед началом копирования в текстовом окне формы выводится надпись "копирование файла такогото....". При окончании копирования или ошибке выводится соотв. надпись - что видно из кода. Естественно что между этими надписями выполняется функция CopyFile.
Так вот поскольку она выполняется довольно продолжительное время на больших файлах, за это время (для теста) успевают подключиться, получить нужные данные и отключиться несколько клиентов. Так вот при этом выделение памяти в диспетчере задач для этого процесса снижается. Если же клиенты подключаются не во время работы CopyFile - такого не происходит.

[RXL]

Честно говоря, описание не помогает понять происходящее. Попробуй воспользоваться каким-нибудь профайлером, следящим за выделением/освобождением памяти. Возможно есть аномалии.

[Mikl]

Увы, я не знаю что это такое.
Еще пару дней "плясок с бубном" и просто выкину эту функцию из программы сделав вынос ее во внешнее приложение.

Попробую объяснить подробнее.
Для теста сделано что клиенты подключаются к серверу, получают пол мегабайта данных и отключаются. Делается это весьма быстро.
Если не работает поток в котором вся проблема - то все работает замечательно.
Поток выполняется функция CopyFile запускается раз в 10 минут для копирования файлов из одного места в другое.
Перед началом копирования каждого файла (их около 10) выводится на экран строка "Копирование файла..." и выполняется функция CopyFile.
По окончании работы функции выводится сообщение об успешном или неудачном завершении копирования файла.
Так вот при подключении новых клиентов в интервале когда работает CopyFile, т.е. между выводами сообщений, наблюдается снижение выделенной памяти на несколько килобайт.

Как по другому объяснить я не знаю. И причину тоже понять не могу.

[RXL]

Стоит ознакомиться с такими инструментами, как профайлеры...
Например, тут есть какие-то: http://en.wikipedia.org/wiki/List_of_performance_analysis_tools#C_and_C.2B.2B

[Mikl]

спасибо. Изучу. Хотя врядли в данном случае от меня что зависит - не исправлять же мне CopyFile.

[RXL]

Думаю, что вероятнее всего дело вовсе не в системной функции.

[Mikl]

методом исключений других вариантов не остается

[Phodopus]

В конструкторе/деструкторе класса используются фукнции WSAStartup/WSACleanup.

этот класс в скольких экземплярах создается?

Думаю, что вероятнее всего дело вовсе не в системной функции.

согласен с RXL, прислушайтесь

не исправлять же мне CopyFile.

даже при том что вероятность вашей ошибки в ней близка к 0, неужели это так сложно?

[Mikl]

Класс создается в одном экземпляре.
RXL естественно прав. Согласен что дело не в том как работает функция. Дело в том откуда она вызывается.
CopyFile править не думаю по одной причине - на рабочем серваке все работает уже 4 года.

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

[Mikl]

"Я ...., дорогая редакция" (С)
Путем долгих экспериментов решение проблемы было найдено. Однако причина так и осталась неясна.
Сначала Я вынес функционал по копированию в отдельное приложение, которое запускалось из главного при старте. Не помогло.
Потом я стал это приложение запускать руками. Не помогло.
Дальше пошли совсем уже пляски с бубном. Решилось все элементарно. Если функция копирования в качестве приемника использует диски этой же машины - через 1-3 сутки в приложении сервера начинается падение выделения памяти. Почему пока не разобрался. Но, если копирование осуществляется на сетевой ресурс - все работает без проблем.

Буду разбираться дальше. После выноса всего функционала по копированию в отдельное приложение синхронизация между этим приложением и серверным осуществляется только по файлу-флагу. Если его удается создать заново в приложении, значит база свободна и можно с ней работать. Осуществляется это следующим кодом (одинаковым везде)

try   {DeleteFile(m_pUkaz->FileFlagNameDB);} catch (CFileException){}
HANDLE FileHandleName=CreateFile(m_pUkaz->FileFlagNameDB, GENERIC_READ | GENERIC_WRITE, FILE_SHARE_DELETE,NULL,CREATE_NEW,FILE_ATTRIBUTE_HIDDEN,NULL);
if (FileHandleName!=INVALID_HANDLE_VALUE)
{//блокирующий файл создан - работаем с базой
...
}
CloseHandle(FileHandleName);


при этом FileFlagNameDB="\\\\server\\Baza\\TaxiDB.flg"

Так что осталось попробовать поотключать эти блоки или попробовать сделать имя файла локальным.

[Алексей++]

try   {DeleteFile(m_pUkaz->FileFlagNameDB);} catch (CFileException){}

опа...

Чем правильно ловить MFC-шные эксепшены:
http://msdn.microsoft.com/en-us/library/e583tzca(v=VS.80).aspx

пример тут
http://msdn.microsoft.com/en-us/library/x2b14fx4(v=VS.80).aspx

А если ловить при помощи try-catch, то случается утечка памяти.

[Mikl]

спасибо, изучу...

Добавлено через 33 минуты и 13 секунд:
Если я правильно понял то MFC-шные эксепшены надо ловить с помощью TRY, а не try как у меня?
Но в http://forum.sources.ru/index.php?showtopic=49090 написано

"Вопрос. В Visual C++ я видел операторы try и TRY. В чём отличие и чем лучше пользоваться?

Макросы TRY/CATCH/AND_CATCH/END_CATCH/THROW/THROW_LAST тянутся из тех времен, когда компилятор C++ от MS еще не поддерживал стандартную обработку исключений. Пользоваться ли ими – это уже ваш выбор, но в свете сказанного ранее – не советую."

И потом DeleteFile не относится к MFC вроде как? Или CFileException заменить на ...?

[Алексей++]

Mikl, я не знаю, на чём основана уверенность (вернее - неуверенность) товарисча Бобра. Но я уже сказал, что будет происходить (я прочувствовал это с исключениями CDBException):  объект класса, описывающего исключение, создаётся где-то в глубине классов MFC оператором new, выбрасывается. Если ты его ловишь catch , то никак не производишь возвращение памяти в кучу. С макросами это произойдёт автоматом.

Кроме того, я не знаю, это ли причина у тебя, но по симптомам очень похоже, особенно если исключение часто возникает. Непонятен ещё один момент - как это исключение вообще может произойти в АПИшной функции

Тебе тут вообще не нужны исключения, обрабатывай ошибки (GetLastError())

[Mikl]

>Тебе тут вообще не нужны исключения, обрабатывай ошибки (GetLastError())
Согласен. Обернуто в исключения по принципу "кашу маслом не испортишь".

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

[Алексей++]

Mikl, ещё как испортишь, если код будет критическим по скорости

[Mikl]

Это да. Только все что не критично к скорости вынесено в потоки - и там тормозит сколько влезет.

[Алексей++]

жуть, какие извращения.

[Mikl]

Может и так, но я где-то слышал, что настоящий программист не тот у которого в программе нет ошибок, а тот у которого она работает при любом их количестве

[Алексей++]

я ещё слышал, что программисты - ленивые )) А делать поток для якобы исключения тормозов - это как-то.... Нелениво, что ли

[Mikl]

замена try на TRY толку не дала....

[Алексей++]

там вообще try не нужно, по идее. И TRY тоже

ну а ошибка не обязательно тут

Добавлено через 2 минуты и 23 секунды:
пообращай внимание на данные, которые отображает диспетчер задач, повключай все интересные колонки - сколько дескрипторов, сколько потоков, память, объекты GDI и прочее. Последи за их динамикой

Добавлено через 1 минуту и 5 секунд:
TCPView , наконец. Гляди на используемые соединения - может их там мильён пооткрывался
technet.microsoft.com/ru-ru/sysinternals/bb897437

[Mikl]

Нет. Все это проверено. И никоим образом не объясняет почему при копировании в сеть все работает. Видимо я что-то сделал с тем сервером на котором все работает. А вот что - вспомнить не могу.

[Алексей++]

может там у тебя поставлен перезапуск программы раз в день, к примеру ?

[Mikl]

нет конечно. Пока копаю дальше...