valgrind и free pascal

Вопросы использования сторонних (не входящих в состав FPC и Lazarus) утилит и библиотек.

Модератор: Модераторы

valgrind и free pascal

Сообщение trifon » 24.10.2007 23:12:12

Попробовал отладку выделения памяти, использовал valgrind.

Код: Выделить всё
program simpl_test;
{$MODE OBJFPC}

type
  TSomeObj = class
  public
    constructor create();
    destructor  destroy;
  end;

constructor TSomeObj.create();
begin
end;

destructor  TSomeObj.destroy;
begin
end;

var
  obj : TSomeObj;
begin
  obj := TSomeObj.create();
  obj.destroy
end.


компилировал: fpc -g -gv -dDEBUG -dGDB valgr.pp
-gv: означает поддержку valgrind
запустил: valgrind --trace-children=yes --leak-check=full ./valgr
Код: Выделить всё
==27268== Memcheck, a memory error detector.
==27268== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==27268== Using LibVEX rev 1732, a library for dynamic binary translation.
==27268== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==27268== Using valgrind-3.2.3, a dynamic binary instrumentation framework.
==27268== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==27268== For more details, rerun with: -v
==27268==
==27268== Invalid free() / delete / delete[]
==27268==    at 0x402254C: free (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==27268==    by 0x4141CCE: __libc_freeres (in /lib/libc-2.6.1.so)
==27268==    by 0x401C256: _vgnU_freeres (in /usr/lib/valgrind/x86-linux/vgpreload_core.so)
==27268==    by 0x805E963: SYSTEM_SYSTEM_EXIT (in /home/wow/devel/pascal/system/valgr)
==27268==    by 0x80576D9: SYSTEM_DO_EXIT (in /home/wow/devel/pascal/system/valgr)
==27268==    by 0x805F890: SI_PRC__FPC_PROC_START (in /home/wow/devel/pascal/system/valgr)
==27268==  Address 0xFFFFFFFF is not stack'd, malloc'd or (recently) free'd
==27268==
==27268== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 7 from 1)
==27268== malloc/free: in use at exit: 0 bytes in 0 blocks.
==27268== malloc/free: 1 allocs, 2 frees, 8 bytes allocated.
==27268== For counts of detected errors, rerun with: -v
==27268== All heap blocks were freed -- no leaks are possible.


Пишет - Invalid free() / delete / delete[]
Чтобы это значило?
Хотя утечки памяти определяет верно.
trifon
постоялец
 
Сообщения: 135
Зарегистрирован: 24.12.2006 12:08:35

Сообщение Sergei I. Gorelkin » 24.10.2007 23:40:19

Судя по третьей строке снизу, похоже на попытку дважды освободить одну и ту же память. Возможно стоит поступить так, как он рекомендует - запустить с ключом -v.
Аватара пользователя
Sergei I. Gorelkin
энтузиаст
 
Сообщения: 1395
Зарегистрирован: 24.07.2005 14:40:41
Откуда: Зеленоград

Сообщение trifon » 24.10.2007 23:44:53

И еще прикол:
malloc/free: 1 allocs, 2 frees

если не вызывать obj.destroy, тогда количество allocs и frees будет равно друг другу.
По идее одно и то-же дважды не должно удалятся, иначе glibc обнаружит это.
trifon
постоялец
 
Сообщения: 135
Зарегистрирован: 24.12.2006 12:08:35

Сообщение trifon » 24.10.2007 23:51:31

Sergei I. Gorelkin писал(а):Судя по третьей строке снизу, похоже на попытку дважды освободить одну и ту же память. Возможно стоит поступить так, как он рекомендует - запустить с ключом -v.


ключ -v добавляет разную системную информацию, например heap и всё, я пробовал, если нужно могу полный вывод привести, там ничего интересного.
trifon
постоялец
 
Сообщения: 135
Зарегистрирован: 24.12.2006 12:08:35

Сообщение trifon » 25.10.2007 00:32:25

Хочу немного дополнить
В том-же коде комментируем obj.destroy

