Для получения триального ключа
заполните форму ниже
Team License (базовая версия)
Enterprise License (расширенная версия)
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

** На сайте установлена reCAPTCHA и применяются
Политика конфиденциальности и Условия использования Google.
Запросите информацию о ценах
Новая лицензия
Продление лицензии
--Выберите валюту--
USD
EUR
GBP
RUB
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

** На сайте установлена reCAPTCHA и применяются
Политика конфиденциальности и Условия использования Google.
Для получения лицензии для вашего открытого
проекта заполните, пожалуйста, эту форму
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

** На сайте установлена reCAPTCHA и применяются
Политика конфиденциальности и Условия использования Google.
Для получения лицензии для вашего открытого
проекта заполните, пожалуйста, эту форму
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

** На сайте установлена reCAPTCHA и применяются
Политика конфиденциальности и Условия использования Google.
Мне интересно попробовать плагин на:
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

** На сайте установлена reCAPTCHA и применяются
Политика конфиденциальности и Условия использования Google.
Ваше сообщение отправлено.

Мы ответим вам на


Если вы так и не получили ответ, пожалуйста, проверьте папку
Spam/Junk и нажмите на письме кнопку "Не спам".
Так Вы не пропустите ответы от нашей команды.

>
>
>
В PVS-Studio появилась поддержка GNU Ar…

В PVS-Studio появилась поддержка GNU Arm Embedded Toolchain

23 Окт 2018

Встраиваемые системы давно и прочно вошли в нашу жизнь. Требования к их стабильности и надежности очень высоки, а исправление ошибок обходится дорого. Поэтому для embedded разработчиков особенно актуально регулярное использование специализированных инструментов для обеспечения качества исходного кода. Эта статья расскажет о появлении поддержки GNU Arm Embedded Toolchain в анализаторе PVS-Studio и дефектах кода, найденных в проекте Mbed OS.

0588_GNU_Embedded_ru/image1.png

Введение

Анализатор PVS-Studio уже поддерживает несколько коммерческих компиляторов для встраиваемых систем, например:

Теперь к поддержке добавлен еще один инструмент разработчика - GNU Embedded Toolchain.

GNU Embedded Toolchain - коллекция компиляторов от компании Arm, основанная на GNU Compiler Collection. Первый официальный релиз состоялся в 2012 году, и с тех пор проект развивается вместе с GCC.

Основное предназначение GNU Embedded Toolchain - генерация кода, работающего на "голом железе" (bare metal), то есть напрямую на процессоре без прослойки в виде операционной системы. В комплект поставки входят компиляторы для C и C++, ассемблер, набор утилит GNU Binutils и библиотека Newlib. Исходный код всех компонентов полностью открыт и распространяется по лицензии GNU GPL. С официального сайта можно скачать версии под Windows, Linux и macOS.

Mbed OS

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

0588_GNU_Embedded_ru/image2.png

Хотя основной целью статьи является рассказать о поддержке GNU Embedded Toolchain, много про это написать сложно. Тем более, что читатели наших статей наверняка ждут описания каких-то интересных ошибок. Что же, не будем обманывать их ожидания и запустим анализатор на проекте Mbed OS. Это операционная система с открытым исходным кодом, которая разрабатывается при участии компании Arm.

Официальный сайт: https://www.mbed.com/

Исходный код: https://github.com/ARMmbed/mbed-os

Выбор на Mbed OS пал не случайно, вот как описывают проект его авторы:

Arm Mbed OS is an open source embedded operating system designed specifically for the "things" in the Internet of Things. It includes all the features you need to develop a connected product based on an Arm Cortex-M microcontroller, including security, connectivity, an RTOS and drivers for sensors and I/O devices.

Это идеальный проект для сборки с помощью GNU Embedded Toolchain, особенно с учетом участия Arm в его разработке. Сразу оговорюсь, что цели найти и показать как можно больше ошибок в конкретном проекте у меня не было, поэтому результаты проверки рассмотрены кратко.

Ошибки

