valgrind-users — General discussion list for Valgrind users

[Valgrind-users] what are the commands to check this scheduler code?

[Mandy M. <te...@ho...>]

Hi


There is a need to recompile kernel to patch this module, how to check and step by step debug run this scheduler with valgrind before patch to kernel ?

what are the commands to check this scheduler code?


http://www.embedded.com/design/operating-systems/4204980/Real-Time-Linux-Scheduling-Part-3

[http://www.embedded.com/content/images/icons/contentitem-default.png]<http://www.embedded.com/design/operating-systems/4204980/Real-Time-Linux-Scheduling-Part-3>

Implementing a new real-time scheduling policy for Linux ...<http://www.embedded.com/design/operating-systems/4204980/Real-Time-Linux-Scheduling-Part-3>
www.embedded.com
Implementing a new real-time scheduling policy for Linux: Part 3. Paulo Baltarejo Sousa and Luis Lino Ferreira, Polytechnic Institute of Porto July 28 ...



Regards,


Martin

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

[David H. <da...@da...>]

Hi Philippe,

sorry to be poking about this again. Is there any news on the issue? Can I
help to provide a fix for it? Would increasing the pool size really be a
good fix? Or should the code be re-written to dynamically allocate the
needed memory? I guess another solution could be to just truncate the
string, if it is just debug information then that would at least be better
that crashing?

Let me know how I can help

Thanks

/David

On Mon, Feb 8, 2016 at 2:19 PM, David Hallas <da...@da...> wrote:

> Hi Philippe,
>
> thanks a lot for your help. I have created this ticket
> https://bugs.kde.org/show_bug.cgi?id=359133 to track the issue.
>
> I was wondering, is there some kind out of out buffering when using printf
> in valgrind? I guess that could explain why I do not see the debug print?
>
> Thanks
>
> /David
>
> On Fri, Feb 5, 2016 at 9:05 PM, Philippe Waroquiers <
> phi...@sk...> wrote:
>
>> On Fri, 2016-02-05 at 11:20 +0100, David Hallas wrote:
>>
>>
>> > thanks for the reply. I tried increasing the SEGINFO_STRPOOLSIZE as
>> > you requested, and for me the magic number is 268*1024 then the assert
>> > goes away :) I also tried to add the print to the ML_(addStr) function
>> > in storage.c but for some reason I never see the print?
>> Strange. VG_(printf) prints unconditionally.
>> >
>> > I tried to play with objdump and nm to find some large symbols, but I
>> > think I do not have enough objdump/nm skills to do that. But I also
>> > tried to play with strings and I found one string (a symbol name) that
>> > is 274154 bytes long (this fits perfectly with that I see the problem
>> > if the SEGINFO_STRPOOLSIZE is 267*1024 but not with 268*1024). The
>> > code that I am debugging is using a lot of templates, so go figure ;)
>> > So I think it sounds very plausible that it is this string that is
>> > causing the problem?
>> A symbol name of 268 Kb is quite impressive,
>> I hope you never have to print this variable in gdb :).
>> >
>> > Please let me know if there is any other information that you need? Or
>> > if you have some other things to test.
>> The information is clear, I think the problem is identified now.
>> The best is to file a bug entry in bugzilla, I hope to fix
>> this problem in the coming weeks or so.
>>
>> Thanks
>>
>> Philippe
>>
>>
>>
>>
>

Re: [Valgrind-users] valgrind it doesn't work with Qt Creator in OS X

[<pa...@fr...>]

----- Original Message -----
> Hi Guys... I'm trying to run valgrind inside Qt Creator as I can make
> in Linux but it doesn't work. I have sent an email to the Qt Creator
> list and they sent me here to ask... my mail was this:
> 
> 
> 
> Valgrinf it doesn’t work on OS X El Capitan:
> Hi guys… I’m trying to run Valgrind inside Qt Creator in OS X El
> Capitan. I have the last Qt version and when I run the Valgrind
> (using Valgrind Memory Analizer or Valgrinf Function Profile)
> valgrind remain unfunctional and my progrmam never start…
> 
> 
> what am i suppose to do ? any idea ?? regards

Hi Freddy

Does it work outside of Qt Creator? I would recommend that you try to get it running in a console first, and then proceed to Qt Creator.


Regards
Paul

[Valgrind-users] valgrind it doesn't work with Qt Creator in OS X

[Freddy M. G. <fre...@gm...>]

Hi Guys... I'm trying to run valgrind inside Qt Creator as I can make in
Linux but it doesn't work. I have sent an email to the Qt Creator list and
they sent me here to ask... my mail was this:

Valgrinf it doesn’t work on OS X El Capitan:
Hi guys… I’m trying to run Valgrind inside Qt Creator in OS X El Capitan. I
have the last Qt version and when I run the Valgrind (using Valgrind Memory
Analizer or Valgrinf Function Profile) valgrind remain unfunctional and my
progrmam never start…

what am i suppose to do ? any idea ?? regards