Код: Выделить всё
==29203== Memcheck, a memory error detector.
==29203== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==29203== Using LibVEX rev 1732, a library for dynamic binary translation.
==29203== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==29203== Using valgrind-3.2.3, a dynamic binary instrumentation framework.
==29203== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==29203== For more details, rerun with: -v
==29203==
==29203== Invalid free() / delete / delete[]
==29203==    at 0x402254C: free (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==29203==    by 0x4141CCE: __libc_freeres (in /lib/libc-2.6.1.so)
==29203==    by 0x401C256: _vgnU_freeres (in /usr/lib/valgrind/x86-linux/vgpreload_core.so)
==29203==    by 0x805E953: SYSTEM_SYSTEM_EXIT (in /home/wow/devel/pascal/system/valgr)
==29203==    by 0x80576C9: SYSTEM_DO_EXIT (in /home/wow/devel/pascal/system/valgr)
==29203==    by 0x805F880: SI_PRC__FPC_PROC_START (in /home/wow/devel/pascal/system/valgr)
==29203==  Address 0xFFFFFFFF is not stack'd, malloc'd or (recently) free'd
==29203==
==29203== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 7 from 1)
==29203== malloc/free: in use at exit: 8 bytes in 1 blocks.
==29203== malloc/free: 1 allocs, 1 frees, 8 bytes allocated.
==29203== For counts of detected errors, rerun with: -v
==29203== searching for pointers to 1 not-freed blocks.
==29203== checked 69,960 bytes.
==29203==
==29203==
==29203== 8 bytes in 1 blocks are possibly lost in loss record 1 of 1
==29203==    at 0x40229A8: malloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==29203==    by 0x805F096: CMEM_CGETMEM$LONGINT$$POINTER (in /home/wow/devel/pascal/system/valgr)
==29203==    by 0x8058EA6: SYSTEM_GETMEM$POINTER$LONGINT (in /home/wow/devel/pascal/system/valgr)
==29203==    by 0x8053851: SYSTEM_TOBJECT_$__NEWINSTANCE$$TOBJECT (in /home/wow/devel/pascal/system/valgr)
==29203==    by 0x80483F6: main (valgr.pp:23)
==29203==
==29203== LEAK SUMMARY:
==29203==    definitely lost: 0 bytes in 0 blocks.
==29203==      possibly lost: 8 bytes in 1 blocks.
==29203==    still reachable: 0 bytes in 0 blocks.
==29203==         suppressed: 0 bytes in 0 blocks.

==29203== malloc/free: 1 allocs, 1 frees, 8 bytes allocated.
..
..
==29203== possibly lost: 8 bytes in 1 blocks.


valgrind пишет, что количество malloc = free, что странно
однако определяет утечку: "possibly lost: 8 bytes in 1 blocks.", что правильно.
Похоже fpc один раз выделяет память, скрыто от valgrind, причем её освобождение valgrind видит.
Видимо ошибка fpc, а так пользоваться можно, valgrind очень серьёзная вещь.
trifon
постоялец
 
Сообщения: 135
Зарегистрирован: 24.12.2006 12:08:35

Сообщение Brainenjii » 25.10.2007 01:07:49

Сорри, если нупский вопрос, но попробовал на проекте с пустой формой - делаю valgrind ./project1 - и получаю
==28259== definitely lost: 34,081 bytes in 115 blocks.
==28259== possibly lost: 74,632 bytes in 71 blocks.
==28259== still reachable: 492,993 bytes in 6,603 blocks.
==28259== suppressed: 0 bytes in 0 blocks.
На проектах с гуем посущественней - вообще ужас... Хотя по коду вроде утечек и нет... Или я смотрю не на то что-то?
Аватара пользователя
Brainenjii
энтузиаст
 
Сообщения: 1351
Зарегистрирован: 10.05.2007 00:04:46

Сообщение trifon » 25.10.2007 01:49:13

и...? хочешь сказать, что valgrind гумно, а создатели fpc дурачки, вставили поддержку этого в своё поделие?
Свою мысль заканчивать нужно.
Возьмём код посложней
Код: Выделить всё
program malloc_test;

{$MODE OBJFPC}

type
  TMemManager = class
  public
    ptr  : Pointer;
    size : Cardinal;
    constructor create(sz : Cardinal);
    destructor  destroy; override;
    procedure   tfree;
    function    allocSize : PtrInt;
  end;

constructor TMemManager.create( sz : Cardinal );
begin
  size := sz;
  ptr := AllocMem(SizeOf(ptr)*size);
end;

destructor  TMemManager.destroy;
begin
  FreeMem(ptr)
end;

procedure   TMemManager.tfree;
begin
  FreeMem(ptr)
end;

function    TMemManager.allocSize : PtrInt;
begin
  allocSize := MemSize(ptr);
end;

var
  mem : TMemManager;
begin
  mem := TMemManager.create(256);
  writeln(mem.allocSize);
  mem.destroy
end.


Код: Выделить всё
==30968== Memcheck, a memory error detector.
==30968== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==30968== Using LibVEX rev 1732, a library for dynamic binary translation.
==30968== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==30968== Using valgrind-3.2.3, a dynamic binary instrumentation framework.
==30968== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==30968== For more details, rerun with: -v
==30968==
==30968== Invalid free() / delete / delete[]
==30968==    at 0x402254C: free (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==30968==    by 0x4141CCE: __libc_freeres (in /lib/libc-2.6.1.so)
==30968==    by 0x401C256: _vgnU_freeres (in /usr/lib/valgrind/x86-linux/vgpreload_core.so)
==30968==    by 0x805EA63: SYSTEM_SYSTEM_EXIT (in /home/wow/devel/pascal/system/malloc)
==30968==    by 0x80577D9: SYSTEM_DO_EXIT (in /home/wow/devel/pascal/system/malloc)
==30968==    by 0x805F990: SI_PRC__FPC_PROC_START (in /home/wow/devel/pascal/system/malloc)
==30968==  Address 0xFFFFFFFF is not stack'd, malloc'd or (recently) free'd
==30968==
==30968== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 7 from 1)
==30968== malloc/free: in use at exit: 0 bytes in 0 blocks.
==30968== malloc/free: 2 allocs, 3 frees, 1,044 bytes allocated.
==30968== For counts of detected errors, rerun with: -v
==30968== All heap blocks were freed -- no leaks are possible.


