СТОП. Подожди читатель, не проходи мимо. Я знаю, что ты увидел слово printf. И уверен, что автор статьи сейчас расскажет банальную историю о том, что функция не контролирует типы передаваемых аргументов. Нет! Статья будет не про это, а именно про уязвимости. Заходи почитать.

Предыдущая заметка находится здесь: Часть первая.

Введение

Взглянем на вот эту строчку:

printf(name);

Она кажется простой и безобидной. А между тем, в ней скрывается как минимум два способа, чтобы атаковать программу.

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

Представленный пример является компромиссом между сложностью и необходимостью не дать компилятору "схлопнуть в ничто" слишком простой код. Признаюсь, немного я себе всё равно помог. Я отключил некоторые виды оптимизации, используемые в Visual Studio 2010. Во-первых, был отключен ключ /GL (Whole Program Optimization). Во–вторых, я использовал атрибут __declspec(noinline).

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

Демонстрационный пример

Полный код и проект для Visual Studio 2010 доступен здесь.

const size_t MAX_NAME_LEN = 60;
enum ErrorStatus {
  E_ToShortName, E_ToShortPass, E_BigName, E_OK
};

void PrintNormalizedName(const char *raw_name)
{
  char name[MAX_NAME_LEN + 1];
  strcpy(name, raw_name);

  for (size_t i = 0; name[i] != '\0'; ++i)
    name[i] = tolower(name[i]);
  name[0] = toupper(name[0]);

  printf(name);
}

ErrorStatus IsCorrectPassword(
  const char *universalPassword,
  BOOL &retIsOkPass)
{
  string name, password;
  printf("Name: "); cin >> name;
  printf("Password: "); cin >> password;
  if (name.length() < 1) return E_ToShortName;
  if (name.length() > MAX_NAME_LEN) return E_BigName;
  if (password.length() < 1) return E_ToShortPass;

  retIsOkPass = 
    universalPassword != NULL &&
    strcmp(password.c_str(), universalPassword) == 0;
  if (!retIsOkPass)
    retIsOkPass = name[0] == password[0];

  printf("Hello, ");
  PrintNormalizedName(name.c_str());

  return E_OK;
}

int _tmain(int, char *[])
{
  _set_printf_count_output(1);
  char universal[] = "_Universal_Pass_!";
  BOOL isOkPassword = FALSE;
  ErrorStatus status =
    IsCorrectPassword(universal, isOkPassword);
  if (status == E_OK && isOkPassword)
    printf("\nPassword: OK\n");
  else
    printf("\nPassword: ERROR\n");
  return 0;
}

Функция _tmain() вызывает функцию IsCorrectPassword(). Если пароль верен или если он совпадает с магическим словом "_Universal_Pass_!", то программа выводит строку "Password: OK". Целью атак будет добиться, чтобы программа выводила именно эту строку.

Функция IsCorrectPassword() запрашивает у пользователя имя и пароль. Пароль считается корректным, если он совпадает с переданным в функцию магическим словом. Также он корректен, если первая буква пароля совпадает с первой буквой имени.

Вне зависимости от того, введен правильный пароль или нет, программа приветствует пользователя. Для этого вызывается функция PrintNormalizedName().

В функции PrintNormalizedName() всё самое интересное. Именно в ней, находится обсуждаемый "printf(name);". Подумайте, как с помощью этой строчки можно обмануть программу. Если знаете как, то дальше можно не читать.

Что делает функция PrintNormalizedName()? Она печатает имя, сделав первую букву заглавной, а остальные маленькими. Например, если ввести имя "andREy2008", то она распечатает "Andrey2008".

Первая атака

Предположим мы не знаем правильный пароль. Но знаем, что где-то есть некий магический пароль. Попробуем его поискать, используя printf(). Если адрес этого пароля есть где-то в стеке, то у нас есть шанс на успех. Есть идеи, как увидеть этот пароль на экране?

Даю подсказку. Функция printf() относится к семейству функций с переменным количеством аргументов. Работают такие функции так. В стек записывается произвольное количество данных. Функция printf() не знает, сколько данных записано в стек и какой у них тип. Она руководствуется исключительно строкой форматирования. Если написано "%d%s", то значит, из стека следует извлечь одно значение типа int и один указатель. Так как функция printf() не знает, сколько аргументов ей передали, то она может заглянуть глубже в стек и распечатать данные, которые никакого к ней отношения не имеет. Как правило, это приводит к access violation или к распечатке мусора. Однако, этим мусором можно воспользоваться.

Рассмотрим, как может выглядеть стек в момент, когда мы вызываем функцию printf():

Рисунок 1. Схематическое расположение данных в стеке.

Вызов функции "printf(name);" имеет только один аргумент, который является строкой форматирования. Это значит, что если мы вместо имени мы введём "%d", то распечатаем данные, которые лежат в стеке до адреса возврата в функцию PrintNormalizedName(). Попробуем:

Name: %d

Password: 1

Hello, 37

Password: ERROR

Пока данное действие малоосмысленно. Как минимум, вначале мы должны распечатать адреса возврата и всё содержимое буфера char name[MAX_NAME_LEN + 1];, который тоже расположен в стеке. И только потом, возможно, мы доберемся до чего-то интересного.

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

В начале, ввести: "%s". Потом ввести "%x%s". Потом ввести "%x%x%s" и так далее. Этим хакер будет перебирать по-очереди данные в стеке, и пытаться распечатать их как строку. Здесь ему помогает то, что все данные в стеке выровнены, как минимум по границе 4 байта.

Если честно, действуя так, у нас ничего не получится. Мы превысим лимит в 60 символов, так и не распечатав ничего полезного. На помощь нам придет "%f", который предназначен для печати значений типа double. Следовательно, с его помощью мы сможем двигаться по стеку сразу по 8 байт.

И вот она - долгожданная строчка:

%f%f%f%f%f%f%f%f%f%f%f%f%f%f%f%f%f%f%f%f%f%f%x(%s)

Результат:

Рисунок 2. Распечатка пароля. Нажмите на рисунок для увеличения.

Попробуем эту строчку в качестве волшебного пароля:

Name: Aaa

Password: _Universal_Pass_!

Hello, Aaa

Password: OK

Ура! Мы смогли найти и вывести на экран приватные данные, к которым программа не планировала дать нам доступ. Причем, обратите внимание, для этого нет необходимости иметь доступ к самому двоичному коду программы. Достаточно усердия и настойчивости.

Выводы по первой атаке

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

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

printf("%s", name);

Вторая атака

Вы знаете, что функция printf() может модифицировать память? Скорее всего, вы про это читали, но забыли. Речь идет о спецификаторе "%n". Он позволяет записать по указанному адресу количество символов, которые уже распечатала функция printf().

Если честно, атака, основанная на спецификаторе "%n" носит исключительно исторический характер. Начиная с Visual Studio 2005 возможность использования "%n" по умолчанию отключена. Чтобы провести эту атаку мне пришлось явно разрешить этот спецификатор. Вот это магическое действие:

_set_printf_count_output(1);

Чтобы стало понятнее, приведу пример использования "%n":

int i;
printf("12345%n6789\n", &i);
printf( "i = %d\n", i );

Вывод программы:

123456789

i = 5

Как добраться до нужного указателя, находящегося в стеке, мы уже узнали. А теперь у нас в руках есть инструмент, который позволяет модифицировать память по этому указателю.