В ходе проверки кода Mbed OS анализатор PVS-Studio выдал 693 предупреждения, 86 из них - с приоритетом high. Я не буду подробно рассматривать их все, тем более что многие из них повторяются или не представляют особого интереса. Например, анализатор выдал много предупреждений V547 (Expression is always true/false), относящихся к однотипным фрагментам кода. Анализатор можно настроить, чтобы существенно сократить количество ложных и неинтересных срабатываний, но такой задачи при написании статьи не ставилось. Желающие могут посмотреть пример подобной настройки, описанной в статье "Характеристики анализатора PVS-Studio на примере EFL Core Libraries, 10-15% ложных срабатываний".

Для статьи я отобрал несколько интересных ошибок, чтобы продемонстрировать работу анализатора.

Утечки памяти

Начнем с распространенного класса ошибок в C и C++ - утечек памяти.

Предупреждение анализатора: V773 CWE-401 The function was exited without releasing the 'read_buf' pointer. A memory leak is possible. cfstore_test.c 565

int32_t cfstore_test_init_1(void)
{
   ....
  read_buf = (char*) malloc(max_len);
  if(read_buf == NULL) {
    CFSTORE_ERRLOG(....);
    return ret;
  }
  ....
  while(node->key_name != NULL)
  {
    ....
    ret = drv->Create(....);
    if(ret < ARM_DRIVER_OK){
      CFSTORE_ERRLOG(....);
      return ret;              // <=
    }
  ....
  free(read_buf);
  return ret;
}

Классическая ситуация при работе с динамической памятью. Выделенный с помощью malloc буфер используется только внутри функции и освобождается перед выходом. Проблема в том, что этого не происходит, если функция прекращает работу досрочно. Обратите внимание на одинаковый код в блоках if. Скорее всего, автор скопировал верхний фрагмент и забыл добавить вызов free.

Еще пример, аналогичный предыдущему.

Предупреждение анализатора: V773 CWE-401 The function was exited without releasing the 'interface' pointer. A memory leak is possible. nanostackemacinterface.cpp 204

nsapi_error_t Nanostack::add_ethernet_interface(
    EMAC &emac,
    bool default_if,
    Nanostack::EthernetInterface **interface_out,
    const uint8_t *mac_addr)
{
  ....
  Nanostack::EthernetInterface *interface;
  interface = new (nothrow) Nanostack::EthernetInterface(*single_phy);
  if (!interface) {
    return NSAPI_ERROR_NO_MEMORY;
  }

  nsapi_error_t err = interface->initialize();
  if (err) {
    return err;              // <=
  }

  *interface_out = interface;
  return NSAPI_ERROR_OK;
}

Указатель на выделенную память возвращается через выходной параметр, но только если вызов initialize прошел успешно, а в случае ошибки происходит утечка, потому что локальная переменная interface выходит из области видимости, и указатель попросту теряется. Здесь следовало бы либо вызвать delete, либо хотя бы отдать хранящийся в переменной interface адрес наружу в любом случае, чтобы об этом мог позаботиться вызывающий код.

Memset

Использование функции memset часто приводит к ошибкам, примеры связанных с ней проблем можно посмотреть в статье "Самая опасная функция в мире С/С++".

Рассмотрим такое предупреждение анализатора:

V575 CWE-628 The 'memset' function processes '0' elements. Inspect the third argument. mbed_error.c 282

mbed_error_status_t mbed_clear_all_errors(void)
{
    ....
    //Clear the error and context capturing buffer
    memset(&last_error_ctx, sizeof(mbed_error_ctx), 0);
    //reset error count to 0
    error_count = 0;
    ....
}

Программист намеревался обнулить память, занимаемую структурой last_error_ctx, но перепутал местами второй и третий аргумент. В результате 0 байт заполняется значением sizeof(mbed_error_ctx).

Точно такая же ошибка присутствует сотней строк выше:

V575 CWE-628 The 'memset' function processes '0' elements. Inspect the third argument. mbed_error.c 123

Безусловный оператор 'return' в цикле

Предупреждение анализатора: V612 CWE-670 An unconditional 'return' within a loop. thread_network_data_storage.c 2348

bool thread_nd_service_anycast_address_mapping_from_network_data (
          thread_network_data_cache_entry_t *networkDataList,
          uint16_t *rlocAddress,
          uint8_t S_id)
{
  ns_list_foreach(thread_network_data_service_cache_entry_t,
                  curService, &networkDataList->service_list) {
    // Go through all services
    if (curService->S_id != S_id) {
      continue;
    }
    ns_list_foreach(thread_network_data_service_server_entry_t,
                    curServiceServer, &curService->server_list) {
      *rlocAddress = curServiceServer->router_id;
      return true;                     // <=
    }
  }
  return false;
}

В этом фрагменте ns_list_foreach - это макрос, который раскрывается в оператор for. Внутренний цикл выполняет не больше одной итерации из-за вызова return сразу после строки, в которой инициализируется выходной параметр функции. Возможно, этот код работает так, как задумано, но использование внутреннего цикла выглядит в этом контексте довольно странно. Скорее всего, инициализация rlocAddress и выход из функции должны выполняться по условию, или от внутреннего цикла можно избавиться.

Ошибки в условиях

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

https://pvs-studio.com/ru/docs/warnings/v547/V547 CWE-570 Expression 'pcb->state == LISTEN' is always false. lwip_tcp.c 689

enum tcp_state {
  CLOSED      = 0,
  LISTEN      = 1,
  ....
};

struct tcp_pcb *
tcp_listen_with_backlog_and_err(struct tcp_pcb *pcb, u8_t backlog, err_t *err)
{
  ....
  LWIP_ERROR("tcp_listen: pcb already connected",
             pcb->state == CLOSED,
             res = ERR_CLSD; goto done);

  /* already listening? */
  if (pcb->state == LISTEN) {               // <=
    lpcb = (struct tcp_pcb_listen*)pcb;
    res = ERR_ALREADY;
    goto done;
  }
  ....
}

Анализатор считает, что условие pcb->state == LISTEN всегда ложно, давайте разберемся, почему.

Перед оператором if используется макрос LWIP_ERROR, который по логике своей работы напоминает assert. Его объявление выглядит так:

#define LWIP_ERROR(message, expression, handler) do { if (!(expression)) { \
  LWIP_PLATFORM_ERROR(message); handler;}} while(0)

