Re: [Valgrind-users] Understand valgrind output when checking a fortran code for memory leaks

[David Chapman]

On 2/4/2016 1:30 PM, kevin.lemorzadec wrote:

Hi all,

I am having troubles understanding the outputs generated by valgrind.

I compile my fortran code with the following flags:  -c -tp x64 -r8 
-i4 -Mnolre -Mnovect -Mnounroll -g


I start it using valgrind doing: valgrind --tool=memcheck 
--leak-check=full ./rsiNE 54 2002SK1 NAEUa


rsiNE is a csh script starts the code with some parameters and file 
names doing:

#!/bin/csh
./paleonSG<< EOF >& out.pal
4 1 1
02
...
...
...
EOF


You are seeing messages from the execution of the shell (/bin/tcsh is a 
common implementation of the C shell), not the FORTRAN program launched 
inside.  Try adding the valgrind parameters to the front of the paleonSG 
command line within the script:


#!/bin/csh
valgrind --tool=memcheck --leak-check=full ./paleonSG<< EOF >& out.pal
...

By default valgrind does not trace into spawned programs, and there is 
no reason for you to look for memory leaks in tcsh unless you are a tcsh 
developer.





I use Valgrind-3.5.0 and added the apport-valgrind package

The output results are:

==4880== HEAP SUMMARY:
==4880== in use at exit: 174,555 bytes in 2,130 blocks
==4880==   total heap usage: 53,125 allocs, 50,995 frees, 16,456,811 
bytes allocated

==4880==
==4880== 4 bytes in 1 blocks are definitely lost in loss record 7 of 548
==4880==at 0x4A0610C: malloc (vg_replace_malloc.c:195)
==4880==by 0x439361: ??? (in /bin/tcsh)
==4880==by 0x43F964: ??? (in /bin/tcsh)
==4880==by 0x415F14: ??? (in /bin/tcsh)
==4880==by 0x412012: ??? (in /bin/tcsh)
==4880==by 0x41FD30: ??? (in /bin/tcsh)
==4880==by 0x41F827: ??? (in /bin/tcsh)
==4880==by 0x403BC4: ??? (in /bin/tcsh)
==4880==by 0x410EBE: ??? (in /bin/tcsh)
==4880==by 0x41FD30: ??? (in /bin/tcsh)
==4880==by 0x41F827: ??? (in /bin/tcsh)
==4880==by 0x403BC4: ??? (in /bin/tcsh)
==4880==
==4880== 8 bytes in 1 blocks are definitely lost in loss record 18 of 548
==4880==at 0x4A0610C: malloc (vg_replace_malloc.c:195)
==4880==by 0x4392EA: ??? (in /bin/tcsh)
==4880==by 0x41B33B: ??? (in /bin/tcsh)
==4880==by 0x404ABC: ??? (in /bin/tcsh)
==4880==by 0x41FD30: ??? (in /bin/tcsh)
==4880==by 0x41F827: ??? (in /bin/tcsh)
==4880==by 0x403BC4: ??? (in /bin/tcsh)
==4880==by 0x40470B: ??? (in /bin/tcsh)
==4880==by 0x404931: ??? (in /bin/tcsh)
==4880==by 0x404D84: ??? (in /bin/tcsh)
==4880==by 0x406910: ??? (in /bin/tcsh)
==4880==by 0x3522A1D9F3: (below main) (in /lib64/libc-2.5.so 
)

==4880==
==4880== 8 bytes in 1 blocks are definitely lost in loss record 19 of 548
==4880==at 0x4A0610C: malloc (vg_replace_malloc.c:195)
==4880==by 0x4392EA: ??? (in /bin/tcsh)
==4880==by 0x41B33B: ??? (in /bin/tcsh)
==4880==by 0x404ABC: ??? (in /bin/tcsh)
==4880==by 0x4067B9: ??? (in /bin/tcsh)
==4880==by 0x3522A1D9F3: (below main) (in /lib64/libc-2.5.so 
)