Конечно, пользоваться этим неудобно. Во-первых, мы можем записать только сразу 4 байта (размер типа int). Если нам нужно большое число, то вначале функция printf() будет должна вывести очень много символов. Чтобы этого не делать, может помочь спецификатор "%00u". Спецификатор влияет на значение текущего количества выведенных байт. Подробнее вникать в тонкости не будем.

В нашем случае всё проще. Нам достаточно записать в переменную isOkPassword любое значение, неравное 0. Адрес этой переменной передаются в функцию IsCorrectPassword(), а значит, находится где-то в стеке. Пусть вас не смущает, что переменная передается как ссылка. На низком уровне, ссылка является обыкновенным указателем.

Вот строка, которая позволит нам модифицировать переменную IsCorrectPassword:

%f%f%f%f%f%f%f%f%f%f%f%f%f%f%f%f%f%f%f%f%f%f%f %n

Спецификатор "%n" не учитывает количество символов, выведенных с помощью таких спецификаторов, как "%f". Поэтому, перед "%n" поставим один пробел, чтобы записать в isOkPassword значение 1.

Пробуем:

Рисунок 3. Запись в память. Нажмите на рисунок для увеличения.

Впечатляет? Но это ещё далеко не всё. Можно произвести запись почти по произвольному адресу. Если выводимая строка находится в стеке, то мы можем дойти до нужных символов и использовать их как адрес.

Например, мы можем написать строку, содержащую подряд символы с кодами 'xF8', 'x32', 'x01', 'x7F'. Получается, что в строке есть жестко закодированное число, которое эквивалентно значению 0x7F0132F8. В конце мы поставим спецификатор "%n". Используя "%x" или другие спецификаторы, мы можем добраться до закодированного числа 0x7F0132F8 и записать количество выведенных символов по этому адресу. У такого способа есть ограничения, но он всё равно очень любопытен.

Выводы по второй атаке

Можно сказать, что атака второго рода сейчас вряд ли возможна. Как видите, поддержка спецификатора "%n" в современных библиотеках по умолчанию выключена. Однако можно создать свой самодельный механизм, который будет предрасположен данному виду уязвимости. Будьте аккуратны, когда введенные извне данные, управляют тем, что и куда записать в память.

Конкретно в этом случае, проблемы опять не возникнет, если написать так:

printf("%s", name);

Общие выводы

Здесь рассмотрено только два простых примера уязвимости. Конечно, их существует намного больше. Здесь не делается попытка описать или хотя бы перечислить их. В статье планировалось показать, что опасность может представлять даже такая простая конструкция как printf(name).

Отсюда следует важный вывод. Если вы не специалист по безопасности, то лучше следовать всем рекомендациям, о которых пишут. Суть рекомендаций бывает слишком тонка, чтобы оценить весь спектр угроз самостоятельно. Ведь вы наверняка читали, что printf() опасная функция. Но я уверен, что многие, из читающих эту статью, впервые узнали о глубине кроличьей норы.

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

Соблюдайте все рекомендации компилятора об использовании обновленных версий строковых функций. Имеется в виду, использование sprintf_s вместо sprintf и так далее.

Ещё лучше - вообще откажитесь от низкоуровневой работы со строками. Эти функции - наследие языка Си. Сейчас есть std::string. Есть безопасные способы формирования строк, такие как boost::format или std::stringstream.

P.S. Кто-то, прочитав вывод, сказал - "это и так было понятно". Но будьте честны. До прочтения этой статьи вы знали и помнили о том, что printf() может писать в память? А ведь это является большой уязвимостью. По крайней мере, являлось таковой раньше. Сейчас есть другие, не менее коварные.

Программисты - ленивые существа. Поэтому норовят решить задачу минимальным количеством кода. Это похвальное и хорошее стремление. Главное не увлечься процессом и вовремя остановиться.

Например, программистам бывает лень создавать единую функцию инициализации в классе, чтобы затем вызывать её из разных конструкторов. Программист думает: "Зачем мне лишняя функция? Я лучше вызову один конструктор из другого". К сожалению, даже эту простую задачу программисту удается решить не всегда. Для выявлений таких неудачных попыток я как раз сейчас реализовываю в PVS-Studio новое правило. Вот, пример кода, который я обнаружил в проекте eMule:

class CSlideBarGroup
{
public:
  CSlideBarGroup(CString strName,
    INT iIconIndex, CListBoxST* pListBox);
  CSlideBarGroup(CSlideBarGroup& Group);
  ...
}

CSlideBarGroup::CSlideBarGroup(CSlideBarGroup& Group)
{
  CSlideBarGroup(
    Group.GetName(), Group.GetIconIndex(), Group.GetListBox());
}

Рассмотрим внимательнее реализацию последнего конструктора. Программист решил, что код

CSlideBarGroup(
  Group.GetName(), Group.GetIconIndex(), Group.GetListBox());

просто вызывает другой констурктор. Ничего подобного. Здесь создается и тут же уничтожается новый неименованный объект типа CSlideBarGroup.

Получается, что программист действительно вызвал другой конструктор. Вот только сделал он совсем не то, что задумал. Поля класса останутся неинициализированными.

Такие ошибки, это только половина беды. Некоторые знают, как все-таки действительно вызвать другой конструктор. И вызывают. Лучше бы они не знали, как это делается. :)

Например, приведенный код, можно было бы переписать так:

CSlideBarGroup::CSlideBarGroup(CSlideBarGroup& Group)
{
  this->CSlideBarGroup::CSlideBarGroup(
    Group.GetName(), Group.GetIconIndex(), Group.GetListBox());
}

или так:

CSlideBarGroup::CSlideBarGroup(CSlideBarGroup& Group)
{
  new (this) CSlideBarGroup(
    Group.GetName(), Group.GetIconIndex(),
    Group.GetListBox());
}

Теперь действительно один конструктор для инициализации данных вызывает другой конструктор.

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

Приведенные примеры являются очень опасным кодом, и нужно хорошо понимать, как они работают!

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

class SomeClass
{
  int x,y;
public:
  SomeClass() { new (this) SomeClass(0,0); }
  SomeClass(int xx, int yy) : x(xx), y(yy) {}
};

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

Рассмотрим другой код, где явный вызов конструктора приводит к ошибке (пример взят из дискуссии на сайте StackOverflow):

class Base 
{ 
public: 
 char *ptr; 
 std::vector vect; 
 Base() { ptr = new char[1000]; } 
 ~Base() { delete [] ptr; } 
}; 
 
class Derived : Base 
{ 
  Derived(Foo foo) { } 
  Derived(Bar bar) { 
     new (this) Derived(bar.foo); 
  } 
}

Когда мы вызываем конструктор "new (this) Derived(bar.foo);", объект Base уже создан и поля инициализированы. Повторный вызов конструктора приведет к двойной инициализации. В 'ptr' запишем указатель на вновь выделенный участок памяти. В результате получаем утечку памяти. К чему приведет двойная инициализация объекта типа std::vector, вообще предсказать сложно. Ясно одно. Такой код недопустим.

Вывод

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

Вот как должен выглядеть правильный код:

