Вышел (http://lists.freedesktop.org/archives/xorg-announce/2010-Oct...) корректирующий релиз xorg-server 1.9.1, содержащий исправления ошибок, накопившихся в ветке 1.9.x. По сравнению с выпуском 1.9.0 в новой версии отмечено 40 исправлений, большинство из которых нацелены на повешение стабильности, устранение утечек памяти и производительности. Из улучшений отмечено добавление поддержки архитектуры nds32 и реализация поддержки расширения RandR для архитектуры XQuartz DDX.URL: http://lists.freedesktop.org/archives/xorg-announce/2010-Oct...
Новость: http://www.opennet.me/opennews/art.shtml?num=28398
> устранение утечек памяти и производительности.Всем, думаю, и без того понятненько. Ну а что делать-то остаётся? Кроме как, устранять производительность наравне с утечками памяти ;)
>устранение утечек памятиСи такой си. Проект разивается столько лет и досихпор страдает утечками, чинят их почти в каждом релизе.
Там такие утечки памяти, что оно копейки по сравнению с тем что штатно жрётся в софте написанном на "не текущих"
Никто и неимеет ввиду жабоподобные монстры. Даже смартпоинтеры в с++, которым уже 200 лет, очень сильно уменьшают вероятность утечек.
если все же сходить по ссылкам и прочитать, то будет понятно, что утечка была ТОЛЬКО в опенконфигфайл и опенконфигдир.
а если чуть подумать, то можно понять, что не все утечки в мире происходят из-за указателей.
к примеру, создать мягкую ссылку в таком конфигдире и забыть про проверки сего факта в прога, то при его сканировании можно так не кисло памяти покушать.
вон и айзен пример для жабы приводил.
так что панацеи от крифых рук не бывает. ни в С, ни в С++, ни java. чтобы маркетологи при этом не говорили.
Если еще немного подумать, то смартпоинтеры - лишь пример того, как можно обезопасить себя. Иксы текут уже довольно давно, и последний раз я это наблюдал 2 дня назад - несколько раз Х сервер выжирал по 1гб памяти. Наверно, это как-то связано с открытыми дровами для нвидии и включенном ускорении в хроме, но какая разница.
Конечно, от кривых рук не спасет, но сделает код более устойчивым, например.
>фи. как толсто. брехня же.Тролефобия? Если ты не видел, это не озночает, что этого нет.
>лично я даже САБЖЕВУЮ утечку не видел. а я постоянно сижу на не стабильной ветке.
Как оно связано?
>угу. жду продолжения.
Какого продолжения? Как правильно писать код? Почитай книжки по проектированию.
>и желательно ближе к сабжу.
Сабж - это то, что на сях сложные проекты писать не просто и хватит лажать, например, плюсы и говорить о замеательности чистого си.
>Тролефобия?однозначно! :D
>Если ты не видел, это не озночает, что этого нет.жду от вас ссылку, где вы зафиксировали этот баг. иначе не было.
всё остальное - в детский сад.
>жду от вас ссылку, где вы зафиксировали этот баг. иначе не было.Лениво же. Вчера обновился блоб в рпмфьюжн и все стало нормально.
>Иксы текут уже довольно давно, и последний раз я это наблюдал 2 дня назад - несколько раз Х сервер выжирал по 1гб памяти.фи. как толсто. брехня же.
лично я даже САБЖЕВУЮ утечку не видел. а я постоянно сижу на не стабильной ветке.зы:
>Если еще немного подумать, то смартпоинтеры - лишь пример того, как можно обезопасить себя.угу. жду продолжения.
и желательно ближе к сабжу.
Кракен такой кракен. Он разивается столько лет и досихпор страдает утечками, чинят его почти каждый день. :D А читать он так и не научился, ровно как и внимательности :P Ну написано же, чёрненьким по беленькому "устранение утечек памяти и производительности"... т.е. "1. устранили утечки памяти, 2. устранили производительность" :-) конечно, всем понятно, что кракены на то и есть crackenы, чтобы на "си таком си" при компиляции уже написанного кода, разумеется, устраняли производительность у себя на компьютере... но остальным-то оно зачем? :D Ну прям всё бы тебе поломать ;)
> Проект разивается столько лет и досихпор страдает утечками, чинят их почти в каждом релизе.А что, лучше было бы если бы он был на жаве, и просто жрал памяти в 50 раз больше?
На Java тоже утечки памяти случаются из-за неконтролируемого создания новых объёктов, на которые не обnullяются ссылки внутри долгоживущих объектов. GC не видит такие якобы "ненужные" объекты и не удаляет их. Поэтому единственная стратегия не создавать утечек памяти в Java: создавать только долгоживущие объекты, время жизни которых сопоставимо с временем жизни приложения, и избегать создания короткоживущих объектов, которые могут затесаться в какой-нибудь контейнер и осесть там навсегда (уйти из области видимости программиста).
> Си такой си. Проект разивается столько лет и досихпор страдает утечками, чинят их почти в каждом релизе.Как будто на других ЯП программы не страдают утечками, ага. Наверное, есть ЯП которые методом телепатии определяют - когда вон та сущность более програмеру уже не нужна :). И программу пишут сами. Ну разве что пых какойнить взять. С таймаутом на максимальное время работы скрипта ножом к горлу, как обычно. Там даже если что и утечет то не более чем на сколько-то секунд :). Хотите иксы работающие 30 секунд, а потом - бабах? Это кстати и на си реализуемо :)
> что пых какойнить взять. С таймаутом на максимальное время работы скрипта
> ножом к горлу, как обычно. Там даже если что и утечет
> то не более чем на сколько-то секунд :).Поставь max_execution_time=0 и теки себе на здоровье :) Хотя в этом случае, наверное, веб-серверный таймаут сработает.
Ну ваще, если разработчик грамотный, то с современным си++ у него меньше шансов налажать с памятью, например.
ну если он действительно грамотный, то уж точно знает о дебагерах, профилировщиках и прочих средствах проверки кода на распространенные и типовые ошибки.
а последние вообще можно в кроне на ночь пускать и утром письма читать за чашкой кофе.
в чем они не помогают, так в логике самого кода. но в этом и выбор языка тоже не помогает.
Искать ошибки - это, конечно, нужно. Но хорошо, когда есть определенные техники, которые заботятся о том, чтобы типовых ошибок не допускать. Паттерны - одно из таки средств. Ну и статическая типизация очень сильно помогает.
это и есть - определённые техники. :D
а от пузырького метода не спасают ни паттерны, ни шаблоны, ни статическая типизация, ни другие умные слова. см.примеры выше.
Я не знаю, что такое "пузырького метода", но я и не утверждаю, что описанные мной техники - панацея от всего. Это лишь хорошие методы, которые не дают делать некоторые ошибки во время написания кода. В случае, когда работаешь с крупным проектом, и где разработчики меняются регулярно это самое оно.
Анализаторы кода вылавливают далеко не все, например. Профилирование - немного из другой области, вряд ли поможет оно, если в коде ошибка, которая возникает при редких обстоятельствах. Оно больше для устранения узких мест подходит. Дебагер также мало полезен, когда ошибка выскакивает у кого-то. Так что сомнительны твои техники.
Кстати, шаблоны-то вообще не к месту приведены. Это лишь инструмент, чтоб писать обобщенный код при статической типизации, да.
да все ваши громкие слова - не к месту.
> устранение утечек памяти и производительности
>устранение производительностиМолодцы, пока справляются :D
Не заметил устранения производительности по сравнению с 1.9.0.
Обновился я с 1.8.1 до 1.9 вчера. Иксы не стартовали: видите ли, xdm хочет xdm-setup, которого впринципе не существует! Нашёл как отредактировать скрипт xdm, заодно проприетарный драйвер nVidia установил последний (думал, проблема в нём).Но не это главное. После этого пошли артефакты. Запустил BOINC, распределённые вычисления, видеокарта проектом GPUGRID, запущенном в нём, также используется. Но ещё ничего не успело расчитываться, только скачиваться 10 мегабайт исходных данных для расчёта, как пошли артефакты. Перед этим монитор выключался для экономии энергии, а закачка 8 раз обрывалась. top и ps говорят что acid6.04.x86_64 в памяти момент артефактов не было. Температура GPU 45, CPU 35. А потом всё зависло.
Весь вечер не мог найти причину сбоя. Иксы ли это или новый драйвер (со старыми такого за месяц не произошло), всё искал алгоритм вызова бага. У кого-нибудь было так, как на этом видео? Только комментарии голосом не слшайте - я заблуждался.
>Только комментарии голосом не слшайте - я заблуждался.Видит б-г, тебе полопеннета хотело бы помочь, но иной раз твой поток сознания настолько велик, что не каждый рассудок готов его принять и вместить
иксы стали работать нормально с рк 1.9.0.902
до этого были баги, но не связанные с видио (евдев в основном)
253 дрова работали и работают нормально (точно помню и в 901, и в 902)
260 на моей модели ноута виснут намертво. баг известный.
сарумян с форума нвидии молчит как рыба об лёд.
/253/256.53/
xhost +
command not found: xhost