regards



*============================================="El tamaño de tus logros
depende del tamaño de tus metas." *

*C++ and Qt Senior Developer*

*Lic. Computer Science*

*Buenos Aires, Argentina*

Re: [Valgrind-users] Interesting program output errors on ARM

[Henry G. <he...@ca...>]

On 11/02/16 08:58, Henry Gomersall wrote:
> What I've found is that with -O3 and -mfpu=neon flags, some values, as
> computed under Valgrind, are wrong. This is demonstrated in the minimal
> example linked to above through the printf statement.

Just to clarify, removal of either of those flags or lowering the -O
level results in a binary that works.

Henry

[Valgrind-users] Interesting program output errors on ARM

[Henry G. <he...@ca...>]

I've been working on some code targeting an ARM Cortex A9.

A minimal working example and compile/test script can be found here:
https://gist.github.com/hgomersall/22a19f245559d55f1ff6

What I've found is that with -O3 and -mfpu=neon flags, some values, as
computed under Valgrind, are wrong. This is demonstrated in the minimal
example linked to above through the printf statement.

Now I understand that Valgrind has potential problems with its own
testing on higher optimisation levels, but this is a problem with the
validity of the program itself (I am assuming the code itself remains
valid).

Clearly, if this is just a Valgrind problem I shouldn't worry too much,
but I seem to be getting various poorly defined problems (largely
erroneous results) with the higher optimisation levels and the neon
flag, even when running outside of Valgrind. It's very hard to isolate a
minimal example though.

My asm-fu is not quite at the point I can understand the program logic
from the compiler output.

I'm trying to understand whether this is a bug in my code, a compiler
bug, or a valgrind bug. Any assistance on this is much appreciated!

All the code is tested initially on x86_64, on which everything works
with no problems at all.

The problem code is with
ARM cortex A9
valgrind 3.10.1	
gcc 5.2.0
glibc 2.22
kernel 3.19.0

Many thanks,

Henry

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

[David H. <da...@da...>]

Hi Philippe,

thanks a lot for your help. I have created this ticket
https://bugs.kde.org/show_bug.cgi?id=359133 to track the issue.

I was wondering, is there some kind out of out buffering when using printf
in valgrind? I guess that could explain why I do not see the debug print?

Thanks

/David

On Fri, Feb 5, 2016 at 9:05 PM, Philippe Waroquiers <
phi...@sk...> wrote:

> On Fri, 2016-02-05 at 11:20 +0100, David Hallas wrote:
>
>
> > thanks for the reply. I tried increasing the SEGINFO_STRPOOLSIZE as
> > you requested, and for me the magic number is 268*1024 then the assert
> > goes away :) I also tried to add the print to the ML_(addStr) function
> > in storage.c but for some reason I never see the print?
> Strange. VG_(printf) prints unconditionally.
> >
> > I tried to play with objdump and nm to find some large symbols, but I
> > think I do not have enough objdump/nm skills to do that. But I also
> > tried to play with strings and I found one string (a symbol name) that
> > is 274154 bytes long (this fits perfectly with that I see the problem
> > if the SEGINFO_STRPOOLSIZE is 267*1024 but not with 268*1024). The
> > code that I am debugging is using a lot of templates, so go figure ;)
> > So I think it sounds very plausible that it is this string that is
> > causing the problem?
> A symbol name of 268 Kb is quite impressive,
> I hope you never have to print this variable in gdb :).
> >
> > Please let me know if there is any other information that you need? Or
> > if you have some other things to test.
> The information is clear, I think the problem is identified now.
> The best is to file a bug entry in bugzilla, I hope to fix
> this problem in the coming weeks or so.
>
> Thanks
>
> Philippe
>
>
>
>

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

[Philippe W. <phi...@sk...>]

On Fri, 2016-02-05 at 11:20 +0100, David Hallas wrote:


> thanks for the reply. I tried increasing the SEGINFO_STRPOOLSIZE as
> you requested, and for me the magic number is 268*1024 then the assert
> goes away :) I also tried to add the print to the ML_(addStr) function
> in storage.c but for some reason I never see the print?
Strange. VG_(printf) prints unconditionally.
> 
> I tried to play with objdump and nm to find some large symbols, but I
> think I do not have enough objdump/nm skills to do that. But I also
> tried to play with strings and I found one string (a symbol name) that
> is 274154 bytes long (this fits perfectly with that I see the problem
> if the SEGINFO_STRPOOLSIZE is 267*1024 but not with 268*1024). The
> code that I am debugging is using a lot of templates, so go figure ;)
> So I think it sounds very plausible that it is this string that is
> causing the problem?
A symbol name of 268 Kb is quite impressive,
I hope you never have to print this variable in gdb :).
> 
> Please let me know if there is any other information that you need? Or
> if you have some other things to test.
The information is clear, I think the problem is identified now.
The best is to file a bug entry in bugzilla, I hope to fix
this problem in the coming weeks or so.

