[fpc-pascal] FPC + valgrind massif problems

[Michalis Kamburelis]

Hi,

I wanted to debug where my program uses the most memory. (There are no 
memory leaks, but I want to optimize memory usage on some large inputs. 
As the code is quite large, simply guessing which part is responsible 
becomes quite hard :) In the past, I happily used valgrind's massif tool 
for such job, and it worked like a charm. But now, FPC 2.6.0 with 
valgrind 3.7.0, it seems valgrind/massif has problems:

$ fpc -gv trivial_alloc.pas
$ valgrind --tool=massif ./trivial_alloc
....
--7286-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 
(SIGSEGV) - exiting
--7286-- si_code=1;  Faulting address: 0xFFFFFFF7;  sp: 0x6298914c
valgrind: the 'impossible' happened:
    Killed by fatal signal

(Full output and trivial_alloc.pas attached.)

The code is compiled with -gv option. It works very fine with valgrind's 
callgrind tool. So I suspect this is a problem with valgrind, 
specifically massif, not related to FPC. Also, it seems to fail the same 
way with older/newer FPC versions (I tried 2.2.4, 2.4.4, 2.6.0, and 
2.7.1 from today 2012-05-11). Probably, some valgrind version broke 
massif for FPC binaries.

So, questions:

1. I want to report this as massif's bug. Any ideas what more 
information should I provide to valgrind's developers? I don't know if 
they are familiar with FPC. And simple C examples work fine, so it's 
probably something specific in FPC binaries.

- Maybe this problem is already reported?

- Maybe there's a workaround? IOW, can someone successfully use massif 
with FPC programs?

2. Is there any other reliable memory profiler for FPC? As you can swap 
memory manager in Pascal, and FPC can give you a backtrace, I suppose 
it's quite possible to just write a unit that works between your program 
and standard memory manager, and tracks memory usage this way. This will 
only measure memory use of Pascal code (external libs don't go through 
FPC memory manager), but that would be very fine for me --- I know 
(well, I'm 99% sure) that my Pascal code is the main memory eater here.

I didn't find any (good and maintained) memory profiler mentioned on 
http://wiki.lazarus.freepascal.org/Profiling#Memory_Profiling . (I tried 
FpProfiler, but it depends on inserting instrumentation code into Pascal 
sources. That's actually a very nice idea, but it means it's closely 
tied to what fcl-passrc can handle. And current fcl-passrc still lacks a 
couple of features (reported). Also FpProfiler seems to use an older, 
local fcl-passrc version.)

Thanks,
Michalis
-------------- next part --------------
==7310== Massif, a heap profiler
==7310== Copyright (C) 2003-2011, and GNU GPL'd, by Nicholas Nethercote
==7310== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==7310== Command: ./trivial_alloc
==7310== 
--7310-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting
--7310-- si_code=1;  Faulting address: 0xFFFFFFF7;  sp: 0x627fb14c

valgrind: the 'impossible' happened:
   Killed by fatal signal
==7310==    at 0x38028524: ??? (in /usr/lib/valgrind/massif-x86-linux)
==7310==    by 0x38060AB6: ??? (in /usr/lib/valgrind/massif-x86-linux)
==7310==    by 0x380635FD: ??? (in /usr/lib/valgrind/massif-x86-linux)
==7310==    by 0x38024CA2: ??? (in /usr/lib/valgrind/massif-x86-linux)
==7310==    by 0x38025542: ??? (in /usr/lib/valgrind/massif-x86-linux)
==7310==    by 0x3807560D: ??? (in /usr/lib/valgrind/massif-x86-linux)

sched status:
  running_tid=1

Thread 1: status = VgTs_Runnable
==7310==    at 0x402428C: free (in /usr/lib/valgrind/vgpreload_massif-x86-linux.so)
==7310==    by 0x416D4C4: __libc_freeres (in /lib/i386-linux-gnu/i686/cmov/libc-2.13.so)
==7310==    by 0x4020466: _vgnU_freeres (in /usr/lib/valgrind/vgpreload_core-x86-linux.so)
==7310==    by 0x805F113: SYSTEM_SYSTEM_EXIT (in /tmp/trivial_alloc)
==7310==    by 0x8058819: SYSTEM_DO_EXIT (in /tmp/trivial_alloc)
==7310==    by 0x805FA66: SI_PRC__FPC_PROC_START (in /tmp/trivial_alloc)


Note: see also the FAQ in the source distribution.
It contains workarounds to several common problems.
In particular, if Valgrind aborted or crashed after
identifying problems in your program, there's a good chance
that fixing those problems will prevent Valgrind aborting or
crashing, especially if it happened in m_mallocfree.c.

If that doesn't help, please report this bug to: www.valgrind.org

In the bug report, send all the above text, the valgrind
version, and what OS and version you are using.  Thanks.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: trivial_alloc.pas
Type: text/x-pascal
Size: 50 bytes
Desc: not available
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20120511/1b6eabc1/attachment.pas>