class CSlideBarGroup
{
  void Init(CString strName, INT iIconIndex,
            CListBoxST* pListBox);
public:
  CSlideBarGroup(CString strName, INT iIconIndex,
                 CListBoxST* pListBox)
  {
    Init(strName, iIconIndex, pListBox);
  }
  CSlideBarGroup(CSlideBarGroup& Group)
  {
    Init(Group.GetName(), Group.GetIconIndex(),
         Group.GetListBox());
  }
  ...
};

P.S. Явный вызов одного конструктора из другого в C++11 (делегация)

Новый стандарт С++11 позволяет вызывать одни конструкторы класса из других (так называемая делегация). Это позволяет писать конструкторы, использующие поведение других конструкторов без внесения дублирующего кода. Пример корректного кода:

class MyClass {
  std::string m_s;
public:
    MyClass(std::string s) : m_s(s) {}
    MyClass() : MyClass("default") {}
};

Аннотация

Это уже четвертая заметка, где я хочу поделиться полезными наблюдениями о паттернах ошибок и том, как можно с ними бороться. В этот раз я затрону такую тему, как обработка редких и аварийных ситуаций в программах. Рассматривая множество программ, я пришел к выводу, что код обработки ошибок в Си/Си++ программах - одно из самых ненадежных мест.

К чему приводят такие дефекты? Программа, вместо того, чтобы выдать сообщение "файл X не найден", падает и заставляет пользователя гадать, что он не так делает. Программа для работы с базой данных выводит невразумительное сообщение, вместо того, чтобы сообщить, что неверно заполнено одно из полей. Попробуем сразиться с этой разновидностью ошибок, которые досаждают нашим пользователям.

Введение

Вначале информация для читателей, которые не знакомы с моими предыдущими заметками. Их можно найти здесь:

• Заметка N1 [Miranda IM];
• Заметка N2 [Chromium, Return to Castle Wolfenstein и т.д.];
• Заметка N3 [Qt SDK].

Как всегда я буду не абстрактен, а начну с примеров. В этот раз примеры будут взяты из исходного кода Firefox. Я постараюсь продемонстрировать, что даже в качественном и известном приложении с кодом для обработки ошибок, всё обстоит не самым лучшим образом. Дефекты были найдены мной с помощью анализатора PVS-Studio 4.50.

Примеры ошибок

Пример N1. Неполноценная проверка целостности таблицы

int  AffixMgr::parse_convtable(..., const char * keyword)
{
  ...
  if (strncmp(piece, keyword, sizeof(keyword)) != 0) {
      HUNSPELL_WARNING(stderr,
                       "error: line %d: table is corrupt\n",
                       af->getlinenum());
      delete *rl;
      *rl = NULL;
      return 1;
  }
  ...
}

Диагностика PVS-Studio: V579 The strncmp function receives the pointer and its size as arguments. It is possibly a mistake. Inspect the third argument. affixmgr.cpp 3708

Здесь сделана попытка проверить целостность таблицы. К сожалению, эта проверка может сработать, а может и не сработать. Для вычисления длины ключевого слова используют оператор sizeof(), что естественно некорректно. В результате, работоспособность кода зависит от счастливого стечения обстоятельств (длины ключевого слова, размера указателя 'keyword' в текущей модели данных).

Пример 2. Неработающая проверка при чтении файла

int PatchFile::LoadSourceFile(FILE* ofile)
{
  ...
  size_t c = fread(rb, 1, r, ofile);
  if (c < 0) {
    LOG(("LoadSourceFile: "
         "error reading destination file: " LOG_S "\n",
         mFile));
    return READ_ERROR;
  }
  ...
}

Диагностика PVS-Studio: V547 Expression 'c < 0' is always false. Unsigned type value is never < 0. updater.cpp 1179

Это пример, когда код обработки ошибки пишется по принципу "чтобы было". Программист даже не задумался, что собственно он написал, и как это будет работать. Проверка некорректна. Функция fread() возвращает количество прочитанных байт с помощью беззнакового типа. Прототип функции:

size_t fread( 
   void *buffer,
   size_t size,
   size_t count,
   FILE *stream 
);

Естественно, для хранения результата используется переменная 'c', имеющая тип size_t. Как следствие, результат проверки (c < 0) всегда ложен.

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

Аналогичную ошибку можно увидеть и в других местах:

V547 Expression 'c < 0' is always false. Unsigned type value is never < 0. updater.cpp 2373

V547 Expression 'c < 0' is always false. Unsigned type value is never < 0. bspatch.cpp 107

Пример 3. Проверка указателя на NULL уже после его использования

nsresult
nsFrameSelection::MoveCaret(...)
{
  ...
  mShell->FlushPendingNotifications(Flush_Layout);
  if (!mShell) {
    return NS_OK;
  }
  ...
}

Диагностика PVS-Studio: V595 The 'mShell' pointer was utilized before it was verified against nullptr. Check lines: 1107, 1109. nsselection.cpp 1107

Если указатель равен нулю, то мы должны обработать этот специальный случай и вернуть из функции NS_OK. Смущает то, что указатель mShell до этого момента уже используется.

Скорее всего, этот код работает, так как указатель mShell всегда неравен NULL. Пример я привожу, чтобы показать, что можно допустить ошибку даже в очень простых проверках. Проверка есть, а смысла от неё нет.

Пример 4. Проверка указателя на NULL уже после его использования

CompileStatus
mjit::Compiler::performCompilation(JITScript **jitp)
{
  ...
  JaegerSpew(JSpew_Scripts,
    "successfully compiled (code \"%p\") (size \"%u\")\n",
    (*jitp)->code.m_code.executableAddress(),
    unsigned((*jitp)->code.m_size));

  if (!*jitp)
      return Compile_Abort;
  ...
}

Диагностика PVS-Studio:V595 The '* jitp' pointer was utilized before it was verified against nullptr. Check lines: 547, 549. compiler.cpp 547

Кстати, использование указателя до проверки - распространенная ошибка. Это ещё один пример на эту тему.

Пример 5. Неполная проверка входных значений

PRBool
nsStyleAnimation::AddWeighted(...)
{
  ...
  if (unit[0] == eCSSUnit_Null || unit[1] == eCSSUnit_Null ||
      unit[0] == eCSSUnit_Null || unit[0] == eCSSUnit_URL) {
    return PR_FALSE;
  }
  ...
}

Диагностика PVS-Studio: V501 There are identical sub-expressions 'unit [0] == eCSSUnit_Null' to the left and to the right of the '||' operator. nsstyleanimation.cpp 1767

Кажется, здесь сразу 2 опечатки. Затрудняюсь сказать, как именно должен выглядеть здесь код, но, наверное, хотели написать так:

