Повышение точности valgrind memcheck ?

[navrocky]

Столкнулся с проблемой, что valgrind (из под qtcreator) показывает стеки на утечках не полные, т.е. не хватает одного или нескольких вызовов в вершине стека:

Код:

472 (52 direct, 420 indirect) bytes in 1 blocks are definitely lost in loss record 956 of 1,090
  in vd::scenario_executor::module::show_report(vd::guid_t const&, vd::cntr::container const&) in client/modules/scenario_executor/impl/module.cpp:233
  1: operator new(unsigned int) in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so
  2: vd::scenario_executor::module::show_report(vd::guid_t const&, vd::cntr::container const&) in client/modules/scenario_executor/impl/module.cpp:233
  3: vd::scenario_executor::module::process_raw_command(vd::transport::raw_command const&, boost::shared_ptr<vd::transport::command_custom>&) in client/modules/scenario_executor/impl/module.cpp:435
.....

Такое ощущение, что между пунктом 1. и пунктом 2. пропущен один вызов или несколько, т.к. при переходе на строку №2. такой код:

Код

C++ (Qt)
       static_maket_model repgen(&dm);
==>    if (!repgen.load(model_xml))
           throw error(repgen.get_last_error());

То есть, очевидно течет где-то в недрах repgen.load(). Причем я уже нашел достаточно много таких утечек и они реально были, просто valgrind не показывал полностью стек, приходилось долго просматривать код вокруг.

Компилируется проект с такими вот флагами:

Код:

/usr/bin/c++ -DDEBUG -DQT_GUI_LIB -DQT_XML_LIB -DQT_CORE_LIB -DQT_DEBUG -fno-elide-constructors -fno-implement-inlines -fno-implicit-inline-templates -fno-default-inline -fno-inline -Wall -Woverloaded-virtual -fexceptions -fnon-call-exceptions -g

Как можно улучшить вывод valgrind? Какие еще ключи можно добавить компилятору?

[navrocky]

бамп

[GreatSnake]

Какие еще ключи можно добавить компилятору?

Чего-то не видно -O0.

[navrocky]

Помогло! Благодарствую. Я что-то думал, что наличие -g подразумевает отключение оптимизации по умолчанию (

[b-s-a]

-g добавляет отладочные символы в код программы. К оптимизиции это вообще отношения не имеет.
А потом, как бы можно было отлаживать программу, которая без оптимизации работает, а с оптимизацией нет?

[GreatSnake]

-g добавляет отладочные символы в код программы. К оптимизиции это вообще отношения не имеет.
А потом, как бы можно было отлаживать программу, которая без оптимизации работает, а с оптимизацией нет?

И каков, интересно, опыт отладки с -O3?
И как успешно ставятся breakpoints в inline методах?

[navrocky]

Отладчик при O3 забавно скачет по команде step ). Видимо отлаживаться с оптимизацией можно только дизассемблере.

[b-s-a]

И каков, интересно, опыт отладки с -O3?
И как успешно ставятся breakpoints в inline методах?

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

[navrocky]

Вопрос остается открытый. Первую запись в стеке valgrind упорно не показывает. Что делать?

Вот такой код:

Код

C++ (Qt)
void func(int a, int b)
{
    new char[a * b];
}
 
int main(int, char**)
{
    func(50, 20);
}
 

Вот так компилится:

Код:

g++ -g -O0 main.cpp -o test_valgrind

Вот так запускаю valgrind:

Код:

valgrind --leak-check=full ./test_valgrind

Результат:

Код:

==7157== Memcheck, a memory error detector
==7157== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==7157== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==7157== Command: ./test_valgrind
==7157== 
==7157== 
==7157== HEAP SUMMARY:
==7157==     in use at exit: 1,000 bytes in 1 blocks
==7157==   total heap usage: 9 allocs, 8 frees, 1,336 bytes allocated
==7157== 
==7157== 1,000 bytes in 1 blocks are definitely lost in loss record 1 of 1
==7157==    at 0x4028699: operator new[](unsigned int) (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==7157==    by 0x8048587: main (main.cpp:8)
==7157== 
==7157== LEAK SUMMARY:
==7157==    definitely lost: 1,000 bytes in 1 blocks
==7157==    indirectly lost: 0 bytes in 0 blocks
==7157==      possibly lost: 0 bytes in 0 blocks
==7157==    still reachable: 0 bytes in 0 blocks
==7157==         suppressed: 0 bytes in 0 blocks
==7157== 
==7157== For counts of detected and suppressed errors, rerun with: -v
==7157== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 37 from 8)

Вот сама суть результата:

Код:

==7157== 1,000 bytes in 1 blocks are definitely lost in loss record 1 of 1
==7157==    at 0x4028699: operator new[](unsigned int) (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==7157==    by 0x8048587: main (main.cpp:8)

Здесь видно, что в стеке пропущен вызов func().

Соответственно такой эффект я наблюдаю везде и очень тяжко искать утечки.

Код:

vlad@vlad:~/tmp/test_valgrind> valgrind --version
valgrind-3.6.1

Кому несложно проверьте у себя этот пример, может существуют версии valgrind которые нормально отображают стеки?

UPD. Установил последнюю версию 3.8.1 - та же петрушка.

[b-s-a]

Подозреваю, что дело не в valgrind, а в gcc. Который заинлайнил твою функцию. Попробуй указать ключ компиляции -g3 или -ggdb вместо -g. Если не поможет, то ищи опции gcc, принудительно отключающие встраивание.

[navrocky]

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

main():

Код:

        7	{
0x804856b  <+0x0000>         push   %ebp
0x804856c  <+0x0001>         mov    %esp,%ebp
0x804856e  <+0x0003>         and    $0xfffffff0,%esp
0x8048571  <+0x0006>         sub    $0x10,%esp
        8	    func(50, 20);
0x8048574  <+0x0009>         movl   $0x14,0x4(%esp)
0x804857c  <+0x0011>         movl   $0x32,(%esp)
0x8048583  <+0x0018>         call   0x8048554 <func(int, int)>
0x8048588  <+0x001d>         mov    $0x0,%eax
        9	}
0x804858d  <+0x0022>         leave
0x804858e  <+0x0023>         ret

func():

Код:

        2	{
0x8048554  <+0x0000>         push   %ebp
0x8048555  <+0x0001>         mov    %esp,%ebp
0x8048557  <+0x0003>         sub    $0x18,%esp
        3	    new char[a * b];
0x804855a  <+0x0006>         mov    0x8(%ebp),%eax
0x804855d  <+0x0009>         imul   0xc(%ebp),%eax
0x8048561  <+0x000d>         mov    %eax,(%esp)
0x8048564  <+0x0010>         call   0x8048464 <_Znaj@plt>
        4	}
0x8048569  <+0x0015>         leave
0x804856a  <+0x0016>         ret