Thanks

Philippe

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

[David H. <da...@da...>]

Hi Philippe,

thanks for the reply. I tried increasing the SEGINFO_STRPOOLSIZE as you
requested, and for me the magic number is 268*1024 then the assert goes
away :) I also tried to add the print to the ML_(addStr) function in
storage.c but for some reason I never see the print?

I tried to play with objdump and nm to find some large symbols, but I think
I do not have enough objdump/nm skills to do that. But I also tried to play
with strings and I found one string (a symbol name) that is 274154 bytes
long (this fits perfectly with that I see the problem if the
SEGINFO_STRPOOLSIZE is 267*1024 but not with 268*1024). The code that I am
debugging is using a lot of templates, so go figure ;) So I think it sounds
very plausible that it is this string that is causing the problem?

Please let me know if there is any other information that you need? Or if
you have some other things to test.

Thanks

/David


On Fri, Feb 5, 2016 at 12:53 AM, Philippe Waroquiers <
phi...@sk...> wrote:

> On Thu, 2016-02-04 at 08:28 +0100, David Hallas wrote:
> > Hi Philippe,
> >
> >
> > thanks a lot for the quick reply!
> >
> >
> > I have rerun the test with -v -v -v -d -d -d options and attached the
> > log. I have also tested compiling the binary with gcc-5.2.1 and there
> > I also see the problem, so it doesn't look to be compiler specific.
>
> Strange thing is that there is no host stacktrace.
> (so maybe the error is encountered before the debug info needed for
> the stack trace is loaded).
>
> From the trace, if this is a (too) big string, then that string
> is in gtest.
> Maybe you could use objdump and/or other tools (strings?)
> to find what could be this string of > 64Kb (if that is really the
> problem).
>
> >
> >
> > If you have some specific patches you want tested, I can pull the
> > valgrind sources and do a local build?
> Yes, what you could try is to increase
> #define SEGINFO_STRPOOLSIZE (64*1024)
> in coregrind/m_debuginfo/priv_storage.h
> (e.g. to (640*1024))
> and see if it works.
>
> I would be nice also to add a
>    if (len > 64 * 1024)
>      VG_(printf("huge string <%s>\n", str);
> in the ML_(addStr) function in storage.c
> to understand what is this big string.
>
> If the patch above and/or the printf do not give a clue; then
> more debugging/tracing of valgrind will be needed.
>
> Philippe
>
>
>
>
>

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

[Philippe W. <phi...@sk...>]

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

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

[Philippe W. <phi...@sk...>]

On Thu, 2016-02-04 at 08:28 +0100, David Hallas wrote:
> Hi Philippe,
> 
> 
> thanks a lot for the quick reply!
> 
> 
> I have rerun the test with -v -v -v -d -d -d options and attached the
> log. I have also tested compiling the binary with gcc-5.2.1 and there
> I also see the problem, so it doesn't look to be compiler specific.

Strange thing is that there is no host stacktrace.
(so maybe the error is encountered before the debug info needed for
the stack trace is loaded).

>From the trace, if this is a (too) big string, then that string
is in gtest.
Maybe you could use objdump and/or other tools (strings?) 
to find what could be this string of > 64Kb (if that is really the
problem).

> 
> 
> If you have some specific patches you want tested, I can pull the
> valgrind sources and do a local build?
Yes, what you could try is to increase
#define SEGINFO_STRPOOLSIZE (64*1024)
in coregrind/m_debuginfo/priv_storage.h
(e.g. to (640*1024))
and see if it works.

I would be nice also to add a
   if (len > 64 * 1024)
     VG_(printf("huge string <%s>\n", str);
in the ML_(addStr) function in storage.c
to understand what is this big string.

If the patch above and/or the printf do not give a clue; then
more debugging/tracing of valgrind will be needed.

Philippe

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

[David C. <dcc...@ac...>]

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 
> <http://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 
> <http://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 
> <http://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 
> <http://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)
> ==4880==    by 0x41F827: ??? (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==
> ==4880== 1,288 bytes in 4 blocks are definitely lost in loss record 
> 522 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)
> ==4880==    by 0x41F827: ??? (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==
> ==4880== 2,200 (800 direct, 1,400 indirect) bytes in 1 blocks are 
> definitely lost in loss record 528 of 548
> ==4880==    at 0x4A0610C: malloc (vg_replace_malloc.c:195)
> ==4880==    by 0x439361: ??? (in /bin/tcsh)
> ==4880==    by 0x415338: ??? (in /bin/tcsh)
> ==4880==    by 0x415E6D: ??? (in /bin/tcsh)
> ==4880==    by 0x4133F1: ??? (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 
> <http://libc-2.5.so>)
> ==4880==
> ==4880== 8,148 (1,040 direct, 7,108 indirect) bytes in 1 blocks are 
> definitely lost in loss record 542 of 548
> ==4880==    at 0x4A0610C: malloc (vg_replace_malloc.c:195)
> ==4880==    by 0x439361: ??? (in /bin/tcsh)
> ==4880==    by 0x43FF0A: ??? (in /bin/tcsh)
> ==4880==    by 0x411C0F: ??? (in /bin/tcsh)
> ==4880==    by 0x412020: ??? (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==
> ==4880== LEAK SUMMARY:
> ==4880==    definitely lost: 4,220 bytes in 30 blocks
> ==4880==    indirectly lost: 8,508 bytes in 143 blocks
> ==4880==      possibly lost: 0 bytes in 0 blocks
> ==4880==    still reachable: 161,827 bytes in 1,957 blocks
> ==4880==         suppressed: 0 bytes in 0 blocks
> ==4880== Reachable blocks (those to which a pointer was found) are not 
> shown.
> ==4880== To see them, rerun with: --leak-check=full --show-reachable=yes
> ==4880==
> ==4880== For counts of detected and suppressed errors, rerun with: -v
> ==4880== ERROR SUMMARY: 11 errors from 11 contexts (suppressed: 4 from 4)
>
>
> Any idea of what I am doing wrong??
>
> Thanks in advance for any clarification.
>
>
> -- 
> Kevin Le Morzadec - Ph.D. candidate
>                                Dept of Physics and Physical Oceanography,
>                                Memorial University of Newfoundland, Canada
>                                Tel 709-864-8654
>
>
> ------------------------------------------------------------------------------
> 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&iu=/4140
>
>
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users


-- 
     David Chapman      dcc...@ac...
     Chapman Consulting -- San Jose, CA
     Software Development Done Right.
     www.chapman-consulting-sj.com

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

[John R. <jr...@bi...>]

> 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

Re: [Valgrind-users] Bypass procedure size checking in Valgrind

[Florian K. <fl...@ei...>]

On 04.02.2016 17:02, Wojciech Franczyk wrote:
> Hi all,
> 
> As you may know, Valgrind checks if there are no procedures bigger than
> 5bln bytes in debugged/profiled binary. It uses assert placed in
> *coregrind/m_debuginfo/storage.c:723* line (at least in version 3.11.0).

No. It used to be an assert. But as you're not the first to run into
this limitation, the assert has been downgraded to a warning. In 3.11.0
(and later) the code reads like this:

   if (len >= 5000000)
      VG_(message)(Vg_DebugMsg,
                   "warning: DiCfSI %#lx .. %#lx is huge;...........

Perhaps you're using a differnet valgrind version?

   Florian

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

[kevin.lemorzadec <kev...@mu...>]

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)
==4880==    by 0x41F827: ??? (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==
==4880== 1,288 bytes in 4 blocks are definitely lost in loss record 522 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)
==4880==    by 0x41F827: ??? (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==
==4880== 2,200 (800 direct, 1,400 indirect) bytes in 1 blocks are
definitely lost in loss record 528 of 548
==4880==    at 0x4A0610C: malloc (vg_replace_malloc.c:195)
==4880==    by 0x439361: ??? (in /bin/tcsh)
==4880==    by 0x415338: ??? (in /bin/tcsh)
==4880==    by 0x415E6D: ??? (in /bin/tcsh)
==4880==    by 0x4133F1: ??? (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== 8,148 (1,040 direct, 7,108 indirect) bytes in 1 blocks are
definitely lost in loss record 542 of 548
==4880==    at 0x4A0610C: malloc (vg_replace_malloc.c:195)
==4880==    by 0x439361: ??? (in /bin/tcsh)
==4880==    by 0x43FF0A: ??? (in /bin/tcsh)
==4880==    by 0x411C0F: ??? (in /bin/tcsh)
==4880==    by 0x412020: ??? (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==
==4880== LEAK SUMMARY:
==4880==    definitely lost: 4,220 bytes in 30 blocks
==4880==    indirectly lost: 8,508 bytes in 143 blocks
==4880==      possibly lost: 0 bytes in 0 blocks
==4880==    still reachable: 161,827 bytes in 1,957 blocks
==4880==         suppressed: 0 bytes in 0 blocks
==4880== Reachable blocks (those to which a pointer was found) are not
shown.
==4880== To see them, rerun with: --leak-check=full --show-reachable=yes
==4880==
==4880== For counts of detected and suppressed errors, rerun with: -v
==4880== ERROR SUMMARY: 11 errors from 11 contexts (suppressed: 4 from 4)


Any idea of what I am doing wrong??

Thanks in advance for any clarification.


-- 
Kevin Le Morzadec - Ph.D. candidate
                               Dept of Physics and Physical Oceanography,
                               Memorial University of Newfoundland, Canada
                               Tel 709-864-8654

[Valgrind-users] Bypass procedure size checking in Valgrind

[Wojciech F. <fra...@gm...>]

Hi all,

As you may know, Valgrind checks if there are no procedures bigger than
5bln bytes in debugged/profiled binary. It uses assert placed in
*coregrind/m_debuginfo/storage.c:723* line (at least in version 3.11.0).
That big procedures are unexpected and should not appear. Well... I have a
piece of code where it occur (5004720 bytes procedure) :)

I have commented out this line and recompiled Valgrind. It works fine now,
but
does anyone know if it's possible to prevent Valgrind asserting this by - I
don't know - maybe a command line flag/option? To bypass that
comment-recompile step.

Thanks,
Wojtek

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

[Florian K. <fl...@ei...>]

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.

  Florian

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

[David H. <da...@da...>]

Hi Philippe,

thanks a lot for the quick reply!

I have rerun the test with -v -v -v -d -d -d options and attached the log.
I have also tested compiling the binary with gcc-5.2.1 and there I also see
the problem, so it doesn't look to be compiler specific.

If you have some specific patches you want tested, I can pull the valgrind
sources and do a local build?

Thanks for your help

/David

On Wed, Feb 3, 2016 at 9:50 PM, Philippe Waroquiers <
phi...@sk...> wrote:

> On Wed, 2016-02-03 at 21:33 +0100, Philippe Waroquiers wrote:
> > On Wed, 2016-02-03 at 20:45 +0100, David Hallas wrote:
> >
> > > valgrind: m_deduppoolalloc.c:258 (vgPlain_allocEltDedupPA): Assertion
> > > 'eltSzB <= ddpa->poolSzB' failed.
> > > I am running on a 64bit Linux system, and the binary is compiled using
> > > clang-3.7.
> > > Can anyone give some pointers as to what might be wrong?
> > This assert probably indicates there is a bug in valgrind triggered
> > by unexpected (or incorrect?) data in the executable (e.g. debug info).
> >
> > Normally, for such asserts, a guest and host stack traces are produced.
> > Without these stacktraces, not much chance to guess what is wrong.
> >
> > Assuming this is caused by debuginfo, you could try to run
> > with more tracing, e.g.
> >    -v -v -v -d -d -d
> > and one or more of
> >
> >     --trace-symtab=no|yes     show symbol table details? [no]
> >     --trace-symtab-patt=<patt> limit debuginfo tracing to obj name <patt>
> >     --trace-cfi=no|yes        show call-frame-info details? [no]
> >     --debug-dump=syms         mimic /usr/bin/readelf --syms
> >     --debug-dump=line         mimic /usr/bin/readelf --debug-dump=line
> >     --debug-dump=frames       mimic /usr/bin/readelf --debug-dump=frames
>
> The assert might be caused by the debuginfo containing a string bigger
> than SEGINFO_STRPOOLSIZE (64Kb).
> If that is the case, we could make the allocEltDedupPA function allow
> for bigger strings, but would be nice to first verify this is
> effectively a big string, and also then understand why clang
> generates strings > 64Kb.
>
> So, more info is needed to confirm what is the problem
> (i.e. either tracing and/or the crash stack traces)
>
> Philippe
>
>
>

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

[Philippe W. <phi...@sk...>]

On Wed, 2016-02-03 at 21:33 +0100, Philippe Waroquiers wrote:
> On Wed, 2016-02-03 at 20:45 +0100, David Hallas wrote:
> 
> > valgrind: m_deduppoolalloc.c:258 (vgPlain_allocEltDedupPA): Assertion
> > 'eltSzB <= ddpa->poolSzB' failed.
> > I am running on a 64bit Linux system, and the binary is compiled using
> > clang-3.7.
> > Can anyone give some pointers as to what might be wrong?
> This assert probably indicates there is a bug in valgrind triggered
> by unexpected (or incorrect?) data in the executable (e.g. debug info).
> 
> Normally, for such asserts, a guest and host stack traces are produced.
> Without these stacktraces, not much chance to guess what is wrong.
> 
> Assuming this is caused by debuginfo, you could try to run
> with more tracing, e.g.
>    -v -v -v -d -d -d 
> and one or more of
> 
>     --trace-symtab=no|yes     show symbol table details? [no]
>     --trace-symtab-patt=<patt> limit debuginfo tracing to obj name <patt>
>     --trace-cfi=no|yes        show call-frame-info details? [no]
>     --debug-dump=syms         mimic /usr/bin/readelf --syms
>     --debug-dump=line         mimic /usr/bin/readelf --debug-dump=line
>     --debug-dump=frames       mimic /usr/bin/readelf --debug-dump=frames

The assert might be caused by the debuginfo containing a string bigger
than SEGINFO_STRPOOLSIZE (64Kb).
If that is the case, we could make the allocEltDedupPA function allow
for bigger strings, but would be nice to first verify this is
effectively a big string, and also then understand why clang
generates strings > 64Kb.

So, more info is needed to confirm what is the problem
(i.e. either tracing and/or the crash stack traces)

Philippe

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

[Philippe W. <phi...@sk...>]

On Wed, 2016-02-03 at 20:45 +0100, David Hallas wrote:

> valgrind: m_deduppoolalloc.c:258 (vgPlain_allocEltDedupPA): Assertion
> 'eltSzB <= ddpa->poolSzB' failed.
> I am running on a 64bit Linux system, and the binary is compiled using
> clang-3.7.
> Can anyone give some pointers as to what might be wrong?
This assert probably indicates there is a bug in valgrind triggered
by unexpected (or incorrect?) data in the executable (e.g. debug info).

Normally, for such asserts, a guest and host stack traces are produced.
Without these stacktraces, not much chance to guess what is wrong.

Assuming this is caused by debuginfo, you could try to run
with more tracing, e.g.
   -v -v -v -d -d -d 
and one or more of

    --trace-symtab=no|yes     show symbol table details? [no]
    --trace-symtab-patt=<patt> limit debuginfo tracing to obj name <patt>
    --trace-cfi=no|yes        show call-frame-info details? [no]
    --debug-dump=syms         mimic /usr/bin/readelf --syms
    --debug-dump=line         mimic /usr/bin/readelf --debug-dump=line
    --debug-dump=frames       mimic /usr/bin/readelf --debug-dump=frames

Philippe

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

[David H. <da...@da...>]

Hi All,

I have run into a problem with valgrind when analyzing a binary, I receive
the following error:

==19823== Memcheck, a memory error detector
==19823== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==19823== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==19823== Command: ./gtest
==19823==

valgrind: m_deduppoolalloc.c:258 (vgPlain_allocEltDedupPA): Assertion
'eltSzB <= ddpa->poolSzB' failed.

I am running on a 64bit Linux system, and the binary is compiled using
clang-3.7.

Can anyone give some pointers as to what might be wrong?

Thanks!

/David

[Valgrind-users] debugging GSequencer

[Joël K. <jkr...@gm...>]

Hi

I'm very happy about being able to debug gsequencer with valgrind :)

It is a very useful error detector. But I experience for now a deadlock.

http://gsequencer.org/download.html

And sometimes I'm asking me where is the data-race detected by helgrind:

==12967== ---Thread-Announcement------------------------------------------
==12967==
==12967== Thread #4 was created
==12967==    at 0x942593E: clone (in /lib/x86_64-linux-gnu/libc-2.21.so)
==12967==    by 0x91260F9: create_thread (createthread.c:102)
==12967==    by 0x9127A07: pthread_create@@GLIBC_2.2.5 (pthread_create.c:677)
==12967==    by 0x4C30C77: pthread_create_WRK (hg_intercepts.c:427)
==12967==    by 0x6043173: _g_closure_invoke_va (in
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.2)
==12967==    by 0x605D975: g_signal_emit_valist (in
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.2)
==12967==    by 0x605E05E: g_signal_emit (in
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.2)
==12967==    by 0x4C6575: ags_thread_start (ags_thread-posix.c:2307)
==12967==    by 0x4525BF: main (main.c:867)
==12967==
==12967== ----------------------------------------------------------------
==12967==
==12967== Possible data race during read of size 8 at 0x6285618 by thread #1
==12967== Locks held: none
==12967==    at 0x605D4C5: g_signal_emit_valist (in
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.2)
==12967==    by 0x605E05E: g_signal_emit (in
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.2)
==12967==    by 0x4C6575: ags_thread_start (ags_thread-posix.c:2307)
==12967==    by 0x4525BF: main (main.c:867)
==12967==
==12967== This conflicts with a previous write of size 8 by thread #4
==12967== Locks held: none
==12967==    at 0x605DA43: g_signal_emit_valist (in
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.2)
==12967==    by 0x605E05E: g_signal_emit (in
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.2)
==12967==    by 0x4C6575: ags_thread_start (ags_thread-posix.c:2307)
==12967==    by 0x4BE622: ags_audio_loop_run (ags_audio_loop.c:545)
==12967==    by 0x6043173: _g_closure_invoke_va (in
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.2)
==12967==    by 0x605D975: g_signal_emit_valist (in
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.2)
==12967==    by 0x605E05E: g_signal_emit (in
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.2)
==12967==    by 0x4C6865: ags_thread_run (ags_thread-posix.c:2639)
==12967==  Address 0x6285618 is 0 bytes inside data symbol "g_emissions"
==12967==
==12967== (action on error) vgdb me ...
==12967== Continuing ...
--12967-- warning: evaluate_Dwarf3_Expr: unhandled DW_OP_ 0xf2
--12967-- warning: evaluate_Dwarf3_Expr: unhandled DW_OP_ 0xf2
--12967-- warning: evaluate_Dwarf3_Expr: unhandled DW_OP_ 0xf2
--12967-- warning: evaluate_Dwarf3_Expr: unhandled DW_OP_ 0xf2
--12967-- warning: evaluate_Dwarf3_Expr: unhandled DW_OP_ 0xf2
--12967-- warning: evaluate_Dwarf3_Expr: unhandled DW_OP_ 0xf2
--12967-- warning: evaluate_Dwarf3_Expr: unhandled DW_OP_ 0xf2
--12967-- warning: evaluate_Dwarf3_Expr: unhandled DW_OP_ 0xf2
--12967-- warning: evaluate_Dwarf3_Expr: unhandled DW_OP_ 0xf2
--12967-- warning: evaluate_Dwarf3_Expr: unhandled DW_OP_ 0xf2
--12967-- warning: evaluate_Dwarf3_Expr: unhandled DW_OP_ 0xf2
--12967-- warning: evaluate_Dwarf3_Expr: unhandled DW_OP_ 0xf2
--12967-- warning: evaluate_Dwarf3_Expr: unhandled DW_OP_ 0xf2
==12967== ----------------------------------------------------------------
==12967==
==12967== Possible data race during read of size 4 at 0x1820F290 by thread #1
==12967== Locks held: none
==12967==    at 0x605D503: g_signal_emit_valist (in
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.2)
==12967==    by 0x605E05E: g_signal_emit (in
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.2)
==12967==    by 0x4C6575: ags_thread_start (ags_thread-posix.c:2307)
==12967==    by 0x4525BF: main (main.c:867)
==12967==  Address 0x1820f290 is on thread #4's stack
==12967==
==12967== (action on error) vgdb me ...
==12967== Continuing ...
--12967-- warning: evaluate_Dwarf3_Expr: unhandled DW_OP_ 0xf2
--12967-- warning: evaluate_Dwarf3_Expr: unhandled DW_OP_ 0xf2
--12967-- warning: evaluate_Dwarf3_Expr: unhandled DW_OP_ 0xf2
--12967-- warning: evaluate_Dwarf3_Expr: unhandled DW_OP_ 0xf2
--12967-- warning: evaluate_Dwarf3_Expr: unhandled DW_OP_ 0xf2
--12967-- warning: evaluate_Dwarf3_Expr: unhandled DW_OP_ 0xf2
--12967-- warning: evaluate_Dwarf3_Expr: unhandled DW_OP_ 0xf2
--12967-- warning: evaluate_Dwarf3_Expr: unhandled DW_OP_ 0xf2
--12967-- warning: evaluate_Dwarf3_Expr: unhandled DW_OP_ 0xf2
--12967-- warning: evaluate_Dwarf3_Expr: unhandled DW_OP_ 0xf2
--12967-- warning: evaluate_Dwarf3_Expr: unhandled DW_OP_ 0xf2
--12967-- warning: evaluate_Dwarf3_Expr: unhandled DW_OP_ 0xf2
--12967-- warning: evaluate_Dwarf3_Expr: unhandled DW_OP_ 0xf2
==12967== ----------------------------------------------------------------
==12967==
==12967== Possible data race during write of size 4 at 0x1820F930 by thread #1
==12967== Locks held: none
==12967==    at 0x605D51B: g_signal_emit_valist (in
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.2)
==12967==    by 0x605E05E: g_signal_emit (in
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4600.2)
==12967==    by 0x4C6575: ags_thread_start (ags_thread-posix.c:2307)
==12967==    by 0x4525BF: main (main.c:867)
==12967==  Address 0x1820f930 is on thread #4's stack
==12967==
==12967== (action on error) vgdb me ...


For readability I don't entire gdb and helgrind command history.


Program received signal SIGTRAP, Trace/breakpoint trap.
Python Exception <class 'TypeError'> iter() returned non-iterator of
type '_iterator':
g_hash_table_resize (hash_table=hash_table@entry=0x101c7b00) at
/build/glib2.0-2.46.2/./glib/ghash.c:622
622    in /build/glib2.0-2.46.2/./glib/ghash.c
(gdb)
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
Python Exception <class 'TypeError'> iter() returned non-iterator of
type '_iterator':
g_hash_table_resize (hash_table=hash_table@entry=0x101c7b00) at
/build/glib2.0-2.46.2/./glib/ghash.c:623
623    in /build/glib2.0-2.46.2/./glib/ghash.c
(gdb)
Continuing.


[New Thread 12990]
[New Thread 12991]

Program received signal SIGTRAP, Trace/breakpoint trap.
g_signal_emit_valist (instance=0x173f2390, signal_id=<optimized out>,
detail=0, var_args=var_args@entry=0xffefffe80) at
/build/glib2.0-2.46.2/./gobject/gsignal.c:3304
3304    /build/glib2.0-2.46.2/./gobject/gsignal.c: Datei oder
Verzeichnis nicht gefunden.
(gdb)
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
emission_pop (emission=0x0) at /build/glib2.0-2.46.2/./gobject/gsignal.c:804
804    in /build/glib2.0-2.46.2/./gobject/gsignal.c
(gdb)
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
0x000000000605d51b in emission_pop (emission=0x0) at
/build/glib2.0-2.46.2/./gobject/gsignal.c:808
808    in /build/glib2.0-2.46.2/./gobject/gsignal.c

bests,
Joël

Re: [Valgrind-users] Strange warning: Ignoring non-Dwarf2/3/4 block in .debug_info

[ISHIKAWA,chiaki <ish...@yk...>]

On 2016/01/28 7:06, Philippe Waroquiers wrote:
> On Thu, 2016-01-28 at 02:19 +0900, ISHIKAWA,chiaki wrote:
>> c++11 runtime seems to use |new| operation to create some data in a very
>> primitive internal string handling function, and these string data are
>> "free"ed by many other functions that my application (mozilla
>> thunderbird) use. So delete vs free issues are reported. I suspect c++11
>> ought to use "malloc()" for the internal string operation, but then
>> maybe other parts of c++11 library may complain about malloc vs delete
>> mismatch then :-(
> Some such false positive of 'mismatched malloc/free/new/delete'
> were found in the past due to one operation being inlined
> (e.g. the new) but the delete not being inlined.
> The matching code does not understand inlining, and so the false
> positive.
>
> Maybe that is your case ?
> (you might check this by showing the stacktrace for the allocation
> and deallocation using e.g. gdb+vgdb, and see if inlining enters in
> the game).
>
> Philippe

Thank you for the tips.

I will investigate this issue further along your suggestions.
I can whitelist typical noises by using suppression file, but
to think the valgrind/memcheck needs to check this and notice the 
anomaly, check the
backtrace of calls to malloc/new to report it and only then learns it is 
whitelisted, and moves on to the original execution: such a waste of 
runtime CPU (!).
Actually, I think I already notice a significant slowdown due to this 
added mismatches.
Or maybe I am hallucinating and in need of a faster CPU :-)

But if the issue is the unbalanced inlining, there is a hope that I can 
either fix the
local build environment to inline both new/delete, etc., or try 
contacting the library builders to fix their
toolchain setup.

CI

Re: [Valgrind-users] Strange warning: Ignoring non-Dwarf2/3/4 block in .debug_info

[Philippe W. <phi...@sk...>]

On Thu, 2016-01-28 at 02:19 +0900, ISHIKAWA,chiaki wrote:
> c++11 runtime seems to use |new| operation to create some data in a very 
> primitive internal string handling function, and these string data are 
> "free"ed by many other functions that my application (mozilla 
> thunderbird) use. So delete vs free issues are reported. I suspect c++11 
> ought to use "malloc()" for the internal string operation, but then 
> maybe other parts of c++11 library may complain about malloc vs delete 
> mismatch then :-(
Some such false positive of 'mismatched malloc/free/new/delete'
were found in the past due to one operation being inlined
(e.g. the new) but the delete not being inlined.
The matching code does not understand inlining, and so the false
positive.

Maybe that is your case ?
(you might check this by showing the stacktrace for the allocation
and deallocation using e.g. gdb+vgdb, and see if inlining enters in
the game).

Philippe

Re: [Valgrind-users] Strange warning: Ignoring non-Dwarf2/3/4 block in .debug_info

[ISHIKAWA,chiaki <ish...@yk...>]

This is an observation from a Debian user.

I use Debian 64bit on my home PC.

Between the end of December/beginning of January and now, something
in the Debian repository which I fetched, probably during the update
to gcc 5.3 branch, caused a significant change from the viewpoint of 
valgrind/memcheck.
Most notably c11++ runtime (or is it spelled c++11 ?) seems to have been 
introduced and
this caused massive reports of mismatched new vs free from 
valgrind/memcheck.
c++11 runtime seems to use |new| operation to create some data in a very 
primitive internal string handling function, and these string data are 
"free"ed by many other functions that my application (mozilla 
thunderbird) use. So delete vs free issues are reported. I suspect c++11 
ought to use "malloc()" for the internal string operation, but then 
maybe other parts of c++11 library may complain about malloc vs delete 
mismatch then :-(

I think those who want to move on to newer GCC (g++) and its runtime may 
want to get prepared for a surprise. I wish the developers of c++11 
runtime use valgrind/memcheck during their development cycle. Maybe they 
use addresssanitizer and don't pay attention to the free vs delete issue 
much.

Just my two cents worth.

CI



On 2016/01/19 7:13, ISHIKAWA,chiaki wrote:
> On 2016/01/18 23:32, Julian Seward wrote:
>> Chiaki,
>>
>>> First of all, thank you for sharing this great package.
>> First of all, thank you for supporting Thunderbird.  I use it all the time.
>>
>>> --11405-- WARNING: Serious error when reading debug info
>>> --11405-- When reading debug info from
>>> /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0.3200.3:
>>> --11405-- Ignoring non-Dwarf2/3/4 block in .debug_info
>> Hmm.  That is pretty strange.  Can you send by email (not to the
>> list) a copy of this libgdk_pixbuf-2.0.so.0.3200.3, for investigation?
>>
>> J
> Yes, I will.
>
> Chiaki
>
>
>
> ------------------------------------------------------------------------------
> 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=267308311&iu=/4140
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
>