if (unit[0] == eCSSUnit_Null || unit[1] == eCSSUnit_Null ||
    unit[0] == eCSSUnit_URL  || unit[1] == eCSSUnit_URL) {

Из-за опечаток функция может начать обрабатывать некорректные входные значения.

Пример 6. Неполная проверка входных значений

nsresult PresShell::SetResolution(float aXResolution, float aYResolution)
{
  if (!(aXResolution > 0.0 && aXResolution > 0.0)) {
    return NS_ERROR_ILLEGAL_VALUE;
  }
  ...
}

Диагностика PVS-Studio: V501 There are identical sub-expressions to the left and to the right of the '&&' operator: aXResolution > 0.0 && aXResolution > 0.0 nspresshell.cpp 5114

А вот ещё один пример неудачной проверки входных параметров. В этот раз из-за опечатки не проверяется значение аргумента aYResolution.

Пример 7. Неразыменованный указатель

nsresult
SVGNumberList::SetValueFromString(const nsAString& aValue)
{
  ...
  const char *token = str.get();
  if (token == '\0') {
    return NS_ERROR_DOM_SYNTAX_ERR; // nothing between commas
  }
  ...
}

Диагностика PVS-Studio: V528 It is odd that pointer to 'char' type is compared with the '\0' value. Probably meant: *token == '\0'. svgnumberlist.cpp 96

Проверка, что между запятыми ничего нет, не работает. Чтобы узнать, пустая строка или нет, можно сравнить первый символ с '\0'. Но здесь с нулем сравнивается не первый символ, а указатель. Этот указатель всегда неравен нулю. Корректная проверка должна была выглядеть так: (*token == '\0').

Пример 8. Неподходящий тип для хранения индекса

PRBool 
nsIEProfileMigrator::TestForIE7()
{
  ...
  PRUint32 index = ieVersion.FindChar('.', 0);
  if (index < 0)
    return PR_FALSE;
  ...
}

Диагностика PVS-Studio: V547 Expression 'index < 0' is always false. Unsigned type value is never < 0. nsieprofilemigrator.cpp 622

Функция не вернёт PR_FALSE, если в строке нет точки и продолжит работать с некорректными данными. Ошибка в том, что для переменной 'index' выбран беззнаковый тип данных. Проверка (index < 0) не имеет смысла.

Пример 9. Формирование неправильного сообщения об ошибке

cairo_status_t
_cairo_win32_print_gdi_error (const char *context)
{
  ...
  fwprintf(stderr, L"%s: %S", context, (wchar_t *)lpMsgBuf);
  ...
}

Диагностика PVS-Studio: V576 Incorrect format. Consider checking the third actual argument of the 'fwprintf' function. The pointer to string of wchar_t type symbols is expected. cairo-win32-surface.c 129

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

Функция _cairo_win32_print_gdi_error() распечатает абракадабру. В качестве третьего аргумента функция fwprintf() ожидает указатель на unicode-строку, а вместо этого получает строку в формате 'const char *'.

Пример 10. Ошибка записи дампа

bool ExceptionHandler::WriteMinidumpForChild(...)
{
  ...
  DWORD last_suspend_cnt = -1;
  ...
  // this thread may have died already, so not opening
  // the handle is a non-fatal error
  if (NULL != child_thread_handle) {
    if (0 <= (last_suspend_cnt =
                SuspendThread(child_thread_handle))) {
  ...
}

Диагностика PVS-Studio: V547 Expression is always true. Unsigned type value is always >= 0. exception_handler.cc 846

Это другой пример в обработчике ошибок. Здесь некорректно обрабатывается результат, возвращаемый функцией SuspendThread. Переменная last_suspend_cnt имеет тип DWORD, а значит она всегда будет больше или равна 0.

О других ошибках в Firefox

Сделаю небольшое отступление и расскажу о результатах проверки Firefox в целом. Проект качественен, и PVS-Studio выявил мало ошибок. Однако, так как он большой, то в количественном отношении ошибок достаточно много. К сожалению, мне не удалось полноценно изучить отчет, выданный инструментом PVS-Studio. Дело в том, что для Firefox отсутствует файл проекта для Visual Studio. Проект проверялся консольной версией PVS-Studio, вызываемой из make-файла. Открыв отчет в Visual Studio, можно просмотреть все диагностические сообщения. Но раз нет проекта, то Visual Studio не подсказывает, где какие переменные объявлены, не позволяет перейти в место определения макросов и так далее. В результате, анализ неизвестного проекта крайне трудоемок, и я смог изучить только часть сообщений.

Ошибки встречаются разноплановые. Например, есть выход за границы массива:

class nsBaseStatis : public nsStatis {
public:
  ...
  PRUint32 mLWordLen[10]; 
  ...
  nsBaseStatis::nsBaseStatis(...)
  {
    ...
    for(PRUint32 i = 0; i < 20; i++)
       mLWordLen[i] = 0;
    ...
  }
  ...
};

Диагностика PVS-Studio: V557 Array overrun is possible. The value of 'i' index could reach 19. detectcharset.cpp 89

Хотя эта и подобные ошибки интересны, они не связаны с темой данной статьи. Поэтому, если интересно, можно посмотреть на некоторые другие ошибки в этом файле: mozilla-test.txt.

Вернемся к ошибкам в обработчиках ошибок

Я решил привести не парочку, а 10 примеров, чтобы убедить вас в актуальности проблем наличия дефектов в обработчиках ошибок. Конечно, обработчики ошибок не самые критичные и важные участки программы. Но ведь программисты их пишут, а значит, надеются с их помощью улучшить поведение программы. К сожалению, как показывают мои наблюдения, очень часто проверки и обработчики ошибок не работают. Смотрите, мне было достаточно одного, пусть и крупного проекта, чтобы показать множество ошибок данного типа.

Что же с этим делать и какие можно дать рекомендации?

Первая рекомендация

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

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

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

Итак, теперь вы предупреждены. И я уверен, это уже очень хорошо и полезно.

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

Вторая рекомендация

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

Неработающий механизм сохранения дампа не только бесполезен, он только создает видимость, что в случае беды им можно будет воспользоваться. Если пользователь пришлёт испорченный dump-файл, то он не только не поможет, а может только ввести в заблуждение и на поиски ошибок будет потрачено больше времени, чем если бы dump-файла вообще отсутствовал.

Рекомендация выглядит простой и очевидной. Но у многих ли, из читающих эту заметку, есть юнит-тесы для проверки класса WriteMyDump ?

Третья рекомендация

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

Другими словами, при статическом анализе покрытие кода составляет 100%. Достичь такого покрытия кода с помощью других видов тестирования практически нереально. Покрытие кода при юнит-тестах и регрессионном тестировании обычно составляет менее 80%. Оставшиеся 20% протестировать очень сложно. В эти 20% входят большинство обработчиков ошибок и редких ситуаций.

Четвертая рекомендация

Можно попробовать использовать методологию внесения неисправностей. Смысл в том, что ряд функций время от времени начинают возвращать различные коды ошибок, и программа должна корректно их обрабатывать. Например, можно написать свою функцию malloc(), которая время от времени будет возвращать NULL, даже если память ещё есть. Это позволит узнать, как будет вести себя программа, когда память действительно кончится. Аналогично можно поступать с такими функциями, как fopen(), CoCreateInstance(), CreateDC() и так далее.

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

Заключение

Дефекты в обработчиках ошибок встречаются часто. К сожалению, я не уверен, что приведенные в статье рекомендации достаточны, чтобы их избежать. Но я надеюсь, что вас заинтересовала эта проблема, и вы сможете придумать способы сократить количество недочетов в своих программах. Также я и другие читатели будут признательны, если вы поделитесь своими идеями и методиками, которые позволят избежать ошибки рассмотренного вида.

Перед тем, как настраивать sshfs, удостоверьтесь, что можете соединиться с сервером по ssh. Далее, ваш логин на сервере будет обозначаться $login, пароль - $passwd, адрес сервера - $host (для MTL - 36.81.203.1), удаленная директория - $remote_path, локальная директория, в которую будет примонтирована удаленная - $local_path (например, ~/mtl-home).

Windows

Установка и настройка

Для работы нам потребуется библиотека Dokan (аналог fuse для windows) и основанное на ней приложение DokanSSHFS. Скачать их можно тут - <http://dokan-dev.net/en/download/>. После установки запускаем DokanSSHFS.exe и настраиваем по аналогии с putty:

• Host - $host
• User - $login
• Password - $passwd
• Server root - $remote_path - удаленная директория, которая станет корнем нового диска. В нашем случае подойдет домашняя директория - /home/$login.

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

Авторизация по ключам

Чтобы не вводить пароль в программу каждый раз (а запоминать его она специально не хочет), можно настроить авторизацию по ключам. DokanSSHFS использует ключи формата OpenSSH (ключи от putty не подойдут), и если у вас нет такого, можно сгенерировать один на удаленном сервере:

$ ssh-keygen
<enter>
<enter>
<enter>

Внимание: я специально оставил passhprase пустым, так как DokanSSHFS почему-то не работает с запароленными ключами)

После этих действий в /home/username/.ssh появятся файлы id_rsa и id_rsa.pub

Первый необходимо скопировать на рабочую машину, а второй добавить в список авторизованных ключей на удаленном сервере: $ cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys; chmod 0600 ~/.ssh/authorized_keys

Теперь, в DokanSSHFS переключаем авторизацию с Password на Identity и указываем путь к id_rsa. Готово!

Нюансы

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

Второй аспект DokanSSHFS, который может вызвать недоумение и сбои в работе - агрессивное кеширование списков директорий. По-умолчанию, DokanSSHFS кеширует списки файлов в директориях и обновляет только следуя своей внутренней логике. Это не доставляет проблем, пока вы работаете один и только через подмонтированную директорию. Но в случае если в одной и той же директории работают два пользователя, возможны отставания в обновлении списка файлов в подмонтированной директории - на удаленном сервере уже может быть содзан/удален файл/директория, а на локальной машине изменений нет. Кэш может держаться несколько минут, что может обеспечить вам головную боль при активной работе. Отключить его можно, выставив флаг “Disable cache” на вкладке “Option”. С другой стороны, отключение кеша сильно влияет на отзывчивость работы с удаленной директорией. В случае больших пингов (как до MTL из Сибири) это может действовать на нервы.

Linux

В linux-системах существует утилита sshfs, основанная на fuse. Работать с ней проще, чем в windows, и все действия сводятся к трем командам:

1. Устанавливаем (для ubuntu/debian):
   sudo apt-get install sshfs
2. Создаем директорию, в которую будет подмонтированная удаленная директория ($local_path) и запускаем sshfs:
   sshfs $login@$host:$remote_path $local_path
   Теперь в $local_path располагается ваша домашняя директория сервера mtl.
3. Чтобы отмонтировать директорию, используется другая команда:
   fusermount -u $local_path

Авторизация по ключам

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

1. Создание ключа
   ssh-keygen
   <Enter>
   <Enter>
   <Enter>
2. Добавление публичного ключа на сервер
   ssh-copy-id $login@$host
   Проверяем работоспособность - ssh и sshfs больше не должны спрашивать пароль.

MacOS

Для macos существует проект MacFUSE, с помощью которого можно пользоваться sshfs аналогично linux-системам. Скачать его можно тут <http://code.google.com/p/macfuse/downloads/list>. Графическая оболочка для него доступна тут - <http://code.google.com/p/sshfs-gui/downloads/detail?name=sshfs-gui.1.2.dmg&can=2&q=>

FreeBSD

Для freebsd также существует порт fuse, он располагается в порте sysutils/fusefs-kmod. Для работы sshfs потребуются также порты sysfsutils/fusefs-libs и sysfsutils/fusefs-sshfs. Используется sshfs аналогично системам linux.

Основная идея конкурса – получить минимальное время работы программы, хорошую масштабируемость (максимальное ускорение) на всех архитектурах от двухядерной машины среднего пользователя до 40-ядерной машины с общей памятью из Manycore Testing Lab (MTL) от Intel.

Итак, в чем же задача? - Поиск максимальной подматрицы

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

Приведем пример – дана прямоугольная матрица:

-8 -48
-7 -10
3 -55
1 64

Очевидно, прямоугольная подматрица с максимальной суммой элементов в ней есть последний столбец, т.е. матрица с координатами [0][2]…[3][2] (первое число – номер начальной строки, нумерация начинается с нуля, второе – номер начального столбца, третье – конечной строки, четвертое – конечного столбца). Собственно этот ответ и требуется от алгоритма в качестве ответа на исходную матрицу.

Что имеем? Описание входных данных

Запускать будем с 2 параметрами:

Первый параметр командной строки — имя входного файла, второй параметр — имя выходного файла.

Во входном файле содержится несколько тестов. На первой строке входного файла дано число C — количество тестов, которые нужно решить. Далее описываются C тестов. Для каждого из них в файле дана одна строка, содержащая 6 целых чисел через пробел.

Первые два числа (M и N) — количество строк и столбцов в матрице, соответственно.

Четыре следующих числа — параметры некоторого псевдослучайного алгоритма, с помощью которого генерируется матрица: seed0, a, b и m соответственно,  – тем не менее алгоритм поиска максимума не зависит от способа генерации входной матрицы. Т.е. Мы не будем привязывать алгоритм к каким-либо предположениям о структуре матрицы, связанным с методом генерации, кроме условия, что в ней есть как отрицательные, так и положительные значения элементов (и нули, конечно :)).

Ограничения для входных параметров (по условиям конкурса):

1 ≤ C ≤ 1000

1 ≤ M, N, a, b, m, seed0 ≤ 20000

Что хотим получить? Описание выходного файла

Для каждого теста в выходной файл выводится строка "Case #x: ", за которой следуют 6 целых чисел (через пробел) и символ переноса строки.

Первые 4 числа — две пары координат, задающих подматрицу с максимальной суммой элементов (в первой паре оба числа должны быть меньше или равны соответственным числам во второй паре, т.е. сначала описывается координаты левого верхнего, а потом правого нижнего угла). В каждой паре первое число — номер строки, а второе число — номер столбца (нумерация начинается с нуля). Если в процессе поиска находится несколько подматриц с одинаковой максимальной суммой элементов, выводятся координаты любой из них.

Последние 2 числа — сумма элементов в найденной подматрице и площадь этой подматрицы соответственно.

Пример вызова программы

./msp input.txt output.txt

Пример входного файла (input.txt):

2

4 3 10 3 4 17

14 31 11 4 5 18

Пример выходного файла (output.txt):

Case #1: 0 2 3 2 17 4

Case #2: 0 4 5 9 18 36

Алгоритмы решения задачи

Последовательный алгоритм решения одномерной задачи

1D:

Очевидно, что «грубая сила» не лучший вариант решения задачи, дающий верхнюю оценку принципиального решения задачи.

За основу был взят алгоритм Кадане 1D, решающий задачу для одномерной задачи за O(N), где N – длина одномерного массива:

Алгоритм Кадане 1D

M=0, t=0
i=1
for j=1 to n do
 	t=t+a[j]
 	if t > M then M=t, (x1,x2)=(i,j)
 	if t ≤ 0 then t=0, i=j+1 //обновить накопление
end for
output M, (x1,x2)

Его работа довольно очевидна: в t накапливается частичная сумма и если t становится больше M, то надо обновить M и положение подмассива. Если t становится отрицательными мы обнуляем накопленное значение, т.к. подмассив с максимальной суммой элементов не может начинаться с меньшего подмассива с отрицательной суммой элементов (в случае рандомного заполнения как положительными, так и отрицательными, очевидно, всегда можно выбрать любое положительное число, а не подмассив с отрицательной суммой элементов;в случае только отрицательных чисел это не так). В приведенном алгоритме M=0 в начале, т.е. если сумма подмассива с максимальной суммой отрицательна, то возвращается пустой подмассив и M=0.

2D:

Обобщение алгоритма на 2D не позволяет в прямом смысле его обобщить, сохранив замечательную скорость поиска максимума – мы можем лишь обобщить его использовав быстрый поиск по 2 измерению и «грубую силу» по 1 измерению:

2D версия Алгоритма Кадане

M = 0, (r1,c1) = (0,0), (r2,c2) = (0,0)
for g = 1 to m do
 	for j = 1 to n do p[j] = 0
 	for i = g to m do
 		t = 0, h = 1
 		for j = 1 to n do
 			p[j] = p[j] + a[i] [j]
 			t = t+p[j]
 			if t > M then M = t, (r1,c1) = (g,h) , (r2,c2) = (i, j)
 			if t ≤ 0 then t=0, i = j+1 //обновить накопление
 		end for
 	end for

end for
output M, (r1,c1), (r2,c2)

Здесь по Y измерению (по номерам строк) мы применяем «грубую силу», а по X измерению (по номерам столбцов) применяется одномерный алгоритм Кадане. Т.к. по Y нам необходимо не меньше, чем O(m²) времени, по X алгоритм Кадане имеет скорость O(n), следовательно общая скорость алгоритма O(m²n).

В программной реализации мы применили алгоритм Кадане по строкам, а не по столбцам, как описано в алгоритме, т.е. далее мы под Х имеем в виду количество столбцов, а под Y – количество строк

Параллелизация и улучшения алгоритма:

Распараллеливание представленного обобщения на 2D алгоритма Кадане:

• Во-первых, т.к. скорость алгоритма квадратична по m нам необходимо ее уменьшить, если это возможно, т.е. если m>n, то надо искать решение для транспонированной матрицы, что для алгоритма означает, что мы меняем местами m и n, а к 2D матрице, хранящейся по строкам в виде одномерного массива, начинаем обращаться «по столбцам»

• очевидно, что по X измерению все вычисления независимы везде, кроме сравнивания с текущим максимумом и записи нового значения максимума и его положения. Используя технологию OpenMP, мы можем распараллелить вычисления по внешнему циклу

• Для начальных Х количество итераций внутреннего цикла от применения «грубой силы», максимально, для конечных Х – минимально. Поэтому при распараллеливании в начале на каждый процессор будет приходиться слишком много работы, а в конце они будут простаивать из-за накладных расходов. Поэтому необходимо, чтобы в начале chunk был равен 1, а в конце – больше 1, чтобы сбалансировать нагрузку. Для OpenMP это решается параметром schedule(guided), при котором размер порции уменьшается с некоторого начального значения до величины chunk (по умолчанию chunk=1) пропорционально количеству ещё не распределённых итераций, делённому на количество нитей, выполняющих цикл. (У нас ситуация с загрузкой прямо противоположная – в начале сильная загрузка, в конце слабая, поэтому мы используем этот параметр вместе с обращением цикла (т.е. отрицательным шагом), т.е. начинаем искать с конца по X).

• При параллельном выполнении возможны ошибки «гонки данных». Введение критической секции (т.е. области кода, куда может входить одновременно не более одной нити – самым простым решением этих ошибок) – при сравнении с текущим максимумом, обновлением его значения и значений координат начала и конца подмассива – значительно замедлит параллельное выполнение, т.к. большую часть времени нити будут ждать друг друга. Чтобы не вводить их мы создаем массив максимумов (и их координат) – «свой» элемент для каждой нити. Это решает проблему гонки данных и снимает проблему синхронизации. Полная синхронизация нитей (и найденных ими «локальных» максимумов) проводится при выходе из основного вычисления и тривиального поиска максимума в массиве максимум каждой нити.

	int xidx, yidx, endxidx, endyidx;
	int Y = M[p]; //Число строк
	int X = N[p]; //Число столбцов
	
	///* Kadans 2D parallel alghoritm
	int N,M;
    int t = 0;
	int s = 0, k, l,j;
    int z,i,x;
	int numthread = omp_get_num_procs();
	int * S, * x1, * x2, * y1, * y2;
	S = (int*) calloc(numthread, sizeof(int)); //(int*) malloc(sizeof(int)*numthread);
	x1 = (int*) calloc(numthread, sizeof(int));
	x2 = (int*) calloc(numthread, sizeof(int));
	y1 = (int*) calloc(numthread, sizeof(int));
	y2 = (int*) calloc(numthread, sizeof(int));
	omp_set_num_threads(numthread);
//т.к. скорость алгоритма О(X^2*Y), надо в качестве Х надо взять min(X,Y), во втором случае надо обращаться к "транспонированной" матрице
	if (X<=Y){
		N = X;
		M = Y;
		#pragma omp parallel shared(N,M,arr,S,x1,x2,y1,y2) private(z,x,i,t,s,j,k,l)  default(none) 
		{
			#pragma omp for schedule(guided) nowait //shared(N,M,arr,S,x1,x2,y1,y2) private(z,x,i,t,s,j,k,l)  default(none) //
			for(z = N-1; z >-1; z--) //обратное уменьшение шага балансирует нагрузку с chunk > 1, где операций меньше, До chunk=1 в начале, где вычислений больше
			{
				int threadIdx = omp_get_thread_num();
				int * sa;
				sa = (int*) calloc(M,sizeof(int));
				for(x = z; x < N; x++)
				{
					t = 0;
					s = 1<<31;
					j = 0;
					k = 0; l = 0;
					for(i = 0; i < M; i++)
					{
						sa[i] = sa[i] + arr[i*N+x]; 
						t = t + sa[i];
						if( t > s)
						{
							s = t;
							k = i;
							l = j;
						}
						if( t < 0 )
						{
							t = 0;
							j = i + 1;
						}
					}
					if( s > S[threadIdx])
					{
						S[threadIdx] = s;
						x1[threadIdx] = z;
						y1[threadIdx] = k;
						x2[threadIdx] = x;
						y2[threadIdx] = l;
					}
					
				}
				free(sa);
			}
		}
		int max_idx = 0;
		int temp = 1<<31;
		for (i=0;i < numthread;i++)
		{if (temp < S[i]) {temp = S[i]; max_idx=i;}}
		if (x2[max_idx] < x1[max_idx])
		{temp = x1[max_idx]; x1[max_idx] = x2[max_idx]; x2[max_idx] = temp;}
		if(y2[max_idx] < y1[max_idx])
		{temp = y1[max_idx]; y1[max_idx] = y2[max_idx]; y2[max_idx] = temp;}

		FILE* file;
		file = fopen(name, "a");
		if (!file) printf("ERROR: file %s doesn't exist", name);
		fprintf(file, "Case #%i, %i, %i, %i, %i, %i, %i \n", p+1, y1[max_idx], x1[max_idx], y2[max_idx], x2[max_idx], S[max_idx], (x2[max_idx]-x1[max_idx]+1)*(y2[max_idx]-y1[max_idx]+1));
		fclose(file);
}

Если m>n то кроме указанных выше изменений в переборе элементов одномерного массива, полученного из исходной матрицы задачи, и замены x<->y при выводе результата код ничем идейно не отличается.

Проблемы распараллеливания 2D алгоритма  Кадане:

Очевидно, что по Y направлению алгоритм принципиально последовательный (т.к. называемая истинная зависимость) и распараллелить мы его сможем, только сменив алгоритм :). В этом смысле это не наилучший алгоритм. Но учитывая ограничения конкурса, и то, что ядер все равно не больше 40, это не большая проблема.  

