Минимальная программа выдает предупреждения Valgrind на g++, но не на clang или VS

Я схожу с ума, выискивая ошибки памяти в проекте среднего размера. Я свернул один из них до приведенного ниже кода и убедился, что это вызывает предупреждения Valgrind о недопустимом чтении по номерам строк с комментариями. Я использую g++ 4.8.2 (Debian 4.8.2-16) для проекта, компилируя с -std= C++11 -O0. g++ 4.7.0 также выдает ошибки, как и 4.4.6 в слегка измененной версии (для удаления C++11). Clang ++ не приводит к ошибкам, как и VS2013.

Мой вопрос:

  1. Я неосознанно участвую в неопределенном поведении?

  2. Является ли это ложным срабатыванием Вальгринда, и если да, то как я могу успокоить себя в подобных ситуациях в будущем?

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

// Types are a little strange because I wanted the minimal failing
// case -- eg, row/col used to be ints.
#include <cassert>
#include <iostream>
#include <vector>

class Coord {
  public:
    bool row, col, layer;
};

void foo(Coord wtf) { }

std::vector<Coord> baz() {
  std::vector<Coord> bees;
  for (int i = 0; i < 4; ++i) {
    bees.push_back({1, 1, 1});
  }
  return bees;
}


int main(int argc, char** argv) {
  auto vec = baz();
  assert(vec.size() > 3);
  Coord bbb = vec[3];
  foo(bbb);
  static int i = 0;
  foo(vec.at(3)); // Causes Valgrind warning.

  Coord& ccc = vec[3];
  foo(ccc);      // causes Valgrind warning
}

Выход Valgrind:

==17700== Memcheck, a memory error detector
==17700== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==17700== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info
==17700== Command: ./a.out
==17700== 
==17700== Invalid read of size 8
==17700==    at 0x400BC9: main (in /home/alexr/projects/suncatcher/a.out)
==17700==  Address 0x59f80e9 is 9 bytes inside a block of size 12 alloc'd
==17700==    at 0x4C27A00: operator new(unsigned long) (vg_replace_malloc.c:319)
==17700==    by 0x40150A: __gnu_cxx::new_allocator<Coord>::allocate(unsigned long, void const*) (in /home/alexr/projects/suncatcher/a.out)
==17700==    by 0x4013A2: std::_Vector_base<Coord, std::allocator<Coord> >::_M_allocate(unsigned long) (in /home/alexr/projects/suncatcher/a.out)
==17700==    by 0x401061: void std::vector<Coord, std::allocator<Coord> >::_M_emplace_back_aux<Coord>(Coord&&) (in /home/alexr/projects/suncatcher/a.out)
==17700==    by 0x400F02: void std::vector<Coord, std::allocator<Coord> >::emplace_back<Coord>(Coord&&) (in /home/alexr/projects/suncatcher/a.out)
==17700==    by 0x400D25: std::vector<Coord, std::allocator<Coord> >::push_back(Coord&&) (in /home/alexr/projects/suncatcher/a.out)
==17700==    by 0x400B17: baz() (in /home/alexr/projects/suncatcher/a.out)
==17700==    by 0x400B64: main (in /home/alexr/projects/suncatcher/a.out)
==17700== 
==17700== Invalid read of size 8
==17700==    at 0x400BEA: main (in /home/alexr/projects/suncatcher/a.out)
==17700==  Address 0x59f80e9 is 9 bytes inside a block of size 12 alloc'd
==17700==    at 0x4C27A00: operator new(unsigned long) (vg_replace_malloc.c:319)
==17700==    by 0x40150A: __gnu_cxx::new_allocator<Coord>::allocate(unsigned long, void const*) (in /home/alexr/projects/suncatcher/a.out)
==17700==    by 0x4013A2: std::_Vector_base<Coord, std::allocator<Coord> >::_M_allocate(unsigned long) (in /home/alexr/projects/suncatcher/a.out)
==17700==    by 0x401061: void std::vector<Coord, std::allocator<Coord> >::_M_emplace_back_aux<Coord>(Coord&&) (in /home/alexr/projects/suncatcher/a.out)
==17700==    by 0x400F02: void std::vector<Coord, std::allocator<Coord> >::emplace_back<Coord>(Coord&&) (in /home/alexr/projects/suncatcher/a.out)
==17700==    by 0x400D25: std::vector<Coord, std::allocator<Coord> >::push_back(Coord&&) (in /home/alexr/projects/suncatcher/a.out)
==17700==    by 0x400B17: baz() (in /home/alexr/projects/suncatcher/a.out)
==17700==    by 0x400B64: main (in /home/alexr/projects/suncatcher/a.out)
==17700== 
==17700== 
==17700== HEAP SUMMARY:
==17700==     in use at exit: 0 bytes in 0 blocks
==17700==   total heap usage: 3 allocs, 3 frees, 21 bytes allocated
==17700== 
==17700== All heap blocks were freed -- no leaks are possible
==17700== 
==17700== For counts of detected and suppressed errors, rerun with: -v
==17700== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 2 from 2)
Источник

1 ответ

Решение

Похоже, что gcc делает вывод о загрузке "призрачных" данных для оптимизации нескольких инструкций, https://bugs.kde.org/show_bug.cgi?id=264936

Я бы добавил макрос, что-то вроде

#ifdef SOMETHING_SOMETHING
#define SUPRESS_VALGRIND_FALSE_POSITIVES __attribute__((__aligned__(8)))
#else
#define SUPRESS_VALGRIND_FALSE_POSITIVES
#endif

...
class Coord {
  public:
    bool row, col, layer;
} SUPRESS_VALGRIND_FALSE_POSITIVES ;

на самом деле может быть полезно принудительное выравнивание независимо от производительности.

Источник
Другие вопросы по тегам