Так это НОРМАЛЬНОГО СТАТИЧЕСКОГО анализатора.
Или может быть я всё проспал и такое уже есть?
Ну и ДИНАМИЧЕСКОГО - тоже. Про AQTime etc - я знаю, но в xCode - явно лучше. Он утечки показывает - ПРАКТИЧЕСКИ с точностью до строчки.
Понимаете - я был совсем "чайник" в xCode (хотя когда читал мануал - я СМЕЯЛСЯ - "ну что вы мне про подсчёт ссылок рассказываете - я же "гуру" в них, я же - "сам всё это придумал")... Но когда я запустил СТАТИЧЕСКИЙ анализатор кода - Я БЫЛ ПОРАЖЁН.. Он мне показал ТАКИЕ места, о которых бы я никогда бы не подумал..
А уж когда запустил ДИНАМИЧЕСКИЙ (Memory Leaks) - я был поражён ещё БОЛЬШЕ...
Это ТОЛЬКО у меня такие руки кривые? Или такие инструменты всё же востребованы на рынке?
Рассказать кстати - как я считаю количество неосвобождённых объектов в Delphi? Или неинтересно?
Или может быть я всё проспал и такое уже есть?
Ну и ДИНАМИЧЕСКОГО - тоже. Про AQTime etc - я знаю, но в xCode - явно лучше. Он утечки показывает - ПРАКТИЧЕСКИ с точностью до строчки.
Понимаете - я был совсем "чайник" в xCode (хотя когда читал мануал - я СМЕЯЛСЯ - "ну что вы мне про подсчёт ссылок рассказываете - я же "гуру" в них, я же - "сам всё это придумал")... Но когда я запустил СТАТИЧЕСКИЙ анализатор кода - Я БЫЛ ПОРАЖЁН.. Он мне показал ТАКИЕ места, о которых бы я никогда бы не подумал..
А уж когда запустил ДИНАМИЧЕСКИЙ (Memory Leaks) - я был поражён ещё БОЛЬШЕ...
Это ТОЛЬКО у меня такие руки кривые? Или такие инструменты всё же востребованы на рынке?
Рассказать кстати - как я считаю количество неосвобождённых объектов в Delphi? Или неинтересно?
>как я считаю количество неосвобождённых объектов в Delphi?
ОтветитьУдалитьfastmm умеет сразу из коробки - ReportMemoryLeaksOnShutdown.
Статический анализатор - видел о нем упоминание в форумах, название не помню, коммерческий и стоит прилично.
Это не статический анализ но все таки:
madExcept умеет ловить утечки памяти с указанием строк где они произошли.
fastmm сам по себе умеет многое.
Здесь подробнее по технике ловле утечек с помощью fastmm (сама статью по ссылке можно пропустить, основное в комментах)
http://tech.turbu-rpg.com/486/wanted-live-leak-detection-for-fastmm
-
Игорь
Насчёт подсчёта неосвобождённых объектов - интересная тема, пишите однозначно!
ОтветитьУдалитьОбязательно напишу тогда. Я сейчас немного ушёл в переход с Delphi 7 на Delphi XE3. Но край - уже виден. Всё больше и больше тестов проходит.
ОтветитьУдалитьВот относительно недавняя статья http://www.altdevblogaday.com/2011/12/24/static-code-analysis/ про статические анализаторы кода. Понятно, не для Delphi, а C++. Хотя и для Delphi что-то есть http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis
ОтветитьУдалитьPascal Analyzer/Codehealer смотрели? Audits/Metrics в среде Delphi есть.
Дело в том, что мне были бы интересны анализаторы родные. Встроенные в среду. А СВОИ проблемы - я уже лет 10-ть как - решил :-) Скоро опишу как. И поскольку у меня есть СВОИ инструменты. То ЧУЖИЕ "навесные" решения - интересны -только в плане идей. Но всё равно - ОГРОМНОЕ ЧЕЛОВЕЧЕСКОЕ СПАСИБО.
ОтветитьУдалитьЯ сейчас пишу БОЛЬШУЮ статью про подсчёт ссылок, контейнерные классы и т.п. На примесях конечно же. Там и про "следилку за объектами" будет. Но опубликую я её - когда закочу портирование на Delphi XE3. Ибо оно у меня теперь занимает 12 часов в сутки. Хочется добить...
ОтветитьУдалитьДа... Pascal Analyzer - я видел.. Пользовался.. Но не вкурил до конца если честно.. Но вещь - ПОЛЕЗНАЯ...
ОтветитьУдалитьЗа примеры ошибок и способы их решения, конкретные тесты, помогающие их выловить заранее спасибо! Кстати, был совсем недавно вебинар об ошибках при переходе в Delphi/Builder на x64. Там классы ошибок с адресной арифметикой показали. На viva64.com есть запись. Я понял, в XCode лучше, чем в Delphi, а в Visual Studio /analyze еще лучше :)
ОтветитьУдалитьDavid I говорил, что улучшить инструменты статического анализа - одна из самых важных задач развития Delphi. Теперь об этом еще и Марко Кэнту можно спросить.
ПОЖАЛУЙСТА! Буду рад помочь! Кидайте интересующие темы кстати если что. Опыт у меня - обширный. Но я пока не понял - что интересно людям, а что неинтересно. Я вот пытаюсь про примеси писать - но похоже - неинтересно. Давайте напишу про что-нибудь ещё... Если интересно... Я кроме БД и SQL - многое попробовал.. И рад бы поделиться...
ОтветитьУдалитьА примеры КОНКРЕТНЫХ тестов - ещё БУДУТ! Просто во-первых они должны КОМПИЛИРОВАТЬСЯ, а во-вторых - не нарушать права работодателя.
xCode - не лучше. Он просто - ДРУГОЙ.. А анализатор - ДА - очень полезный.. я им ОЧЕНЬ впечатлился... Мне даже сначала это показалось "магией"..
VS - не видел...
И ещё... Если вы в Москве, ну или недалеко (скажем в Твери или Питере или около того), то предлагаю - "попить пива"... Ну пообщаться лично.. ВСЕМ интересующимся кстати... Просто у меня с вербальным общением - вроде бы неплохо, а вот с письменным - БЕДА... Не всё я могу "на бумаге донести".. А на "пальцах" - может быть.. Ну и у вас я бы чего полезного почерпнул бы... Мне - было бы интересно...
У меня - ОЧЕНЬ умные и интересные коллеги, но я с ними уже ОЧЕНЬ давно работаю. А "снаружи" - лет 10-ть точно ни с кем не общался...
eurekalog тоже умеет ловить утечки
ОтветитьУдалитьСлышал о таком :-) СПАСИБО!
ОтветитьУдалитьПросто я то уже сижу на своих инструментах.. Но за информацию - СПАСИБО! Пишите ещё...
Про тесты кстати - http://18delphi.blogspot.com/2013/04/delphi-xe.html
ОтветитьУдалитьЭтот тест проходит конечно же. Но он - ПОЛЕЗНЫЙ.
madExcept - не слышал. Посмотрю обязательно. СПАСИБО!
ОтветитьУдалитьИдея на моих объектах - банальна. Я перекрываю NewInstance и FreeInstance через примеси и складываю все объекты в глобальную мапу. И на выходе вижу статистику неосвобождённых объектов. И если вчера статистики не было, а сегодня я что-то поправил - то я гоняю тесты и вижу статистику неосвобождённых объектов. Значит я - ЗНАЮ - где их искать. Ну и плюс информация из JEDI.
ОтветитьУдалитьПовторю то, что уже писали выше.
ОтветитьУдалитьДля поиска утечек памяти - бесплатный FastMM (полная версия - с fastmm.sf.net) отлично с этим справляется, показывая как число неосвобождённых объектов, так и название файла и номер строки в которой этот объект создавался. Помимо этого он также может показывать места где используются уже освобождённые объекты, интерфейсы (этим грешат некоторые разработчики компонентов), и проверять кучу на повреждения.
О борьбе с утечками памяти и использовании Eurekalog, Fastmm и MadExcept очень хорошо написал Gunsmoker. Вообще, очень рекомендую почитать (лучше даже прочитать) его блог - там очень много очень хорошо структурированного материала по отладке и поиску ошибок в коде.
О статическом анализе кода:
* В Delphi есть встроенные QA Audits. Их имеет смысл использовать если установлена Delphi в редакции Enterprise, Architect или Ultimate. В Professional редакции все самые интересные проверки отключены.
* Есть сторонние инструменты: Peganza Pascal Analyzer, Code Healer.
Но конечно, такого богатого выбора функционала как в лучших анализаторов для C/C++, в Delphi я не встречал.
Ещё раз :-) Когда я писал свой подсчёт объектов и памяти - никакой этой красоты не было :-) Да FastMM не было :-)
ОтветитьУдалитьА что до Enterprise - дорого. А в xCode - "из коробки". Чем и поразился. Собственно что и было написано.
А так - спасибо конечно :-) Буду читать. А блог gunsmoker'а - конечно читал/читаю. Проникся уж давно :-)
> Когда я писал свой подсчёт объектов и памяти - никакой этой красоты не было :-) Да FastMM не было :-)
ОтветитьУдалитьНо теперь они есть и про них известно. Чем своё лучше?
Да ничем :-) Кроме того, что своё - решение проверенное. А чужое - ещё смотреть надо. А вы просто так интересуетесь? :-)
ОтветитьУдалитьПросто, потому что интересно, есть ли ещё что-то в этой области, что ещё нереализовано в FastMM.
ОтветитьУдалитьНе могу сходу сказать. У меня у самого "реализовано" гораздо меньше, но "мне хватало". В FastMM реализовано - гораздо больше. И более общо. Наверное "мне" - хватит. Но не факт, что я сразу сменю "самокат" на "феррари".
ОтветитьУдалитьК чему я вообще про контроль за ресурсами? Да к тому, что по моим скромным наблюдениям - далеко не все о нём вообще когда-нибудь задумывались. Судя по тому открытому коду, который я видел. А видел я его - много.
Собственно - неплохо, что тема нашла хоть какой-то отклик. Я так понимаю, что у корифеев.
> К чему я вообще про контроль за ресурсами? Да к тому, что по моим скромным наблюдениям - далеко не все о нём вообще когда-нибудь задумывались. Судя по тому открытому коду, который я видел.
ОтветитьУдалитьЯ тут совсем недавно нашёл штуки 3 ошибки в сторонних библиотеках (платных, кстати).
А началось всё с того, что через некоторое время после очередного обновления 2х сторонних библиотек, программа начала плеваться Access Violation-ами. Причём плеваться только при открытии одной определённой формы. И каждый раз вылет происходил на разной строке в разных методах. Ну в общем, понятно что что-то портит память, но как же узнать кто именно? И тут на помощь пришёл FastMM. Повключал я у него все отладочные флаги, какие только нашёл, включая проверку целостности Heap-а при каждом выделении памяти, обнаружение использования освобождённых указателей (а контроль за утечками памяти и так всегда включен).
И тут началось. Вместо AV при открытии той формы, стал получать AV при старте программы, при выходе и ещё в паре мест. Как оказалось, одна из TMS-ных библиотек, спокойно обращается к указателям освобождённых объектов, как будто так и надо. И всё это даже каким-то чудом работает (т.е. конечно понятно каким), пока не включишь в проект FastMM с отладочными флагами. В общем, пока я искал того, кто у меня в программе память поганит, я исправил в TMS-ной библиотеке 2 или 3 таких ошибки. Причём, как оказалось, ни одна из них не была виновата в моём AV.
И только после, наконец, добрался до своей ошибки. И-таки даже нашёл и отписал автору, и автор поблагодарил и ответил, что он уже в курсе и прислал исправление, но это уже совсем другая история.
Я это всё к тому клоню, что Ferrari - оно такое Ferrari. ;)
Поучительно :-)
ОтветитьУдалитьЯ уж написал, что и у нас нашёл :-) Место, где ездят :-)
Более менее закончу с портированием, займусь теорией :-)
Я уж написал, что и у нас нашёл - http://18delphi.blogspot.com/2013/04/blog-post_4535.html
ОтветитьУдалить