Тайминги:

Использовались предложенные на форуме:

#include <sys/time.h>
int t = curTime();
fprintf(stderr, "Time of execution: %.3lf sec.\n",
(double)(curTime() - t) / 1000.0);

static int curTime() {
    struct timeval now_tv;
    gettimeofday( &now_tv, NULL );
    return (int)now_tv.tv_sec * 1000 + (int)now_tv.tv_usec / 1000;
}

Полученные результаты и недостгнутые цели

• Транспонирование матрицы (если M<N) дает ускорение в 2 раза для наборов содержащих сильно прямоугольные матрицы (M=3*N). 
  
• Использование директивы guided дает ускорение в 1.5 раза.
• Использование массива максимумов для каждой нити дает ускорение в 5 раз. (Среднее число одновременно работающих потоков остается постоянной, равной удвоенному (с включенным HyperThreading) количеству ядер). Для варианта с критической секции и с общей переменной максимума среднее число одновременно работающих потоков равно 0, т.е. нити всегда друг друга ждут.

На тестах для следующего input.txt:

3
4 3 10 3 4 17
14 31 11 4 5 18
1024 1024 10 3 4 17

Intel Core i3-350M, RAM 3Gb: 9.35 секунд, при этом удалось добиться равномерной загрузки всех 4 потоков (с включенным HyperThreading).

Корректность параллельного алгоритма, т.е. правильность выходных данных для средних датасетов (medium.txt) была проверена на Intel MTL и гарантируется (время выполнения ~23 секунд).

Выводы

Преимущества алгоритма Кадане 2D:

• Элегантность
• Простота реализации
• Относительная простота распараллеливания
• Хорошая масштабируемость по количеству ядер
• Большое количество литературы

Недостатки алгоритма Кадане 2D:

• Далеко не лучшая скорость работы O(m²n) по сравнению с минимальной оценкой идеального алгоритма O(mn). (Лучшую чем O(m²n) оценку имеет, например, алгоритм Такаоки, о котором мы только скажем, что для довольно «маленьких» тестов данного конкурса он слишком громоздок)
  
• Принципиальная последовательность алгоритма по второму направлению (столбцы в нашей статье).

Литература:

В процессе поиска было найдено много материалов (ссылки ниже) из открытого доступа.

[1] Tadao Takaoka, Efficient Algorithms for the Maximum Subarray Problem by Distance Matrix Multiplication

[2] KALYAN PERUMALLA, PARALLEL ALGORITHMS FOR MAXIMUM SUBSEQUENCE AND MAXIMUM SUBARRAY

[3] Sung Eun Bae, Sequential and Parallel Algorithms for the Generalized Maximum Subarray Problem

[4] Fredrik Bengtsson C. Jingsen Chen, Efficient Algotithms for k Maximum Sums

[5] Mohammad Bashar, AVERAGE CASE ANALYSIS OF ALGORITHMS FOR THE MAXIMUM SUBARRAY PROBLEM

P.S. Успехов в этом увлекательном деле, Let's go parallel!

Год тому назад, когда я учился на 3-ем курсе университета, у нас появился предмет, который вел “big-boss” одной из местных фирм, занимающихся разработкой программного обеспечения. Этот предмет назывался “Операционные системы”, а речь на нем шла о современном строении, функционировании компьютерных систем в общем. На практических занятиях требовалось реализовать простую задачу: подобрать пароль по хэшу, зашифрованному стандартной функцией crypt() из POSIX. Написав простую программу, вы получите новое задание - реализовать это многопоточно, а потом опять новое - реализовать распределенно и так далее.

Но мы остановимся на многопоточном решении этой задачи, и на примере ее разберем тему нашего разговора - шаблон проектирования “producer-consumer”. Я замечу, что для чтения требуется понимание основ и базовых приемов параллельного программирования, например, нужно знать, что такое синхронизация потоков, мьютексы, семафоры, а также понимать типичные ошибки в проектировании решения параллельных задач.

Анатомия нашего шаблона

Шаблон “producer-consumer” устроен по следующей схеме:

Producer (изготовитель) - это некоторый поток, который генерирует “задания” и складывает их в очередь Queue.

Consumer (исполнитель) - это поток, который берет задания из очереди, выполняет и отправляет результаты туда, куда нужно.

Очередь Queue - это ограниченный буфер заданий с заранее заданной вместимостью.

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

Применение шаблона в нашей задаче

Самое простое решение будет перебирать все строки длиной не более L, с буквами из определенного алфавита (например, большие и маленькие латинские буквы и цифры) вызывать функцию crypt(), и полученный хэш сравнивать с исходным.

Можно легко протестировать и понять, что самая ресурсоемкая часть программы - это вызов функции crypt() для всех перебранных строк, в то время как сам перебор работает 1-2 процента от общего времени исполнения. Понятно, что нужно параллелить именно эту часть программы.

Основные части шаблона в нашей задаче устроены следующим образом:

task = (s, len), где s - это строка длиной len.

queue = (data[], head, tail, mutex). Задания хранятся в массиве data[], используются указатели head и tail для работы с очередью, а также обязательно нужен mutex, чтобы обеспечить синхронизацию потоков, работающих с очередью.

Схема:

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

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

Вариант второй, улучшенный. теперь задание - это строка, которую перебрали “наполовину”, то есть task = (s, len, l, r), l и r означают, что консьюмер должен еще перебрать кусок строки с l по r, а только потом проверять хэш. В данной задаче, подобная идея - это основа оптимального решения, нужно лишь подобрать пропорцию, в которой продюсер и консьюмер делят процесс перебора строк.

Зачем это все нужно

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

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

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

Зачем я написал эту статью в рамках конкурса Aceller8? Как знать... :)

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

1. Анализ генетических последовательностей

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

Одна из задач – предсказание расположения мембран протеина. Протеины – большие молекулы, состоящие из большого числа аминокислот, насчитывающих 20 видов. Фактически, все протеины могут рассматриваться как длинная цепочка аминокислот, или последовательность букв 20-буквенного алгоритма. В большинстве случаев, действительное расположение каждого атома молекулы протеина может быть точно определено линейной последовательностью, которая определяет биологическое значение в живом организме. Информация о биологическом значении протеина содержится в линейной последовательности.

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

Определение трансмембранных доменов в протеиновой последовательности – одна из важных задач понимания структуры протеина. Для каждой аминокислоты найден индекс гидрофобности. Гидрофобные радикалы протеина находится только в ядре мембраны, которая окружена двойным липидным слоем. Наименее гидрофобные располагаются в водной среде. Это явление известно как гидрофобный эффект, одна из связывающих сил внутри молекулы. Трансмембранные домены обычно содержат гидрофобные радикалы. Если известен индекс гидрофобности для каждого радикала, трансмембранные домены будут являться сегментами с наибольшей суммой индексов. Задача нахождения цепочки с наибольшей общей суммой будет эквивалентна нахождению подвектора с наибольшей суммой.

2. Компьютерное зрение

Изображение представляется двумерным массивом, где в каждая ячейка представляет значение яркости каждого пискела, основанное на стандарте RGB. Если необходимо найти наиболее яркую часть изображения, строится двумерный массив, где каждая ячейка представляет яркость соответствующего пикселя. Яркость формально определяется как (R+G+B)/3, однако это не соответствует человеческому восприятию цветов. Для яркости, соответствующей человеческому восприятию, в большинстве графических приложений используется освещенность Y, вычисляемая как взвешенная сумма R, G, B: Y=0,3R+0,59G+0,11B. Веса выбраны так, чтобы максимально точно соответствовать чувствительности глаза к красному, зеленому и синему. Очевидно, все значения неотрицательные, и подмассив с наибольшей суммой – весь массив. Перед вычислением подмассива с наибольшей суммой, важно нормализовать каждую ячейку вычитанием положительного опорного значения. Обычно, среднее арифметическое значений яркостей всех пикселей является подходящим опорным значением. Затем находится подмассив с наибольшей суммой, соответствующей наиболее яркой области изображения.

Этот подход может применяться к различным схемам оценки пикселя. Например, можно находить горячие точки на термографическом изображении. Наиболее горячие части имеют белый цвет, средние температуры – красный и желтый, и самые холодные части – синие. Можно назначить значение каждому пикселю и определить самую нагретую область.

3. Анализ данных (data mining)

Поиск подматрицы с наибольшей суммой применяется в области анализа данных, когда заданы числовые характеристики. Вероятность, обозначаемая x->y  и называемая правилом ассоциации, задается формулой условной вероятности:

conf(x->y)=support(x,y)/support(x)

Предположим, мы хотим видеть, имеет ли тенденцию определенная возрастная группа тенденцию покупать определенный товар. У нас имеются 2 числовые характеристики покупателей: их возраст и количество купленного товара. Эта задача может быть сведена к нашей задаче. Пусть есть массив из 6 элементов, в котором a[i] – число покупателей возраста от 10i до 10(i+1), и купивших товар А. У нас есть массив {0,1,2,0,0,0}, который нормализуем вычитанием среднего арифметического:

a={-1/2,1/2,3/2,-1/2, -1/2, -1/2}.

Подмассив a[2..3] имеет наибольшую сумму. Приходим к выводу, что основная группа покупателей – возрастом от 20 до 30 лет. Если имеются 2 числовые характеристики, то задача сведется к поиску подматрицы с наибольшей суммой.

P.S. Успехов всем участникам!

Почему именно Torque? Ответ на это вопрос достаточно прост. Torque является продолжением семейства систем управления PBS, одна из который установлена на Intel(R) Manycore Testing Lab.

Весь функционал, предоставляемый разработчиками систем управления кластерами, условно можно разделить на две группы:

1. Команды управления ресурсами:
   1. Постановка задачи в очередь системы управления для последующего исполнения.
   2. Остановка задачи, если она была запущена, или удаление из очереди системы управления, если она ожидает запуска.
2. Команды мониторинга:
   1. Получение актуальной информации о состоянии узлов системы управления.
   2. Получение информации о текущем состоянии задач.

Центральным компонентом системы управления кластером является планировщик. Именно планировщик обеспечивает эффективное использование узлов кластера. По мере поступления задач в очередь системы управления, каждая получает некоторый приоритет. Планировщик выбирает наиболее приоритетные задачи и в соответствии с некоторое стратегией планирования назначает узлы, на которых они будут исполняться. Фактически планировщик строит расписание запуска задач. В настоящее время наиболее распространенными стратегиями планирования являются FCFS (First Come First Served) и Backfilling.

В системе управления Torque существует встроенный планировщик, в котором реализован алгоритм FCFS. Наряду с этим, есть возможность подключения внешнего планировщика Maui . Разработчики Maui предоставляют несколько модификаций стратегии Backfilling, а именно FIRSTFIT, BESTFIT, GREEDY. Подробнее о том, как рабоают эти алгоримты можно познакомиться на официальной странице.

Команды управления ресурсами системы управления

1. Постановка задачи в очередь системы управления. Команда qsub .

Формат команды:

qsub [ключи] [script]

Наиболее важные ключи:

• [-a date_time] - время, после которого задача готова к исполнению.
• [-b secs] - максимальное время исполнения задачи (в секундах).
• [-c checkpoint_options] - применение механизма контрольных точек к задаче, запущенной на узле, при условии, что ОС поддерживает механизм контрольных точек.
• [-d path] - рабочая директория приложения.
• [-e path] - путь для перенаправления стандартного потока ошибок.
• [-I ] - интерактивный запуск задачи.
• [-l resource_list ] - определяет список ресурсов для запуска задачи на конкретном наборе ресурсов. Формат задания списка ресурсов следующий: resource_name[=[value]][,resource_name[=[value]],...]
• [-N name] - название задачи.
• [-o path] - директория для перенаправления стандартного потока вывода.
  [-p priority] - приоритет задачи (значение от -1024 до 1023).
• [-v variable_list] - установка списка переменных окружения.

Скрипт для запуска задачи [script] может состоять из директив, комментариев и исполняемых команд системы управления PBS. PBS-директивы обеспечивают добавление дополнительных аттрибутов к команде qsub. По существу qsub сканирует строки скрипта на наличие директив. Например, название задачи можно указать внутри скрипта с помощью слудующей директивы: #PBS -N my_job

Ниже приведен пример скрипта. Отметим, что в заголовке скрипта явно указывается интерпретатор. Последующие строки скрипта содержат установку переменной окружения, установку списка узлов (i-node и i-master) для запуска задачи, явную установку (cd) рабочей директории и прав пользователя (chmod) на эту директорию, а также непосредственный вызов для исполнения задачи

#!/bin/sh
PATH=/opt/openmpi_ifort_1.3.3/bin/:$PATH
#PBS -l nodes=i-node+i-master
cd /mnt/share/2322/
chmod 777 *
/mnt/share/2322/runMPI.sh > /mnt/share/2322/std.out

2. Остановка задачи. Команда qdel.

Формат команды:

qdel [ключи] <JobId> | 'all' | 'ALL'

Наиболее важные ключи:

• 'all' - удаление всех задач из очереди.

Команды мониторинга

1. Получение актуальной информации о состоянии узлов системы управления. Команда pbsnodes

Формат команды:

pbsnodes [ключи] [JobId]

Наиболее важные ключи:

• [-a] - получение всей информации обо всех узлах системы управления.
• [-x] - то же, что и предыдущий ключ, только результат выводится в формате xml.
• [-c] - убрать узлы, которые находятся в состоянии OFFLINE, из списка просматриваемых узлов.
• [-l] - получение названий узлов с их текущими состояниями.

2. Получение информации о текущем состоянии задачи. Команда qstat

Формат команды:

qstat [ключи]

Наиболее важные ключи:

• [-a] - выводится информация обо всех задачах, которые находятся в очереди системы управления.
• [-n] - дополнительно к состоянию задачи выводятся названия узлов, на которых была запущена задача.

Стандартный вывод команды gstat содержит следующую информацию о задаче:

Официальная страница, на которой размещена подробная документации.