Если условие ложно, макрос сообщает об ошибке и выполняет код, переданный через параметр handler, в этом фрагменте кода - безусловный переход с использованием goto.

В данном примере проверяется условие 'pcb->state == CLOSED', то есть переход на метку done происходит в случае, когда pcb->state имеет любое другое значение. Оператор if, следующий за вызовом LWIP_ERROR, проверяет pcb->state на равенство LISTEN, но это условие никогда не выполняется, потому что state в этой строке может содержать только значение CLOSED.

Рассмотрим еще одно предупреждение, связанное с условиями: V517 CWE-570 The use of 'if (A) {...} else if (A) {...}' pattern was detected. There is a probability of logical error presence. Check lines: 62, 65. libdhcpv6_server.c 62

static void libdhcpv6_address_generate(....)
{
  ....
  if (entry->linkType == DHCPV6_DUID_HARDWARE_EUI64_TYPE) // <=
  {
    memcpy(ptr, entry->linkId, 8);
   *ptr ^= 2;
  }
  else if (entry->linkType == DHCPV6_DUID_HARDWARE_EUI64_TYPE)// <=
  {
    *ptr++  = entry->linkId[0] ^ 2;
    *ptr++  = entry->linkId[1];
  ....
  }
}

Здесь if и else if проверяют одно и то же условие, в результате чего код в теле else if никогда не выполняется. Такие ошибки часто возникают при написании кода методом 'copy-paste'.

Ownerless expression

Посмотрим напоследок на забавный фрагмент кода.

Предупреждение анализатора: V607 Ownerless expression '& discover_response_tlv'. thread_discovery.c 562

static int thread_discovery_response_send(
                        thread_discovery_class_t *class,
                        thread_discovery_response_msg_t *msg_buffers)
{
  ....
  thread_extension_discover_response_tlv_write(
             &discover_response_tlv, class->version,
             linkConfiguration->securityPolicy);
  ....
}

А теперь давайте взглянем на объявление макроса thread_extension_discover_response_tlv_write:

#define thread_extension_discover_response_tlv_write \
( data, version, extension_bit)\
(data)

Макрос раскрывается в аргумент data, то есть его вызов внутри функции thread_discovery_response_send после препроцессирования превращается в выражение (&discover_response_tlv).

0588_GNU_Embedded_ru/image3.png