==4880==
==4880== 8 bytes in 1 blocks are definitely lost in loss record 20 of 548
==4880==at 0x4A0610C: malloc (vg_replace_malloc.c:195)
==4880==by 0x4392EA: ??? (in /bin/tcsh)
==4880==by 0x41B33B: ??? (in /bin/tcsh)
==4880==by 0x404ABC: ??? (in /bin/tcsh)
==4880==by 0x41677B: ??? (in /bin/tcsh)
==4880==by 0x405FD9: ??? (in /bin/tcsh)
==4880==by 0x3522A1D9F3: (below main) (in /lib64/libc-2.5.so 
)

==4880==
==4880== 16 bytes in 1 blocks are definitely lost in loss record 120 
of 548

==4880==at 0x4A0610C: malloc (vg_replace_malloc.c:195)
==4880==by 0x4392EA: ??? (in /bin/tcsh)
==4880==by 0x41AFC8: ??? (in /bin/tcsh)
==4880==by 0x410C43: ??? (in /bin/tcsh)
==4880==by 0x41FD30: ??? (in /bin/tcsh)
==4880==by 0x41F827: ??? (in /bin/tcsh)
==4880==by 0x403BC4: ??? (in /bin/tcsh)
==4880==by 0x40470B: ??? (in /bin/tcsh)
==4880==by 0x404931: ??? (in /bin/tcsh)
==4880==by 0x404A42: ??? (in /bin/tcsh)
==4880==by 0x41FD30: ??? (in /bin/tcsh)
==4880==by 0x41F827: ??? (in /bin/tcsh)
==4880==
==4880== 24 bytes in 3 blocks are definitely lost in loss record 240 
of 548

==4880==at 0x4A0610C: malloc (vg_replace_malloc.c:195)
==4880==by 0x4392EA: ??? (in /bin/tcsh)
==4880==by 0x41B33B: ??? (in /bin/tcsh)
==4880==by 0x404ABC: ??? (in /bin/tcsh)
==4880==by 0x41FD30: ??? (in /bin/tcsh)
==4880==by 0x41F827: ??? (in /bin/tcsh)
==4880==by 0x403BC4: ??? (in /bin/tcsh)
==4880==by 0x40470B: ??? (in /bin/tcsh)
==4880==by 0x404931: ??? (in /bin/tcsh)
==4880==by 0x404A42: ??? (in /bin/tcsh)
==4880==by 0x41FD30: ??? (in /bin/tcsh)
==4880==by 0x41F827: ??? (in /bin/tcsh)
==4880==
==4880== 104 bytes in 13 blocks are definitely lost in loss record 493 
of 548

==4880==at 0x4A0610C: malloc (vg_replace_malloc.c:195)
==4880==by 0x4392EA: ??? (in /bin/tcsh)
==4880==by 0x41B33B: ??? (in /bin/tcsh)
==4880==by 0x404ABC: ??? (in /bin/tcsh)
==4880==by 0x41FD30: ??? (in /bin/tcsh)
==4880==by 

Re: [Valgrind-users] Understand valgrind output when checking a fortran code for memory leaks

[John Reiser]

> I compile my fortran code with the following flags:  -c -tp x64 -r8 -i4 
> -Mnolre -Mnovect -Mnounroll -g
>
> I start it using valgrind doing: valgrind --tool=memcheck --leak-check=full 
> ./rsiNE 54 2002SK1 NAEUa
>
> rsiNE is a csh script starts the code with some parameters and file names 
> doing:
> #!/bin/csh
> ./paleonSG<< EOF >& out.pal
> 4 1 1
> 02
> ...
> ...
> ...
> EOF

> I use Valgrind-3.5.0 and added the apport-valgrind package

> Any idea of what I am doing wrong??

You are using valgrind-3.5.0 which is FIVE YEARS OBSOLETE.
The current version is 3.11.0.  UPGRADE NOW!

Then grab a clue from:
valgrind --help  |  grep child


--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

[Valgrind-users] Understand valgrind output when checking a fortran code for memory leaks

[kevin.lemorzadec]

Hi all,

I am having troubles understanding the outputs generated by valgrind.

I compile my fortran code with the following flags:  -c -tp x64 -r8 -i4
-Mnolre -Mnovect -Mnounroll -g

