OMG, this fuckin bug o_O, Наконец-то нашел причину

===========
нет, у меня практически всегда работает и работал 1 клиент. разные, но не одновременно.проблема наблюдалась при работе флаф и грея. и никогда в стронге. однако недавно случился такой глюк. работал стронг 2.22. с ним это впервые

По-моему,проблема налицо...

==============
а именно?

Некорректная работа нескольких клиентов одновременно.

Пользуясь случаем,хочу выразить анреспект PPA за его мод Стронга. О смачной проблеме я писал выше,а вот последняя версия этого поделия меня вообще удивила - на всё,что пытался скачать,оно кричало,что файлы бьются при скачке. Поставил оригинальный Стронг,тупо портировал настройки - всё пашет как часы.

Вообще,по-моему,делать merge со всеми субвервисями Стронга - бред. На выходе всегда будем имееть и имеем кучу багов. ИМХО.

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

Давно знаю о существовании проблемы и некоторых путях её облегчения. Являюсь программистом, и оператором довольно больших хабов.
По моему скромному мнению, проблема заключается конечно же в авторах оригинала, т.е. клиента DC++, видимо его авторы - программисты не очень высокого уровня и напутали с выделением памяти и вообще работой с ней. Также, наш любимый виндоус и его "великий" диспетчер управления памятью...видимо повлияли несколько факторов.
Эта проблема встречается во всех распространенных клиентах. Видимо пямять течет или еще чего.....точно сказать не могу.
Вот, что я посоветую делать:

1. Отключить смайлы и словари проверки (в грее)
2. Периодически очищать главный чат хаба и закрывать ненужные лички.
3. Почаще перезагружать комп, а не использовать ждущий и спящий режимы. Виндоус так устроен, что он их не очень любит.
4. Закрывать неиспользуемые окна проводника, браузера, а еще лучше перезагружать процесс explorer.exe
5. Использовать различные чистилки и дефрагментаторы оперативной памяти. Также, можно поэкспериментировать с файлом подкачки.

6. Найти того, кто разбирается в этом лучше меня и спросить у него, что делать

З.Ы. В грее, у меня, подобная проблема почти пропала в последних версиях, при отключенных смайлах и словарях проверки.

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


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

А это вообще не аргумент

На одном из моих компов я использую спящий режим. Другой комп у меня гоняет круглосуточно. С глюками сталкивался только в виде заторможенности в переключении вкладок в клиентах. От этого спасает перезапуск клиента. Поэтому приведённые способы решения проблем являются частными.

На мой взгляд действительно дело в утечки памяти. Где-то в оригинальном коде dc клиента не удаляется какой-то объект из-за чего происходит медленная утечка памяти, которая в дальнейшем проявляется глюками в ос.

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

а я использую грей - шара около террабайта, upload - 100 гигов в сутки, аптайм клиента - недели (клиент обновляю после перезагрузки компа) - при этом никаких глюков, все ок. Отключаю анимацию смайлов и все.
баг с анисмайлами - http://livedc.ucoz.ru/forum/2-16-40#3624 там же его решение

Бред написан. Я говорил не о выделении памяти, а об освобождении. И кроме этого простые пользователи ничего с этим поделать не смогут, поэтому пустые разговоры.

Это бесполезно. Рано или поздно глюк все равно проявится.
Чушь. До того, как на моей машине появились 2 хаба, всегда использовал спящий режим. Никаких глюков при этом не наблюдалось. Винда месяцами работала без перезагрузки.

Кстати, мне удалось ПОЛНОСТЬЮ избавиться от данного глюка в стронге. Для этого нужно было всего лишь откатиться на версию 2.05 . И самое интересное то, что глюк все равно время от времени дает о себе знать, только частота "приступов" уже не зависит от интенсивности использования стронга.

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

Те, кто ещё не понял, в чем первопричина глюка, могут посмотреть чейнджлог того же стронга, и им все станет ясно (я так думаю ) Так что единственный способ избавиться от глюка - перейти на старые версии софта.

Не компонент это. И даже не модуль. Это Явление .

Ни хрена себе "всего лишь".
Чур,на мой хаб Вы зайти с таким клиентом не сможете.

Вариант решения есть. Кто хорошо знает английский,пусть возьмёт ноги в руки и стучит если не напрямую в личку BM,то уж точно к нему на форум. Можно сказать,коллективная жалоба.

Поправим тег и зайдем .

Тут стучать надо не BM, а в фирму "Некрософт", потому как виновато в этих глюках, судя по всему, Visual Studio 2008.

На VS не надо гнать!
Я его активно юзаю, и никаких глюков в программах нету.

Тут дело именно в кривости написания, но никак не в VS!!!

Если только перепишете клиент. Потому что все 0.6* версии я тоже забаню.
Кстати,спешу уведомить,что StrongDC++ 2.05 автоматически умирает при получении информации о новейшей версии. Вряд ли это сделано просто так.

Зачем переписывать? Пару байт подправим, и всё.

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

И, чтобы не выглядеть голословным, выкладываю вылеченный стронг 2.05:

 StrongDC.rar ( 997.31 килобайт ) Кол-во скачиваний: 5

Заметно, что вы 'не программист и близко". Негоже не знать ветки развития клиентов и классификацию "Кто от кого произошел"....

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



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

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



Да, по крайней мере в грее - помогает хорошо. Насчет темки, не читал, нужно посмотреть.



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

Глупости говорите. То же самое практикуется для ApexDC++ и RSX++. И это только известные мне клиенты.

Вот Вам делать нехер,ей-богу.

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

Спасибо. Видите ли,я считаю это комплиментом!