У меня комментариев нет. Наверное, это не ошибка, но такой код всегда вводит меня в состояние, подобному изображению на картинке :).

Заключение

Список поддерживаемых в PVS-Studio компиляторов пополнился. Если у вас есть проект, предназначенный для сборки с помощью GNU Arm Embedded Toolchain, предлагаю попробовать проверить его с помощью нашего анализатора. Скачать демонстрационную версию можно здесь. Обратите также внимание на вариант с бесплатной лицензией, который подходит для некоторых небольших проектов.

Популярные статьи по теме
Бесплатный PVS-Studio для тех, кто развивает открытые проекты

Дата: 22 Дек 2018

Автор: Андрей Карпов

В канун празднования нового 2019 года команда PVS-Studio решила сделать приятный подарок всем контрибьюторам open-source проектов, хостящихся на GitHub, GitLab или Bitbucket. Им предоставляется возмо…
Технологии, используемые в анализаторе кода PVS-Studio для поиска ошибок и потенциальных уязвимостей

Дата: 21 Ноя 2018

Автор: Андрей Карпов

Краткое описание технологий, используемых в инструменте PVS-Studio, которые позволяют эффективно обнаруживать большое количество паттернов ошибок и потенциальных уязвимостей. Статья описывает реализа…
Главный вопрос программирования, рефакторинга и всего такого

Дата: 14 Апр 2016

Автор: Андрей Карпов

Вы угадали, ответ - "42". Здесь приводится 42 рекомендации по программированию, которые помогут избежать множества ошибок, сэкономить время и нервы. Автором рекомендаций выступает Андрей Карпов - тех…
Эффект последней строки

Дата: 31 Май 2014

Автор: Андрей Карпов

Я изучил множество ошибок, возникающих в результате копирования кода. И утверждаю, что чаще всего ошибки допускают в последнем фрагменте однотипного кода. Ранее я не встречал в книгах описания этого …
PVS-Studio для Java

Дата: 17 Янв 2019

Автор: Андрей Карпов

В седьмой версии статического анализатора PVS-Studio мы добавили поддержку языка Java. Пришло время немного рассказать, как мы начинали делать поддержку языка Java, что у нас получилось и какие дальн…
Как и почему статические анализаторы борются с ложными срабатываниями

Дата: 20 Мар 2017

Автор: Андрей Карпов

В своей предыдущей статье я писал, что мне не нравится подход, при котором статические анализаторы кода оцениваются с помощью синтетических тестов. В статье приводился пример, воспринимаемый анализат…
Как PVS-Studio оказался внимательнее, чем три с половиной программиста

Дата: 22 Окт 2018

Автор: Андрей Карпов

PVS-Studio, как и другие статические анализаторы кода, часто выдаёт ложные срабатывания. Но не стоит спешить считать странные срабатывания ложными. Это короткая история о том, как PVS-Studio вновь ок…
Зло живёт в функциях сравнения

Дата: 19 Май 2017

Автор: Андрей Карпов

Возможно, читатели помнят мою статью под названием "Эффект последней строки". В ней идёт речь о замеченной мной закономерности: ошибка чаще всего допускается в последней строке однотипных блоков текс…
Любите статический анализ кода!

Дата: 16 Окт 2017

Автор: Андрей Карпов

Я в шоке от возможностей статического анализа кода, хотя сам участвую в разработке инструмента PVS-Studio. На днях я был искренне удивлён тому, что анализатор оказался умнее и внимательнее меня.
Характеристики анализатора PVS-Studio на примере EFL Core Libraries, 10-15% ложных срабатываний

Дата: 31 Июл 2017

Автор: Андрей Карпов

После большой статьи про проверку операционной системы Tizen мне было задано много вопросов о проценте ложных срабатываний и о плотности ошибок (сколько ошибок PVS-Studio выявляет на 1000 строк кода)…

Комментарии (0)

Следующие комментарии

На сайте установлена reCAPTCHA и применяются
Политика конфиденциальности и Условия использования Google.
Этот сайт использует куки и другие технологии, чтобы предоставить вам более персонализированный опыт. Продолжая просмотр страниц нашего веб-сайта, вы принимаете условия использования этих файлов. Если вы не хотите, чтобы ваши данные обрабатывались, пожалуйста, покиньте данный сайт. Подробнее →
Принять