использовал ещё и AllocMem, что ещё нужно?
результат тот-же: "All heap blocks were freed -- no leaks are possible.", один malloc - фантом

Возможно надо собирать используемые компоненты lazarus с аналогичными дебаг опциями, а возможно виновато качество кода lazarus, бывает серьёзно текут весьма известные вещи.

Если есть альтернативы valgrind, для fpc - буду рад узнать о них, для с - чересчур много.
trifon
постоялец
 
Сообщения: 135
Зарегистрирован: 24.12.2006 12:08:35

Сообщение Brainenjii » 25.10.2007 02:07:56

никоим образом, сам давно искал средство для обнаружения утечек памяти (в нескольких топиках в разделе Lazarus спрашивал - ответа не было ^_^), просто может утечки памяти в самой LCL? Или смотреть надо не на количественные оценки утечки, а на что-то еще ?
Аватара пользователя
Brainenjii
энтузиаст
 
Сообщения: 1351
Зарегистрирован: 10.05.2007 00:04:46

Сообщение Sergei I. Gorelkin » 25.10.2007 02:42:30

А чем не подходят родные средства - heaptrc (компиляция с -gh), memcheck?

Даже большая утечка может быть обусловлена не-освобождением единственного объекта, вроде Application. Но если проект скомпилиован с отладочной информацией, причина легко находится по стеку вызовов.
Аватара пользователя
Sergei I. Gorelkin
энтузиаст
 
Сообщения: 1395
Зарегистрирован: 24.07.2005 14:40:41
Откуда: Зеленоград

Сообщение debi12345 » 25.10.2007 08:20:33

Valgring больше полезен не столько для определения утечек памяти (гораздо лучше с этим справляется сам FPC, с опцией "heaptrace") - сколько для отлавливания причин спорадических SegFault и AccessViolation.
Аватара пользователя
debi12345
долгожитель
 
Сообщения: 5752
Зарегистрирован: 10.05.2006 23:41:15
Откуда: Ташкент (Узбекистан)

Сообщение Brainenjii » 25.10.2007 11:23:44

Во, heaptrc мне понравилось гораздо больше - всего 5 неосвобожденных блоков ^_^ Только как их найти - как понимаю, после закрытия там выводятся Call trace for block $* size *, но что-то не совсем удается разобраться по ним - где не освобождается память...
Аватара пользователя
Brainenjii
энтузиаст
 
Сообщения: 1351
Зарегистрирован: 10.05.2007 00:04:46

Сообщение Sergei I. Gorelkin » 25.10.2007 16:35:05

Call trace показывает, где выделяется неосвобожденная память. Если в нем только цифры, а названий процедур нет - то надо перекомпилить с -gl. Ну а дальше уже надо смотреть по исходникам.
Аватара пользователя
Sergei I. Gorelkin
энтузиаст
 
Сообщения: 1395
Зарегистрирован: 24.07.2005 14:40:41
Откуда: Зеленоград

Сообщение Brainenjii » 27.10.2007 16:59:59

Поигрался с headtrc'ом - теперь если эту опцию включить в проект/опции компилятора/связызвание - после определенных действий проект падает с Access Violation, если же опция отключена - все нормально!!! В том месте где падает поставил блок Try / Except On E: Exception - опять же, если опция включена, то ShowMessage(E.Message); - срабатывает, если выключена - сообщение не появляется... Может быть проблема в том, что FPC стабильной версии 2.2.0, а Lazarus - из снапшота ?
Аватара пользователя
Brainenjii
энтузиаст
 
Сообщения: 1351
Зарегистрирован: 10.05.2007 00:04:46

Сообщение Sergei I. Gorelkin » 27.10.2007 18:23:01

Эти симптомы похожи на то, что где-то переписывается память за границей выделенного блока...
Я тему heaptrc + Lazarus особо не изучал, но тот факт, что у Лазаря есть свой "улучшенный и дополненный" heaptrc, называемый memcheck, наводит на определенные мысли.
Аватара пользователя
Sergei I. Gorelkin
энтузиаст
 
Сообщения: 1395
Зарегистрирован: 24.07.2005 14:40:41
Откуда: Зеленоград


Вернуться в Сторонние средства

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 2

Рейтинг@Mail.ru