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

[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 )