The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Релиз системы Valgrind 3.8.0, нацеленной на выявление проблем при работе с памятью

14.08.2012 14:00

После двух лет разработки доступен релиз инструмента Valgrind 3.8.0, предназначенного для отладки работы с памятью, обнаружения утечек памяти и профилирования потребления памяти. В новой версии добавлена полная поддержка платформ MIPS32/Linux и X86/Android, а также частичная поддержка Mac OS X 10.8 (Mountain Lion). Обеспечена поддержка наборов инструкций POWER DFP, Intel AVX и AES. Добавлена поддержка новых дистрибутивов и системных инструментариев (glibc 2.16, gcc 4.7). Внесена большая порция оптимизаций производительности и сокращено потребление памяти. Добавлена поддержка реализаций malloc не из состава libc, что позволяет отлаживать программы, статически слинкованные с такими библиотеками, как TCMalloc и JEMalloc.

  1. Главная ссылка к новости (http://sourceforge.net/mailarc...)
Лицензия: CC-BY
Тип: Программы
Короткая ссылка: https://opennet.ru/34569-valgrind
Ключевые слова: valgrind, memory, debug
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (47) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 14:29, 14/08/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • –22 +/
    Языки без автоматического управления памятью должны остаться в прошлом веке
     
     
  • 2.2, Аноним (-), 14:44, 14/08/2012 [^] [^^] [^^^] [ответить]  
  • +11 +/
    Пока процессор и остальная обвязка не научится обрабатывать непосредственно высокоуровневые конструкции языков и реализовывать автоматическое управление памятью все уровни программирования от предметно ориентированного до машинного кода будут иметь свою нишу. И да, Вы полный неадекват.
     
     
  • 3.5, Аноним (-), 14:54, 14/08/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Пока процессор и остальная обвязка не научится обрабатывать непосредственно высокоуровневые конструкции языков и реализовывать автоматическое управление памятью все уровни программирования от предметно ориентированного до машинного кода будут иметь свою нишу.

    А после того, как они это научатся, мы получим аппаратно реализованные тормоза и глюки.

     
     
  • 4.6, Аноним (-), 15:01, 14/08/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Именно так. Хотел дописать, но подумал, что догадаются.

    Можно скорректировать:
    > ...не научится обрабатывать...

    на
    > ...не научится эффективно обрабатывать...

     
     
  • 5.8, Ag (ok), 15:29, 14/08/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Эльбрус-1, -2, барроузовские машины - на аппартное управление веделением ОП как то народ не жаловался. Особенно после GETMAIN/FREEMAIN :)
     
     
  • 6.9, Аноним (-), 15:37, 14/08/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Не вдаваясь в тонкости управления памятью в Эльбрус-1, -2, изначальный вопрос состоял в автоматической сборке мусора, что ИМХО более высокоуровнево, но может и ошибаюсь. В любом случае распространенность остальных систем и распространенность Эльбрус снижают полезность продолжения этой беседы до 0.
     
     
  • 7.10, Ag (ok), 15:56, 14/08/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Не вдаваясь в тонкости управления памятью в Эльбрус-1, -2, изначальный вопрос состоял
    > в автоматической сборке мусора, что ИМХО более высокоуровнево, но может и
    > ошибаюсь.

    Сборка мусора там как раз была. Эльбрусы да, не выжили. А барроузовская платформа вполне себе существует. Только сменила владельца.
    > В любом случае распространенность остальных систем и распространенность Эльбрус
    > снижают полезность продолжения этой беседы до 0.

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

     
     
  • 8.14, Alatar (ok), 16:43, 14/08/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Ну почему же В оборонке они используются Да и вот, например - http sdelanoun... текст свёрнут, показать
     
     
  • 9.21, Аноним (-), 17:55, 14/08/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Интересно, почему США или там китай не занимаются созданием таких сайтов Может,... текст свёрнут, показать
     
     
  • 10.31, Аноним (-), 00:21, 15/08/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Как это не занимаются Они просто делают это на гораздо более мощном уровне www ... текст свёрнут, показать
     
     
  • 11.35, Аноним (-), 02:12, 15/08/2012 [^] [^^] [^^^] [ответить]  
  • +/
    cnn com не занимается коллекцией всего булшита мира по принципу сделано в сша ... текст свёрнут, показать
     
  • 2.3, Аноним (-), 14:45, 14/08/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Вместе с вменяемыми требованиями к оперативной памяти. Со всякими явами и питонами уже сейчас 4х гиг не хватает...
     
     
  • 3.12, Vkni (ok), 16:21, 14/08/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Вместе с вменяемыми требованиями к оперативной памяти. Со всякими явами и питонами
    > уже сейчас 4х гиг не хватает...

    Ну не надо говно брать. Тот же OCaml жрёт очень мало, компилирует значительно быстрее С++, а скорость выполнения примерно такая же.

     
     
  • 4.19, Аноним (-), 17:52, 14/08/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Ну не надо гoвно брать.

    Кто ж виноват что громче всего орущие скриптокиды обычно про него вещают?

    > Тот же OCaml жрёт очень мало, компилирует
    > значительно быстрее С++, а скорость выполнения примерно такая же.

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

     
     
  • 5.34, Vkni (ok), 01:27, 15/08/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Ну и как, рискнули бы вы прокатиться на авто где памятью будет
    > автоматически рулить в критичных системах (отказ которых ведет к ДТП) это
    > нечто?

    Эээ, я, знаете, авто никогда не программировал. И большая часть программистов на С - тоже.

    Кроме того, на авто, где отказ ПО ведёт к ДТП, я бы предпочёл вообще не ездить. Вне зависимости от того, на чём это ПО написано. (внезапная остановка двигателя к ДТП не приводит)

     
     
  • 6.36, Аноним (-), 02:30, 15/08/2012 [^] [^^] [^^^] [ответить]  
  • +/
    А уж жаба-скриптеры и подавно И вот поди ж ты - люди делают вполне себе надежны... большой текст свёрнут, показать
     
     
  • 7.43, Руслан Зиганшин (ok), 07:21, 15/08/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > В том числе и с критичными функциями возложенными на софт

    Критичные функции _никогда_ нельзя полностью возлагать на софт. За подробностями гуглите Therac-25 (спойлер: медицинский прибор, у которого отключили аппаратную блокировку слишком мощного излучения, что (вместе с кривой прошивкой) привело к смерти нескольких человек)

     
     
  • 8.46, arisu (ok), 20:39, 15/08/2012 [^] [^^] [^^^] [ответить]  
  • +/
    а в железе багов не бывает, ага какая разница, на что там возлагается тестиров... текст свёрнут, показать
     
  • 2.4, grondek (ok), 14:46, 14/08/2012 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Пишите аккуратно и не надо автоматически управлять памятью.

    А с помощью valgrind'а отладка производится быстро и удобно.

     
     
  • 3.7, ВовкаОсиист (ok), 15:14, 14/08/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Да пускай пишет на говно-языках "будущего". Ему больше ниначём другом писать нельзя. Криворукость головного мозга.
     
  • 3.11, vkni (?), 16:19, 14/08/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Пишите аккуратно и не надо автоматически управлять памятью.

    Это совет никогда не делать ошибок. :-)

     
     
  • 4.20, Аноним (-), 17:53, 14/08/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Это совет никогда не делать ошибок. :-)

    На си можно вообще не оперировать выделением памяти. При этом ошибки выделения памяти исключены чисто технически. Если у вас нет malloc то и юзать его вы не сможете. В фирмварях где нужна железобетонная предсказуемость и совершенно неприемлим отказ в невнятных условиях через полгода работы - так и делается.

     
     
  • 5.32, pavlinux (ok), 01:10, 15/08/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > На си можно вообще не оперировать выделением памяти.

    Все на константные массивы!!! :)
    И кстати, массивы переменной длины уже давно в стандарте.

     
     
  • 6.38, Аноним (-), 02:34, 15/08/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Все на константные массивы!!! :)

    В критичных применениях есть и такое. Вплоть до запрета в ответственных применениях адресной арифметики вообще. А как раз чтоб не нарваться на факап лишний раз. Вплоть до того что программа просто не собирается если такое в ней есть.

    > И кстати, массивы переменной длины уже давно в стандарте.

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

     
  • 5.33, Vkni (ok), 01:24, 15/08/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > На си можно вообще не оперировать выделением памяти.

    Это вы так тонко советуете вообще программы на С не писать? Разумно, конечно. Всё-таки, глупо писать программы, не выжимающие что-то специфическое из железа, на портабельном ассемблере, когда есть множество других языков.

     
     
  • 6.39, Аноним (-), 02:38, 15/08/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >> На си можно вообще не оперировать выделением памяти.
    > Это вы так тонко советуете вообще программы на С не писать?

    Почему же. На нем вполне можно писать. И даже очень ответственные штуки, которые на чем-то еще пожалуй фиг напишешь так же предсказуемо.

    > Разумно, конечно.

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

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

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

     
  • 2.13, kurokaze (ok), 16:42, 14/08/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Расскажи это Apple, пусть заменят ObjC на жабку, сынку
     
     
  • 3.15, VoDA (ok), 16:53, 14/08/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Расскажи это Apple, пусть заменят ObjC на жабку, сынку

    Их Oracle затроллит, так что ObjC так и будут строгать )))

     
  • 3.17, Аноним (-), 17:41, 14/08/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >Расскажи это Apple, пусть заменят ObjC на жабку, сынку

    ObjC более продвинутый и современный язык чем Java, к тому же в нём тоже есть автомитическая сборка мусора (опционально)

     
     
  • 4.30, anonymous (??), 23:32, 14/08/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Уже выпилили, зато запилили ARC
     
  • 2.18, Аноним (-), 17:48, 14/08/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Языки без автоматического управления памятью должны остаться в прошлом веке

    Довольно лицемерная заява в свете того что недавно был представлен инструмент для борьбы с утечками памяти в ... JS.

    p.s. но я искренне желаю вам чтобы у таракашки управляющего "электронным газом" или ABS невовремя кончилась память. Это было бы заслуженным наказанием за общую идиотию и неспособность смотреть вокруг и видеть что-то кроме себя и своих задач.

     
  • 2.24, Пиу (?), 19:50, 14/08/2012 [^] [^^] [^^^] [ответить]  
  • +/
    мнение похаписта очень ценно для нас, пожалуйста продолжайте
     
  • 2.25, Карбофос (ok), 19:52, 14/08/2012 [^] [^^] [^^^] [ответить]  
  • +/
    весьма толсто, в стиле iZen
     
  • 2.44, mad_fashist (ok), 12:46, 15/08/2012 [^] [^^] [^^^] [ответить]  
  • +/
    C#-compatible programmer detected.
     

  • 1.16, ryzhov_al (ok), 17:07, 14/08/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    В OpenWRT и производных появился в нативном виде и прекрасно работает на крохотныъ embedded системах. Трижды рулез!
     
  • 1.22, Аноним (-), 19:05, 14/08/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    В D сборка мусора реализована без всяких ВМ.
     
     
  • 2.23, Аноним (-), 19:07, 14/08/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Так что можно спокойно писать на машинозависимых языках не задумываясь об утечках памяти. Скорее бы ...
     
     
  • 3.27, VoDA (ok), 20:01, 14/08/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Так что можно спокойно писать на машинозависимых языках не задумываясь об утечках
    > памяти. Скорее бы ...

    А зачем?

    Машино-зависимые хороши только когда используемых платформ/железок довольно мало. Как только видов железа становится много, так сразу абстракции/VM/машино-независимость.


    PS C# - машино-зависимый язык. Оно работает только на x86 и x86 64 bit ;)))

     
     
  • 4.28, Аноним (-), 21:10, 14/08/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > PS C# - машино-зависимый язык. Оно работает только на x86 и x86 64 bit ;)))

    И только в виндовсе, по большому счету. Даже кроссплатформенного набора виджетов нету.

     
  • 4.37, ... (?), 02:30, 15/08/2012 [^] [^^] [^^^] [ответить]  
  • +/
    http://www.mono-project.com/Supported_Platforms - мужики-то не знали.
     
     
  • 5.40, Аноним (-), 02:42, 15/08/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > http://www.mono-project.com/Supported_Platforms - мужики-то не знали.

    Мужики читать не научились. В какоме месте непонимание того что стандартного кроссплатформенного набора виджетов - нет? По поводу чего начинаются извращения, когда вместо paint.net появляется наполовину переписанная pinta. Такой вот хреновый written once, runs everywhere, что даже гтк или куть какой-нибудь более кроссплатформенный. По крайней мере, программы на GTK или Qt не требуется переписывать наполовину при переносе на иную ОС. Как максимум - перекомпилить.

     
     
  • 6.41, ... (?), 03:43, 15/08/2012 [^] [^^] [^^^] [ответить]  
  • +/
    1. Мой комментарий относился к "x86 и x86 64" предыдущего оратора.
    2. Язык программирования никоим образом не связан с "стандартный кроссплатформенный набор виджетов". Gtk# - "стандартный кроссплатформенный набор виджетов" для _платформы_ mono. Windows.Forms - стандартный _не_ кроссплатформенный набор виджетов для _платформы_ .NET.
    4. paint.net - столько раз обсуждалось почему так, чтоповоторять это сдесь - просто бессмысленно.
    5. Покажите-ка мне программу на Qt или Gtk которая будет кроссплатформенно двигать курсом мыши, работу с окнами (взять дескриптор текущего выделенного окна чужого приложения, у найти у него 3-й дочерний виджет и установить ему какие-либо свойства), установить тему курсоров/окон. Не реализуя нескольких различных вариантов для Windows и Linux. Правда, очень интересно было-бы взглянуть.
     
     
  • 7.42, ананим (?), 06:37, 15/08/2012 [^] [^^] [^^^] [ответить]  
  • +/
    пятый пункт сразу за слив считать?
    или одумаетесь?

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

    от подобных манипуляций уже даже мс отказывается (зарывая винапи в вин8рт)

     
     
  • 8.45, ... (?), 13:37, 15/08/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Пятый пункт был приведен для того, чтобы показать что утверждение По крайней ме... текст свёрнут, показать
     
  • 2.26, VoDA (ok), 19:58, 14/08/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Сборка мусора либо автоматическая либо ручная.

    То, что приложение можно запустить без VM - ни о чем не говорит. Ту же java можно собирать в нативные бинари. А сборка мусора как была автоматической, так и остается ;)))

     
     
  • 3.29, Аноним (-), 21:10, 14/08/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Сборка мусора либо автоматическая либо ручная.

    Вообще, бывали адекватные потуги - разрешить и так и сяк.

     
     
  • 4.47, VoDA (ok), 10:05, 24/08/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >> Сборка мусора либо автоматическая либо ручная.
    > Вообще, бывали адекватные потуги - разрешить и так и сяк.

    потуги были, а вот результат в мэйнстриме не виден. увы.

     
     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру