valgrind сообщает о неверном чтении с помощью std :: string - PullRequest
0 голосов
/ 11 сентября 2018

Я работаю над кодом, который выполняется на Raspberry Pi 3. И получил следующие ошибки в моих классах журналирования.

==1297== Invalid read of size 8
==1297==    at 0x4865D1C: ??? (in /usr/lib/arm-linux-gnueabihf/libarmmem.so)
==1297==  Address 0x4c8d45c is 100 bytes inside a block of size 107 alloc'd
==1297==    at 0x4847DA4: operator new(unsigned int) (vg_replace_malloc.c:328)
==1297==    by 0x49C3D9B: std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::reserve(unsigned int) (in /usr/lib/arm-linux-gnueabihf/libstdc++.so.6.0.22)
==1297==    by 0x4AE65: std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > std::operator+<char, std::char_traits<char>, std::allocator<char> >(char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (basic_string.tcc:1155)
==1297==    by 0xF82B5: Log::Book::addField(std::unique_ptr<Log::Entry, std::default_delete<Log::Entry> >&, unsigned int, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (LogBook.cpp:149)
==1297==    by 0xF7CCB: Log::Book::record(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, int, unsigned int, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::chrono::time_point<std::chrono::_V2::system_clock, std::chrono::duration<long long, std::ratio<1ll, 1000000000ll> > >) (LogBook.cpp:87)

Версия GCC: версия gcc 6.3.0 20170516 (Raspbian 6.3.0-18 + rpi1 + deb9u1)
версия valgrind: valgrind-3.13.0
Кажется, я не могу найти проблему, так как функция Log :: Book :: record () получает ее значение через pass- by-значение.Я также могу сказать, что эта ошибка не всегда отображается при вызове функции.Он является детерминированным в том смысле, в какой строке отображается ошибка, а в какой нет.Кто-нибудь может направить меня в сторону того, что это за проблема и как ее решить?Ниже приведен фрагмент кода с комментарием к указанным строкам.

/** log message */
void Book::record(std::string file, const int line, const unsigned int level, Identifier id, const std::string message,
                  const std::chrono::high_resolution_clock::time_point timeStamp)
{
    if (!(fileLevels & level) && !(consoleLevels & level)) { return; }

    auto now = Time::keeper->now();
    auto duration = std::chrono::duration_cast<std::chrono::milliseconds>(timeStamp - Time::globalEpoch);

    //generate message
    auto entry = std::make_unique<Entry>(level);

    // Time since startup
    addField(entry, 0, std::to_string(duration.count()));

    //UTC Time
    addField(entry, 1, now.dateTime());

    // File
    std::string stringFile;
    if (!file.empty())
    {
        stringFile = URL{file}.lastPathComponent();
    }
    addField(entry, 2, stringFile);

    //Line number
    addField(entry, 3, std::to_string(line));

    //ID
    addField(entry, 4, id);

    //Message
    std::string stringMessage;
    if(!message.empty())
    {
        addField(entry, 5, message); //this is line LogBook.cpp:87
    }
    else
    {
        addField(entry, 5, " empty message.");
    }
    *entry << ";";

    //queue message
    this->append(std::move(entry));
}
void Book::addField(std::unique_ptr<Entry> &entry, unsigned int index, const std::string &text)
{
    std::string textOutput;

    if ((spacings.at(index) != 0) && (text.length() > (spacings.at(index) - 1)))
    {
        spacings.at(index) = (uint8_t) (text.length() + 2);
    }

    entry->setWidth(spacings.at(index));

    if(entry->empty())
        textOutput = text;
    else
        textOutput = ";" + text;   //This is line LogBook.cpp:149

    if(!textOutput.empty())
        (*entry) << textOutput;
}

Код вызова этой функции и возникновения этой проблемы.

auto node = child(items, "item", index);
auto enabled = boolValue(node, "enabled", false);
auto file = pathValue(node, key::path);
auto name = stringValue(node, "name", "");
auto type = stringValue(node, "type");

CLOG(CLOG::WARNING, "Yard item " + name + " not enabled, path:" + file.path());

Обновление 1: Я компилирую cmake с опциями.И добавлены дополнительные опции.Это не решило проблему.

add_compile_options(-ggdb)
add_compile_options(-O1)

#Extra disable vectorization
add_compile_options(-fno-tree-vectorize)
add_compile_options(-fno-tree-loop-vectorize)
add_compile_options(-fno-tree-slp-vectorize)

Обновление 2:
Я нашел другое место, где используется конкатенация строк и отчеты valgrind с такими же ошибками


Обновление 3:
Некоторое время и интересные открытия позже.Ошибка происходит в общей библиотеке libarmmem.so.Это загружается динамически и по этой причине всегда по другому адресу.Использовать комбинацию gdb и valgrind для прерывания при возникновении ошибки.
gdb загружает общие библиотеки с начальным адресом.

(gdb) info sharedlibrary
From        To          Syms Read   Shared Object Library
0x0483246c  0x04832750  Yes         /usr/local/lib/valgrind/vgpreload_core-arm-linux.so
0x04846e60  0x04850c10  Yes         /usr/local/lib/valgrind/vgpreload_memcheck-arm-linux.so
0x04863588  0x048672fc  Yes (*)     /usr/lib/arm-linux-gnueabihf/libarmmem.so
...

Ошибка, о которой сообщает valgrind.

==9442== Invalid read of size 8
==9442==    at 0x4865D34: ??? (in /usr/lib/arm-linux-gnueabi/libarmmem.so)

Мы знаем из readelflibarmmem.so, что раздел .text начинается на 588. и что memcpy сидит на 710. Разборка на этой точке останова показывает, что мы находимся в memcpy по адресу 0x04863710.Если мы проверим диапазон, например: 0x04863588 - 0x04863710 = 188. 188 + 588 (начальный адрес .text) = 710.
Разборка показывает, что это происходит на сборочной линии.vldmia - это инструкция для регистров с плавающей точкой вектора загрузки.

0x04865d34 <+9764>: vldmia  r1!, {d9}

Решения пока нет.

1 Ответ

0 голосов
/ 11 октября 2018

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

Подобные проблемы ухудшаются со временем и приводят кВальгринд менее полезен на практике.См. Valgrind против Оптимизирующих компиляторов для углубленного обсуждения или эту ошибку в diff для реального примера (или мой список подавления Debian для еще большего количества примеров).

...