I start it using valgrind doing: valgrind --tool=memcheck --leak-check=full
./rsiNE 54 2002SK1 NAEUa

rsiNE is a csh script starts the code with some parameters and file names
doing:
#!/bin/csh
./paleonSG<< EOF >& out.pal
4 1 1
02
...
...
...
EOF


I use Valgrind-3.5.0 and added the apport-valgrind package

The output results are:

==4880== HEAP SUMMARY:
==4880== in use at exit: 174,555 bytes in 2,130 blocks
==4880==   total heap usage: 53,125 allocs, 50,995 frees, 16,456,811 bytes
allocated
==4880==
==4880== 4 bytes in 1 blocks are definitely lost in loss record 7 of 548
==4880==at 0x4A0610C: malloc (vg_replace_malloc.c:195)
==4880==by 0x439361: ??? (in /bin/tcsh)
==4880==by 0x43F964: ??? (in /bin/tcsh)
==4880==by 0x415F14: ??? (in /bin/tcsh)
==4880==by 0x412012: ??? (in /bin/tcsh)
==4880==by 0x41FD30: ??? (in /bin/tcsh)
==4880==by 0x41F827: ??? (in /bin/tcsh)
==4880==by 0x403BC4: ??? (in /bin/tcsh)
==4880==by 0x410EBE: ??? (in /bin/tcsh)
==4880==by 0x41FD30: ??? (in /bin/tcsh)
==4880==by 0x41F827: ??? (in /bin/tcsh)
==4880==by 0x403BC4: ??? (in /bin/tcsh)
==4880==
==4880== 8 bytes in 1 blocks are definitely lost in loss record 18 of 548
==4880==at 0x4A0610C: malloc (vg_replace_malloc.c:195)
==4880==by 0x4392EA: ??? (in /bin/tcsh)
==4880==by 0x41B33B: ??? (in /bin/tcsh)
==4880==by 0x404ABC: ??? (in /bin/tcsh)
==4880==by 0x41FD30: ??? (in /bin/tcsh)
==4880==by 0x41F827: ??? (in /bin/tcsh)
==4880==by 0x403BC4: ??? (in /bin/tcsh)
==4880==by 0x40470B: ??? (in /bin/tcsh)
==4880==by 0x404931: ??? (in /bin/tcsh)
==4880==by 0x404D84: ??? (in /bin/tcsh)
==4880==by 0x406910: ??? (in /bin/tcsh)
==4880==by 0x3522A1D9F3: (below main) (in /lib64/libc-2.5.so)
==4880==
==4880== 8 bytes in 1 blocks are definitely lost in loss record 19 of 548
==4880==at 0x4A0610C: malloc (vg_replace_malloc.c:195)
==4880==by 0x4392EA: ??? (in /bin/tcsh)
==4880==by 0x41B33B: ??? (in /bin/tcsh)
==4880==by 0x404ABC: ??? (in /bin/tcsh)
==4880==by 0x4067B9: ??? (in /bin/tcsh)
==4880==by 0x3522A1D9F3: (below main) (in /lib64/libc-2.5.so)
==4880==
==4880== 8 bytes in 1 blocks are definitely lost in loss record 20 of 548
==4880==at 0x4A0610C: malloc (vg_replace_malloc.c:195)
==4880==by 0x4392EA: ??? (in /bin/tcsh)
==4880==by 0x41B33B: ??? (in /bin/tcsh)
==4880==by 0x404ABC: ??? (in /bin/tcsh)
==4880==by 0x41677B: ??? (in /bin/tcsh)
==4880==by 0x405FD9: ??? (in /bin/tcsh)
==4880==by 0x3522A1D9F3: (below main) (in /lib64/libc-2.5.so)
==4880==
==4880== 16 bytes in 1 blocks are definitely lost in loss record 120 of 548
==4880==at 0x4A0610C: malloc (vg_replace_malloc.c:195)
==4880==by 0x4392EA: ??? (in /bin/tcsh)
==4880==by 0x41AFC8: ??? (in /bin/tcsh)
==4880==by 0x410C43: ??? (in /bin/tcsh)
==4880==by 0x41FD30: ??? (in /bin/tcsh)
==4880==by 0x41F827: ??? (in /bin/tcsh)
==4880==by 0x403BC4: ??? (in /bin/tcsh)
==4880==by 0x40470B: ??? (in /bin/tcsh)
==4880==by 0x404931: ??? (in /bin/tcsh)
==4880==by 0x404A42: ??? (in /bin/tcsh)
==4880==by 0x41FD30: ??? (in /bin/tcsh)
==4880==by 0x41F827: ??? (in /bin/tcsh)
==4880==
==4880== 24 bytes in 3 blocks are definitely lost in loss record 240 of 548
==4880==at 0x4A0610C: malloc (vg_replace_malloc.c:195)
==4880==by 0x4392EA: ??? (in /bin/tcsh)
==4880==by 0x41B33B: ??? (in /bin/tcsh)
==4880==by 0x404ABC: ??? (in /bin/tcsh)
==4880==by 0x41FD30: ??? (in /bin/tcsh)
==4880==by 0x41F827: ??? (in /bin/tcsh)
==4880==by 0x403BC4: ??? (in /bin/tcsh)
==4880==by 0x40470B: ??? (in /bin/tcsh)
==4880==by 0x404931: ??? (in /bin/tcsh)
==4880==by 0x404A42: ??? (in /bin/tcsh)
==4880==by 0x41FD30: ??? (in /bin/tcsh)
==4880==by 0x41F827: ??? (in /bin/tcsh)
==4880==
==4880== 104 bytes in 13 blocks are definitely lost in loss record 493 of
548
==4880==at 0x4A0610C: malloc (vg_replace_malloc.c:195)
==4880==by 0x4392EA: ??? (in /bin/tcsh)
==4880==by 0x41B33B: ??? (in /bin/tcsh)
==4880==by 0x404ABC: ??? (in /bin/tcsh)
==4880==by 0x41FD30: ??? (in /bin/tcsh)
==4880==by 0x41F827: ??? (in /bin/tcsh)
==4880==by 0x403BC4: ??? (in /bin/tcsh)
==4880==by 0x40470B: ??? (in /bin/tcsh)
==4880==by 0x404931: ??? (in /bin/tcsh)
==4880==by 0x406734: ??? (in /bin/tcsh)
==4880==by 0x3522A1D9F3: (below main) (in /lib64/libc-2.5.so)
==4880==
==4880== 920 bytes in 3 blocks are definitely lost in loss record 518 of 548
==4880==at 0x4A0610C: malloc (vg_replace_malloc.c:195)
==4880==by 0x4392EA: ??? (in /bin/tcsh)
==4880==by 0x41AFC8: ??? (in /bin/tcsh)
==4880==by 0x410C43: ??? (in /bin/tcsh)
==4880==by 0x41FD30: ??? (in /bin/tcsh)
==4880==by 0x41F7D8: ??? (in /bin/tcsh)

Re: [Valgrind-users] Assertion 'eltSzB <= ddpa->poolSzB' failed

[Philippe Waroquiers]

On Thu, 2016-02-04 at 08:54 +0100, Florian Krohm wrote:
> On 03.02.2016 21:50, Philippe Waroquiers wrote:
> > 
> > The assert might be caused by the debuginfo containing a string bigger
> > than SEGINFO_STRPOOLSIZE (64Kb).
> 
> Why exactly are we having yet another fixed size buffer here?
> I've spent a lot of time crawling through the code and getting rid of
> those. To read this is a bit of a disappointment.
Yes, the work on removing or auditing the maxima was a nice thing.
For this particular fixed size:
This is not a (very) new fixed size buffer.
It was already there at least in 3.9.0 (did not check before).
In fact, I suspect that in 3.9.0, exceeding the maxima was
causing a buffer overflow (i.e. was not checked).

I think it should not be that difficult to allow to exceed the
pool size (but still keeping the pool size reasonable, and allocate
a bigger one only when needed).

Still, finding a 64kb string in the debug info is strange.


Philippe



--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users