valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] Not able to get the Leak summery details in ARM architecture

[venkat k. <ven...@gm...>]

>
> I have compiled the above program using below commands
>
> arm-linux-gnueabi-gcc -o test-arm -g test.c
> arm-linux-gnueabi-gcc -o test-arm-static -g test.c
>
> when i am running in my ARM architecture with valgrind
>

So that looks like you are cross compiling? But you are actually running
valgrind on the target machine, not on the host where you do the compil?

    -----> Yes i cross compiled both test app and valgrind, then i copied
to target machine.
 I cross compiled valgrind like this ./configure --host=arm-linux-gnueabi
--target=arm-linux-gnueabi

1) valgrind --tool=memcheck --leak-check=yes --show-reachable=yes ./test-arm
>
> valgrind: m_ume.c: can't open interpreter
>

Well that means whatever ELF interpreter your program is declaring can't be
opened by valgrind. Run "file ./test-arm" and see what interpreter it says
it is using.

2) /writable/valgrind/bin/valgrind --tool=memcheck --leak-check=yes
> --show-reachable=yes ./test-arm-static
>
> ==8118== Memcheck, a memory error detector ==8118== Copyright (C)
> 2002-2013, and GNU GPL'd, by Julian Seward et al. ==8118== Using
> Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info ==8118==
> Command: ./test-arm-static ==8118== Enter number of elements: 1 Enter
> elements of array: 1 Sum=1==8118== ==8118== HEAP SUMMARY: ==8118== in
> use at exit: 0 bytes in 0 blocks ==8118== total heap usage: 0 allocs, 0
> frees, 0 bytes allocated ==8118== ==8118== All heap blocks were freed --
> no leaks are possible ==8118== ==8118== For counts of detected and
> suppressed errors, rerun with: -v ==8118== ERROR SUMMARY: 0 errors from
> 0 contexts (suppressed: 0 from 0)
>
> In both the cases i didn't get LEAK SUMMERY , but in my linux machine i
> am able to get the valgrind report. can you suggest me the how to
> resolve this on ?
>

You won't be able to get a leak report for a statically linked program
because valgrind won't be able to intercept calls to malloc and free.

Thanks,

Venkateswarlu.K

On Tue, Apr 12, 2016 at 4:46 PM, Tom Hughes <to...@co...> wrote:

> On 12/04/16 11:52, venkat konamki wrote:
>
> I have compiled the above program using below commands
>>
>> arm-linux-gnueabi-gcc -o test-arm -g test.c
>> arm-linux-gnueabi-gcc -o test-arm-static -g test.c
>>
>> when i am running in my ARM architecture with valgrind
>>
>
> So that looks like you are cross compiling? But you are actually running
> valgrind on the target machine, not on the host where you do the compil?
>
> 1) valgrind --tool=memcheck --leak-check=yes --show-reachable=yes
>> ./test-arm
>>
>> valgrind: m_ume.c: can't open interpreter
>>
>
> Well that means whatever ELF interpreter your program is declaring can't
> be opened by valgrind. Run "file ./test-arm" and see what interpreter it
> says it is using.
>
> 2) /writable/valgrind/bin/valgrind --tool=memcheck --leak-check=yes
>> --show-reachable=yes ./test-arm-static
>>
>> ==8118== Memcheck, a memory error detector ==8118== Copyright (C)
>> 2002-2013, and GNU GPL'd, by Julian Seward et al. ==8118== Using
>> Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info ==8118==
>> Command: ./test-arm-static ==8118== Enter number of elements: 1 Enter
>> elements of array: 1 Sum=1==8118== ==8118== HEAP SUMMARY: ==8118== in
>> use at exit: 0 bytes in 0 blocks ==8118== total heap usage: 0 allocs, 0
>> frees, 0 bytes allocated ==8118== ==8118== All heap blocks were freed --
>> no leaks are possible ==8118== ==8118== For counts of detected and
>> suppressed errors, rerun with: -v ==8118== ERROR SUMMARY: 0 errors from
>> 0 contexts (suppressed: 0 from 0)
>>
>> In both the cases i didn't get LEAK SUMMERY , but in my linux machine i
>> am able to get the valgrind report. can you suggest me the how to
>> resolve this on ?
>>
>
> You won't be able to get a leak report for a statically linked program
> because valgrind won't be able to intercept calls to malloc and free.
>
> Tom
>
> --
> Tom Hughes (to...@co...)
> http://compton.nu/
>

Re: [Valgrind-users] Not able to get the Leak summery details in ARM architecture

[Tom H. <to...@co...>]

On 12/04/16 11:52, venkat konamki wrote:

> I have compiled the above program using below commands
>
> arm-linux-gnueabi-gcc -o test-arm -g test.c
> arm-linux-gnueabi-gcc -o test-arm-static -g test.c
>
> when i am running in my ARM architecture with valgrind

So that looks like you are cross compiling? But you are actually running 
valgrind on the target machine, not on the host where you do the compil?

> 1) valgrind --tool=memcheck --leak-check=yes --show-reachable=yes ./test-arm
>
> valgrind: m_ume.c: can't open interpreter

Well that means whatever ELF interpreter your program is declaring can't 
be opened by valgrind. Run "file ./test-arm" and see what interpreter it 
says it is using.

> 2) /writable/valgrind/bin/valgrind --tool=memcheck --leak-check=yes
> --show-reachable=yes ./test-arm-static
>
> ==8118== Memcheck, a memory error detector ==8118== Copyright (C)
> 2002-2013, and GNU GPL'd, by Julian Seward et al. ==8118== Using
> Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info ==8118==
> Command: ./test-arm-static ==8118== Enter number of elements: 1 Enter
> elements of array: 1 Sum=1==8118== ==8118== HEAP SUMMARY: ==8118== in
> use at exit: 0 bytes in 0 blocks ==8118== total heap usage: 0 allocs, 0
> frees, 0 bytes allocated ==8118== ==8118== All heap blocks were freed --
> no leaks are possible ==8118== ==8118== For counts of detected and
> suppressed errors, rerun with: -v ==8118== ERROR SUMMARY: 0 errors from
> 0 contexts (suppressed: 0 from 0)
>
> In both the cases i didn't get LEAK SUMMERY , but in my linux machine i
> am able to get the valgrind report. can you suggest me the how to
> resolve this on ?

You won't be able to get a leak report for a statically linked program 
because valgrind won't be able to intercept calls to malloc and free.

Tom

-- 
Tom Hughes (to...@co...)
http://compton.nu/

[Valgrind-users] Not able to get the Leak summery details in ARM architecture

[venkat k. <ven...@gm...>]

Hi,

#include <stdio.h>
#include <stdlib.h>
int main(){
    int n,i,*ptr,sum=0;
    printf("Enter number of elements: ");
    scanf("%d",&n);
    ptr=(int*)malloc(n*sizeof(int));  //memory allocated using malloc
    if(ptr==NULL)
    {
        printf("Error! memory not allocated.");
        exit(0);
    }
    printf("Enter elements of array: ");
    for(i=0;i<n;++i)
    {
        scanf("%d",ptr+i);
        sum+=*(ptr+i);
    }
    printf("Sum=%d",sum);
   // free(ptr);
    return 0;
}

I have compiled the above program using below commands

arm-linux-gnueabi-gcc -o test-arm -g test.c
arm-linux-gnueabi-gcc -o test-arm-static -g test.c

when i am running in my ARM architecture with valgrind

1) valgrind --tool=memcheck --leak-check=yes --show-reachable=yes ./test-arm

valgrind: m_ume.c: can't open interpreter

2) /writable/valgrind/bin/valgrind --tool=memcheck --leak-check=yes
--show-reachable=yes  ./test-arm-static

==8118== Memcheck, a memory error detector ==8118== Copyright (C)
2002-2013, and GNU GPL'd, by Julian Seward et al. ==8118== Using
Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info ==8118==
Command: ./test-arm-static ==8118== Enter number of elements: 1 Enter
elements of array: 1 Sum=1==8118== ==8118== HEAP SUMMARY: ==8118== in use
at exit: 0 bytes in 0 blocks ==8118== total heap usage: 0 allocs, 0 frees,
0 bytes allocated ==8118== ==8118== All heap blocks were freed -- no leaks
are possible ==8118== ==8118== For counts of detected and suppressed
errors, rerun with: -v ==8118== ERROR SUMMARY: 0 errors from 0 contexts
(suppressed: 0 from 0)

In both the cases i didn't get LEAK SUMMERY , but in my linux machine
i am able to get the valgrind report. can you suggest me the how to
resolve this on ?


Thanks,

Venkateswarlu.K

Re: [Valgrind-users] Is is possible to use "valgrind --tool=callgrind" command in "excelp" call

[PRASHANT P. <PRA...@ad...>]

Thanks Tom... Your suggestion helped me :)

Thanks,
Prashant

-----Original Message-----
From: Tom Hughes [mailto:to...@co...] 
Sent: 06 April 2016 18:00
To: PRASHANT PATEL; val...@li...
Subject: Re: Is is possible to use "valgrind --tool=callgrind" command in "excelp" call

On 06/04/16 13:09, PRASHANT PATEL wrote:

>                   I would like to use "valgrind -tool=callgrind 
> <executive name>" in "execlp()" system call as below. Is it possible ?
>
> For me, valgrind is not invoking up.
>
> execlp("/usr/local/pmas/bin/pma", "valgrind --tool=callgrind pma", 
> "-n", option_pma_name, NULL);
>
> Is it any other way to do it  ?

Well that's completely wrong is why... You are trying to exec the wrong executable and have merged several arguments into one. You want:

execlp("/path/to/valgrind", "valgrind", "--tool=callgrind", "/usr/local/pmas/bin/pma", "-n", option_pma_name, NULL);

So you are running valgrind, and providing the arguments that valgrind needs including the path to the program it needs to start.

Tom

--
Tom Hughes (to...@co...)
http://compton.nu/

Re: [Valgrind-users] Is is possible to use "valgrind --tool=callgrind" command in "excelp" call

[Tom H. <to...@co...>]

On 06/04/16 13:09, PRASHANT PATEL wrote:

>                   I would like to use “valgrind –tool=callgrind
> <executive name>” in “execlp()” system call as below. Is it possible ?
>
> For me, valgrind is not invoking up.
>
> execlp("/usr/local/pmas/bin/pma", "valgrind --tool=callgrind pma", "-n",
> option_pma_name, NULL);
>
> Is it any other way to do it  ?

Well that's completely wrong is why... You are trying to exec the wrong 
executable and have merged several arguments into one. You want:

execlp("/path/to/valgrind", "valgrind", "--tool=callgrind", 
"/usr/local/pmas/bin/pma", "-n", option_pma_name, NULL);

So you are running valgrind, and providing the arguments that valgrind 
needs including the path to the program it needs to start.

Tom

-- 
Tom Hughes (to...@co...)
http://compton.nu/

[Valgrind-users] Is is possible to use "valgrind --tool=callgrind" command in "excelp" call

[PRASHANT P. <PRA...@ad...>]

Hello All,
                 I would like to use "valgrind -tool=callgrind <executive name>" in "execlp()" system call as below. Is it possible ?
For me, valgrind is not invoking up.

execlp("/usr/local/pmas/bin/pma", "valgrind --tool=callgrind pma", "-n", option_pma_name, NULL);

Is it any other way to do it  ?

Thanks,
Prashant

Re: [Valgrind-users] helgrind: false race positive with static variable in function

[David F. <fa...@kd...>]

On Wednesday 30 March 2016 11:28:27 Ivo Raisr wrote:
> 2016-03-30 10:59 GMT+02:00 David Faure <fa...@kd...>:
> 
> > This simple testcase :
> >
> > int foo() {
> >     struct Foo {
> >         int *i;
> >         Foo() {  i = new int(42); }
> >     };
> >     static Foo f;
> >     return *(f.i);
> > }
> >
> > called from two threads (
> > http://www.davidfaure.fr/2016/testcase_ogoffart.cpp)
> > leads to this race warning in helgrind :
> >
> 
> I've done some googling for you:
> http://stackoverflow.com/questions/8393777/current-state-of-drd-and-helgrind-support-for-stdthread
> https://gcc.gnu.org/onlinedocs/libstdc++/manual/debug.html (search for
> "Data Race Hunting")

The #defines in these pages don't help, helgrind shows the same race.
They seem to be about atomic usage in templates defined by libstdc++ (which
doesn't seem to be the case for __cxa_guard_acquire).

> http://stackoverflow.com/questions/19128549/force-use-of-locks-inside-stdatomic-during-debugging-with-libstdc

Basically says there is no solution.

> There could be other articles, for sure.
> If you find Valgrind documentation [1] not sufficient, please file bugs [2]
> and suggest solutions. Patches are welcome!
> [1] http://valgrind.org/docs/manual/manual.html

Hmm I see nothing in there about static variables indeed.
(Qt5 is missing too).

Thanks.

-- 
David Faure, fa...@kd..., http://www.davidfaure.fr
Working on KDE Frameworks 5

Re: [Valgrind-users] Help running valgrind

[Tom H. <to...@co...>]

On 31/03/16 09:38, Harish Babu wrote:

>    I'm having trouble getting valgrind working with one of the software
> that I'm working on. I worked around couple of initial issues and got it
> to start. But then I running into other next issues, so I have following
> questions:
>
> 1) Does valgrind work well with mapped file segments. We use these
> segments for execution too! And I run into crashes when trying to
> execute code on these pages.
>
> 2) Is it possible to tell valgrind not to track certain virtual
> addresses? That way we could workaround above issue.
>
> 3) Or, is it possible to make valgrind just track mallocs and not worry
> about mmaps? which could still workaround the issue!

Rather than speculating about what the problem is and asking us to 
answer various questions about your speculations why not just tell us 
what actually happens, with appropriate output messages, and let us see 
what we can advise?

To answer your questions:

1) Yes valgrind works find with mapped file segments, that's exactly 
what an ELF executable is after all.

2) No, you can't "not track" certain addresses because it just wouldn't 
work - valgrind needs to know everything that has happened in the 
program so it can accurately track the state of memory.

3) Again, no, and for the same reasons.

Tom

-- 
Tom Hughes (to...@co...)
http://compton.nu/

[Valgrind-users] Help running valgrind

[Harish B. <har...@gm...>]

Hello,

  I'm having trouble getting valgrind working with one of the software that
I'm working on. I worked around couple of initial issues and got it to
start. But then I running into other next issues, so I have following
questions:

1) Does valgrind work well with mapped file segments. We use these segments
for execution too! And I run into crashes when trying to execute code on
these pages.

2) Is it possible to tell valgrind not to track certain virtual addresses?
That way we could workaround above issue.

3) Or, is it possible to make valgrind just track mallocs and not worry
about mmaps? which could still workaround the issue!

Regards,
Harish

Re: [Valgrind-users] helgrind: false race positive with static variable in function

[Ivo R. <iv...@iv...>]

2016-03-30 10:59 GMT+02:00 David Faure <fa...@kd...>:

> This simple testcase :
>
> int foo() {
>     struct Foo {
>         int *i;
>         Foo() {  i = new int(42); }
>     };
>     static Foo f;
>     return *(f.i);
> }
>
> called from two threads (
> http://www.davidfaure.fr/2016/testcase_ogoffart.cpp)
> leads to this race warning in helgrind :
>

I've done some googling for you:
http://stackoverflow.com/questions/8393777/current-state-of-drd-and-helgrind-support-for-stdthread
https://gcc.gnu.org/onlinedocs/libstdc++/manual/debug.html (search for
"Data Race Hunting")
http://stackoverflow.com/questions/19128549/force-use-of-locks-inside-stdatomic-during-debugging-with-libstdc

There could be other articles, for sure.
If you find Valgrind documentation [1] not sufficient, please file bugs [2]
and suggest solutions. Patches are welcome!

Kind regards,
I.

[1] http://valgrind.org/docs/manual/manual.html
[2] http://valgrind.org/support/bug_reports.html

[Valgrind-users] helgrind: false race positive with static variable in function

[David F. <fa...@kd...>]

This simple testcase :

int foo() {
    struct Foo {
        int *i;
        Foo() {  i = new int(42); }
    };
    static Foo f;
    return *(f.i);
}

called from two threads (http://www.davidfaure.fr/2016/testcase_ogoffart.cpp)
leads to this race warning in helgrind :

==16440== Possible data race during read of size 8 at 0x602070 by thread #3
==16440== Locks held: none
==16440==    at 0x400B34: foo() (testcase_ogoffart.cpp:10)
==16440==    by 0x400B48: threadStart(void*) (testcase_ogoffart.cpp:16)
==16440==    by 0x4C3005E: mythread_wrapper (hg_intercepts.c:389)
==16440==    by 0x4E430A3: start_thread (pthread_create.c:309)
==16440==    by 0x595D00C: clone (clone.S:111)
==16440== 
==16440== This conflicts with a previous write of size 8 by thread #2
==16440== Locks held: none
==16440==    at 0x400AF2: foo()::Foo::Foo() (testcase_ogoffart.cpp:7)
==16440==    by 0x400B1B: foo() (testcase_ogoffart.cpp:9)
==16440==    by 0x400B48: threadStart(void*) (testcase_ogoffart.cpp:16)
==16440==    by 0x4C3005E: mythread_wrapper (hg_intercepts.c:389)
==16440==    by 0x4E430A3: start_thread (pthread_create.c:309)
==16440==    by 0x595D00C: clone (clone.S:111)
==16440==  Address 0x602070 is 0 bytes inside data symbol "_ZZ3foovE1f"

with both clang and gcc.
(and without -Wno-threadsafe-statics)

I assume that both compilers are not buggy. More likely, helgrind doesn't recognize
the atomic operations used by the compilers to protect the initialization of Foo ?

  <bb 3>:
  _5 = __cxa_guard_acquire (&_ZGVZ3foovE1f);
  if (_5 != 0)
    goto <bb 4>;
  else
    goto <bb 5>;

  <bb 4>:
  foo()::Foo::Foo (&f);
  __cxa_guard_release (&_ZGVZ3foovE1f);

Isn't cxa_guard_acquire implemented with mutexes? (Google seems to say so)
Why then does helgrind see a race? It doesn't catch the mutexes used internally in libstdc++?

-- 
David Faure, fa...@kd..., http://www.davidfaure.fr
Working on KDE Frameworks 5

Re: [Valgrind-users] 0 bytes inside a block of size 30,121

[Burlen L. <bl...@lb...>]

On 03/27/2016 03:08 AM, Tom Hughes wrote:
> On 26/03/16 19:15, Burlen Loring wrote:
>
>> I like to understand better the following reports. I have a buffer that
>> I allocated and that gets filled by MPI recv. However, for every access
>> to the buffer valgrind produce a report similar to the following first
>> report shown here:
>>
>>     Invalid read of size 4
>>     Address 0x1788a6d0 is 0 bytes inside a block of size 30,121 alloc'd
>>
>> in subsequent reports "0 bytes inside" the 0 is replaced with the offset
>> of the access in the buffer. Full output of the first few reports are
>> shown below.
>
> That does look odd. The only obvious way I can think of to get a 
> report like that is if you had explicitly told valgrind to consider 
> that memory as inaccessible with the VALGRIND_MAKE_MEM_NOACCESS call.
I haven't done that, but maybe the Open MPI library does. It does indeed 
seem that they are trying to using these features of valgrind. At least 
one of the first search hit with key you mention is a question a few 
days ago to valgrind list about how to mark a buffer as read only. :-) I 
have notice some other runtime checking that they enabled, and also a 
number valgrind leak reports in there code. although ompi_info claims 
the features are disabled. Maybe I follow up with them.  Thanks!

Re: [Valgrind-users] can memchecker mark memory as read-only ? 
<https://sourceforge.net/p/valgrind/mailman/message/34933327/>

Re: [Valgrind-users] 0 bytes inside a block of size 30,121

[Tom H. <to...@co...>]

On 26/03/16 19:15, Burlen Loring wrote:

> I like to understand better the following reports. I have a buffer that
> I allocated and that gets filled by MPI recv. However, for every access
> to the buffer valgrind produce a report similar to the following first
> report shown here:
>
>     Invalid read of size 4
>     Address 0x1788a6d0 is 0 bytes inside a block of size 30,121 alloc'd
>
> in subsequent reports "0 bytes inside" the 0 is replaced with the offset
> of the access in the buffer. Full output of the first few reports are
> shown below.

That does look odd. The only obvious way I can think of to get a report 
like that is if you had explicitly told valgrind to consider that memory 
as inaccessible with the VALGRIND_MAKE_MEM_NOACCESS call.

Tom

-- 
Tom Hughes (to...@co...)
http://compton.nu/

[Valgrind-users] 0 bytes inside a block of size 30,121

[Burlen L. <bl...@lb...>]

Hi All,

I like to understand better the following reports. I have a buffer that 
I allocated and that gets filled by MPI recv. However, for every access 
to the buffer valgrind produce a report similar to the following first 
report shown here:

    Invalid read of size 4
    Address 0x1788a6d0 is 0 bytes inside a block of size 30,121 alloc'd

in subsequent reports "0 bytes inside" the 0 is replaced with the offset 
of the access in the buffer. Full output of the first few reports are 
shown below.

what I don't understand about these reports are, if I am accessing 
memory inside the buffer I allocated how that is a problem?? I spent 
some time looking for problems in my code, and verifying that the recv'd 
data is accurate. Finally I tried MPI from a different vendor and the 
reports are gone!

Thanks for an insight into this!
Burlen


==23010== Invalid read of size 4
==23010==    at 0x60683FA: void teca_binary_stream::unpack<unsigned 
int>(unsigned int&) (teca_binary_stream.h:108)
==23010==    by 0x6433AD9: 
teca_metadata::from_stream(teca_binary_stream&) (teca_metadata.cxx:207)
==23010==    by 0x5D560BF: teca_cf_reader::get_output_metadata(unsigned 
int, std::vector<teca_metadata, std::allocator<teca_metadata> > const&) 
(teca_cf_reader.cxx:736)
==23010==    by 0x64266C4: 
teca_algorithm::get_output_metadata(std::pair<std::shared_ptr<teca_algorithm>, 
unsigned int>&) (teca_algorithm.cxx:579)
==23010==    by 0x642665B: 
teca_algorithm::get_output_metadata(std::pair<std::shared_ptr<teca_algorithm>, 
unsigned int>&) (teca_algorithm.cxx:573)
==23010==    by 0x642665B: 
teca_algorithm::get_output_metadata(std::pair<std::shared_ptr<teca_algorithm>, 
unsigned int>&) (teca_algorithm.cxx:573)
==23010==    by 0x642665B: 
teca_algorithm::get_output_metadata(std::pair<std::shared_ptr<teca_algorithm>, 
unsigned int>&) (teca_algorithm.cxx:573)
==23010==    by 0x642665B: 
teca_algorithm::get_output_metadata(std::pair<std::shared_ptr<teca_algorithm>, 
unsigned int>&) (teca_algorithm.cxx:573)
==23010==    by 0x6426F5A: teca_algorithm::update(unsigned int) 
(teca_algorithm.cxx:684)
==23010==    by 0x642725D: teca_algorithm::update() (teca_algorithm.cxx:708)
==23010==    by 0x4415FA: main (test_descriptive_statistics.cpp:100)
==23010==  Address 0x1788a6d0 is 0 bytes inside a block of size 30,121 
alloc'd
==23010==    at 0x4C28C50: malloc (vg_replace_malloc.c:298)
==23010==    by 0x4C2AC1C: realloc (vg_replace_malloc.c:785)
==23010==    by 0x643276B: teca_binary_stream::resize(unsigned long) 
(teca_binary_stream.cxx:87)
==23010==    by 0x5D55F3C: teca_cf_reader::get_output_metadata(unsigned 
int, std::vector<teca_metadata, std::allocator<teca_metadata> > const&) 
(teca_cf_reader.cxx:725)
==23010==    by 0x64266C4: 
teca_algorithm::get_output_metadata(std::pair<std::shared_ptr<teca_algorithm>, 
unsigned int>&) (teca_algorithm.cxx:579)
==23010==    by 0x642665B: 
teca_algorithm::get_output_metadata(std::pair<std::shared_ptr<teca_algorithm>, 
unsigned int>&) (teca_algorithm.cxx:573)
==23010==    by 0x642665B: 
teca_algorithm::get_output_metadata(std::pair<std::shared_ptr<teca_algorithm>, 
unsigned int>&) (teca_algorithm.cxx:573)
==23010==    by 0x642665B: 
teca_algorithm::get_output_metadata(std::pair<std::shared_ptr<teca_algorithm>, 
unsigned int>&) (teca_algorithm.cxx:573)
==23010==    by 0x642665B: 
teca_algorithm::get_output_metadata(std::pair<std::shared_ptr<teca_algorithm>, 
unsigned int>&) (teca_algorithm.cxx:573)
==23010==    by 0x6426F5A: teca_algorithm::update(unsigned int) 
(teca_algorithm.cxx:684)
==23010==    by 0x642725D: teca_algorithm::update() (teca_algorithm.cxx:708)
==23010==    by 0x4415FA: main (test_descriptive_statistics.cpp:100)
==23010==
unpacking 9
==23010== Invalid read of size 8
==23010==    at 0x44AB7C: void teca_binary_stream::unpack<unsigned 
long>(unsigned long&) (teca_binary_stream.h:108)
==23010==    by 0x44A62A: 
teca_binary_stream::unpack(std::__cxx11::basic_string<char, 
std::char_traits<char>, std::allocator<char> >&) (teca_binary_stream.h:147)
==23010==    by 0x6433B43: 
teca_metadata::from_stream(teca_binary_stream&) (teca_metadata.cxx:214)
==23010==    by 0x5D560BF: teca_cf_reader::get_output_metadata(unsigned 
int, std::vector<teca_metadata, std::allocator<teca_metadata> > const&) 
(teca_cf_reader.cxx:736)
==23010==    by 0x64266C4: 
teca_algorithm::get_output_metadata(std::pair<std::shared_ptr<teca_algorithm>, 
unsigned int>&) (teca_algorithm.cxx:579)
==23010==    by 0x642665B: 
teca_algorithm::get_output_metadata(std::pair<std::shared_ptr<teca_algorithm>, 
unsigned int>&) (teca_algorithm.cxx:573)
==23010==    by 0x642665B: 
teca_algorithm::get_output_metadata(std::pair<std::shared_ptr<teca_algorithm>, 
unsigned int>&) (teca_algorithm.cxx:573)
==23010==    by 0x642665B: 
teca_algorithm::get_output_metadata(std::pair<std::shared_ptr<teca_algorithm>, 
unsigned int>&) (teca_algorithm.cxx:573)
==23010==    by 0x642665B: 
teca_algorithm::get_output_metadata(std::pair<std::shared_ptr<teca_algorithm>, 
unsigned int>&) (teca_algorithm.cxx:573)
==23010==    by 0x6426F5A: teca_algorithm::update(unsigned int) 
(teca_algorithm.cxx:684)
==23010==    by 0x642725D: teca_algorithm::update() (teca_algorithm.cxx:708)
==23010==    by 0x4415FA: main (test_descriptive_statistics.cpp:100)
==23010==  Address 0x1788a6d4 is 4 bytes inside a block of size 30,121 
alloc'd
==23010==    at 0x4C28C50: malloc (vg_replace_malloc.c:298)
==23010==    by 0x4C2AC1C: realloc (vg_replace_malloc.c:785)
==23010==    by 0x643276B: teca_binary_stream::resize(unsigned long) 
(teca_binary_stream.cxx:87)
==23010==    by 0x5D55F3C: teca_cf_reader::get_output_metadata(unsigned 
int, std::vector<teca_metadata, std::allocator<teca_metadata> > const&) 
(teca_cf_reader.cxx:725)
==23010==    by 0x64266C4: 
teca_algorithm::get_output_metadata(std::pair<std::shared_ptr<teca_algorithm>, 
unsigned int>&) (teca_algorithm.cxx:579)
==23010==    by 0x642665B: 
teca_algorithm::get_output_metadata(std::pair<std::shared_ptr<teca_algorithm>, 
unsigned int>&) (teca_algorithm.cxx:573)
==23010==    by 0x642665B: 
teca_algorithm::get_output_metadata(std::pair<std::shared_ptr<teca_algorithm>, 
unsigned int>&) (teca_algorithm.cxx:573)
==23010==    by 0x642665B: 
teca_algorithm::get_output_metadata(std::pair<std::shared_ptr<teca_algorithm>, 
unsigned int>&) (teca_algorithm.cxx:573)
==23010==    by 0x642665B: 
teca_algorithm::get_output_metadata(std::pair<std::shared_ptr<teca_algorithm>, 
unsigned int>&) (teca_algorithm.cxx:573)
==23010==    by 0x6426F5A: teca_algorithm::update(unsigned int) 
(teca_algorithm.cxx:684)
==23010==    by 0x642725D: teca_algorithm::update() (teca_algorithm.cxx:708)
==23010==    by 0x4415FA: main (test_descriptive_statistics.cpp:100)
==23010==
==23010== Invalid read of size 2
==23010==    at 0x4C2D3E0: memcpy@@GLIBC_2.14 (vg_replace_strmem.c:1018)
==23010==    by 0x9E5F2DC: std::__cxx11::basic_string<char, 
std::char_traits<char>, std::allocator<char> >::_M_replace(unsigned 
long, unsigned long, char const*, unsigned long) (in 
/usr/lib64/libstdc++.so.6.0.21)
==23010==    by 0x44A658: 
teca_binary_stream::unpack(std::__cxx11::basic_string<char, 
std::char_traits<char>, std::allocator<char> >&) (teca_binary_stream.h:150)
==23010==    by 0x6433B43: 
teca_metadata::from_stream(teca_binary_stream&) (teca_metadata.cxx:214)
==23010==    by 0x5D560BF: teca_cf_reader::get_output_metadata(unsigned 
int, std::vector<teca_metadata, std::allocator<teca_metadata> > const&) 
(teca_cf_reader.cxx:736)
==23010==    by 0x64266C4: 
teca_algorithm::get_output_metadata(std::pair<std::shared_ptr<teca_algorithm>, 
unsigned int>&) (teca_algorithm.cxx:579)
==23010==    by 0x642665B: 
teca_algorithm::get_output_metadata(std::pair<std::shared_ptr<teca_algorithm>, 
unsigned int>&) (teca_algorithm.cxx:573)
==23010==    by 0x642665B: 
teca_algorithm::get_output_metadata(std::pair<std::shared_ptr<teca_algorithm>, 
unsigned int>&) (teca_algorithm.cxx:573)
==23010==    by 0x642665B: 
teca_algorithm::get_output_metadata(std::pair<std::shared_ptr<teca_algorithm>, 
unsigned int>&) (teca_algorithm.cxx:573)
==23010==    by 0x642665B: 
teca_algorithm::get_output_metadata(std::pair<std::shared_ptr<teca_algorithm>, 
unsigned int>&) (teca_algorithm.cxx:573)
==23010==    by 0x6426F5A: teca_algorithm::update(unsigned int) 
(teca_algorithm.cxx:684)
==23010==    by 0x642725D: teca_algorithm::update() (teca_algorithm.cxx:708)
==23010==  Address 0x1788a6dc is 12 bytes inside a block of size 30,121 
alloc'd
==23010==    at 0x4C28C50: malloc (vg_replace_malloc.c:298)
==23010==    by 0x4C2AC1C: realloc (vg_replace_malloc.c:785)
==23010==    by 0x643276B: teca_binary_stream::resize(unsigned long) 
(teca_binary_stream.cxx:87)
==23010==    by 0x5D55F3C: teca_cf_reader::get_output_metadata(unsigned 
int, std::vector<teca_metadata, std::allocator<teca_metadata> > const&) 
(teca_cf_reader.cxx:725)
==23010==    by 0x64266C4: 
teca_algorithm::get_output_metadata(std::pair<std::shared_ptr<teca_algorithm>, 
unsigned int>&) (teca_algorithm.cxx:579)
==23010==    by 0x642665B: 
teca_algorithm::get_output_metadata(std::pair<std::shared_ptr<teca_algorithm>, 
unsigned int>&) (teca_algorithm.cxx:573)
==23010==    by 0x642665B: 
teca_algorithm::get_output_metadata(std::pair<std::shared_ptr<teca_algorithm>, 
unsigned int>&) (teca_algorithm.cxx:573)
==23010==    by 0x642665B: 
teca_algorithm::get_output_metadata(std::pair<std::shared_ptr<teca_algorithm>, 
unsigned int>&) (teca_algorithm.cxx:573)
==23010==    by 0x642665B: 
teca_algorithm::get_output_metadata(std::pair<std::shared_ptr<teca_algorithm>, 
unsigned int>&) (teca_algorithm.cxx:573)
==23010==    by 0x6426F5A: teca_algorithm::update(unsigned int) 
(teca_algorithm.cxx:684)
==23010==    by 0x642725D: teca_algorithm::update() (teca_algorithm.cxx:708)
==23010==    by 0x4415FA: main (test_descriptive_statistics.cpp:100)
==23010==
==23010== Invalid read of size 2
==23010==    at 0x4C2D3EE: memcpy@@GLIBC_2.14 (vg_replace_strmem.c:1018)
==23010==    by 0x9E5F2DC: std::__cxx11::basic_string<char, 
std::char_traits<char>, std::allocator<char> >::_M_replace(unsigned 
long, unsigned long, char const*, unsigned long) (in 
/usr/lib64/libstdc++.so.6.0.21)
==23010==    by 0x44A658: 
teca_binary_stream::unpack(std::__cxx11::basic_string<char, 
std::char_traits<char>, std::allocator<char> >&) (teca_binary_stream.h:150)
==23010==    by 0x6433B43: 
teca_metadata::from_stream(teca_binary_stream&) (teca_metadata.cxx:214)
==23010==    by 0x5D560BF: teca_cf_reader::get_output_metadata(unsigned 
int, std::vector<teca_metadata, std::allocator<teca_metadata> > const&) 
(teca_cf_reader.cxx:736)
==23010==    by 0x64266C4: 
teca_algorithm::get_output_metadata(std::pair<std::shared_ptr<teca_algorithm>, 
unsigned int>&) (teca_algorithm.cxx:579)
==23010==    by 0x642665B: 
teca_algorithm::get_output_metadata(std::pair<std::shared_ptr<teca_algorithm>, 
unsigned int>&) (teca_algorithm.cxx:573)
==23010==    by 0x642665B: 
teca_algorithm::get_output_metadata(std::pair<std::shared_ptr<teca_algorithm>, 
unsigned int>&) (teca_algorithm.cxx:573)
==23010==    by 0x642665B: 
teca_algorithm::get_output_metadata(std::pair<std::shared_ptr<teca_algorithm>, 
unsigned int>&) (teca_algorithm.cxx:573)
==23010==    by 0x642665B: 
teca_algorithm::get_output_metadata(std::pair<std::shared_ptr<teca_algorithm>, 
unsigned int>&) (teca_algorithm.cxx:573)
==23010==    by 0x6426F5A: teca_algorithm::update(unsigned int) 
(teca_algorithm.cxx:684)
==23010==    by 0x642725D: teca_algorithm::update() (teca_algorithm.cxx:708)
==23010==  Address 0x1788a6e0 is 16 bytes inside a block of size 30,121 
alloc'd
==23010==    at 0x4C28C50: malloc (vg_replace_malloc.c:298)
==23010==    by 0x4C2AC1C: realloc (vg_replace_malloc.c:785)
==23010==    by 0x643276B: teca_binary_stream::resize(unsigned long) 
(teca_binary_stream.cxx:87)
==23010==    by 0x5D55F3C: teca_cf_reader::get_output_metadata(unsigned 
int, std::vector<teca_metadata, std::allocator<teca_metadata> > const&) 
(teca_cf_reader.cxx:725)
==23010==    by 0x64266C4: 
teca_algorithm::get_output_metadata(std::pair<std::shared_ptr<teca_algorithm>, 
unsigned int>&) (teca_algorithm.cxx:579)
==23010==    by 0x642665B: 
teca_algorithm::get_output_metadata(std::pair<std::shared_ptr<teca_algorithm>, 
unsigned int>&) (teca_algorithm.cxx:573)
==23010==    by 0x642665B: 
teca_algorithm::get_output_metadata(std::pair<std::shared_ptr<teca_algorithm>, 
unsigned int>&) (teca_algorithm.cxx:573)
==23010==    by 0x642665B: 
teca_algorithm::get_output_metadata(std::pair<std::shared_ptr<teca_algorithm>, 
unsigned int>&) (teca_algorithm.cxx:573)
==23010==    by 0x642665B: 
teca_algorithm::get_output_metadata(std::pair<std::shared_ptr<teca_algorithm>, 
unsigned int>&) (teca_algorithm.cxx:573)
==23010==    by 0x6426F5A: teca_algorithm::update(unsigned int) 
(teca_algorithm.cxx:684)
==23010==    by 0x642725D: teca_algorithm::update() (teca_algorithm.cxx:708)
==23010==    by 0x4415FA: main (test_descriptive_statistics.cpp:100)
==23010==
==23010== Invalid read of size 4
==23010==    at 0x60683FA: void teca_binary_stream::unpack<unsigned 
int>(unsigned int&) (teca_binary_stream.h:108)
==23010==    by 0x6433B56: 
teca_metadata::from_stream(teca_binary_stream&) (teca_metadata.cxx:217)
==23010==    by 0x5D560BF: teca_cf_reader::get_output_metadata(unsigned 
int, std::vector<teca_metadata, std::allocator<teca_metadata> > const&) 
(teca_cf_reader.cxx:736)
==23010==    by 0x64266C4: 
teca_algorithm::get_output_metadata(std::pair<std::shared_ptr<teca_algorithm>, 
unsigned int>&) (teca_algorithm.cxx:579)
==23010==    by 0x642665B: 
teca_algorithm::get_output_metadata(std::pair<std::shared_ptr<teca_algorithm>, 
unsigned int>&) (teca_algorithm.cxx:573)
==23010==    by 0x642665B: 
teca_algorithm::get_output_metadata(std::pair<std::shared_ptr<teca_algorithm>, 
unsigned int>&) (teca_algorithm.cxx:573)
==23010==    by 0x642665B: 
teca_algorithm::get_output_metadata(std::pair<std::shared_ptr<teca_algorithm>, 
unsigned int>&) (teca_algorithm.cxx:573)
==23010==    by 0x642665B: 
teca_algorithm::get_output_metadata(std::pair<std::shared_ptr<teca_algorithm>, 
unsigned int>&) (teca_algorithm.cxx:573)
==23010==    by 0x6426F5A: teca_algorithm::update(unsigned int) 
(teca_algorithm.cxx:684)
==23010==    by 0x642725D: teca_algorithm::update() (teca_algorithm.cxx:708)
==23010==    by 0x4415FA: main (test_descriptive_statistics.cpp:100)
==23010==  Address 0x1788a6e6 is 22 bytes inside a block of size 30,121 
alloc'd
==23010==    at 0x4C28C50: malloc (vg_replace_malloc.c:298)
==23010==    by 0x4C2AC1C: realloc (vg_replace_malloc.c:785)
==23010==    by 0x643276B: teca_binary_stream::resize(unsigned long) 
(teca_binary_stream.cxx:87)
==23010==    by 0x5D55F3C: teca_cf_reader::get_output_metadata(unsigned 
int, std::vector<teca_metadata, std::allocator<teca_metadata> > const&) 
(teca_cf_reader.cxx:725)
==23010==    by 0x64266C4: 
teca_algorithm::get_output_metadata(std::pair<std::shared_ptr<teca_algorithm>, 
unsigned int>&) (teca_algorithm.cxx:579)
==23010==    by 0x642665B: 
teca_algorithm::get_output_metadata(std::pair<std::shared_ptr<teca_algorithm>, 
unsigned int>&) (teca_algorithm.cxx:573)
==23010==    by 0x642665B: 
teca_algorithm::get_output_metadata(std::pair<std::shared_ptr<teca_algorithm>, 
unsigned int>&) (teca_algorithm.cxx:573)
==23010==    by 0x642665B: 
teca_algorithm::get_output_metadata(std::pair<std::shared_ptr<teca_algorithm>, 
unsigned int>&) (teca_algorithm.cxx:573)
==23010==    by 0x642665B: 
teca_algorithm::get_output_metadata(std::pair<std::shared_ptr<teca_algorithm>, 
unsigned int>&) (teca_algorithm.cxx:573)
==23010==    by 0x6426F5A: teca_algorithm::update(unsigned int) 
(teca_algorithm.cxx:684)
==23010==    by 0x642725D: teca_algorithm::update() (teca_algorithm.cxx:708)
==23010==    by 0x4415FA: main (test_descriptive_statistics.cpp:100)

[Valgrind-users] Multi threading

[David N. <do...@ma...>]

> Hi,
> 
> I am running valgrind in order to get a call graph, I am running top
> and I keep seeing only one thread 100% cpu working for valgrind.
> 
> Does valgrind have any parameters that I can set for him, so it will
> use all my machine cores (16 for example) ?
> 
> Regards,
> Dor Ben Dov
> 
> This message and the information contained herein is proprietary and
> confidential and subject to the Amdocs policy statement, you may review
> at http://www.amdocs.com/email_disclaimer.asp -------------- next part

There is no way that a public archived mailing list is or can be
confidential. Consider removing the trailing privacy statement next time
you email a public mailing list.

Sincerely, David

Re: [Valgrind-users] Insight as to why Valgrind shows memory leak for LAPACKE_dgbsv

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

----- Original Message -----
> This is the first time I've ever used Intel's MKL LAPACKE and
> Valgrind. Unfortunately, I get an error with something I have little
> to no experience with. I could use some advice on how to cure a
> potential memory leak. I'm using Intel's MKL library, so I highly
> assume this issue is my fault, but I'm not exactly sure what to look
> for or how to debug the issue.

Hi

I'm not familiar with LAPACKE.

Looking at your Valgrind traces, thay say that you have possible leaks. The most likely cause is that LAPACKE is using a memory manager. I don't know if you need to use LAPACKE_malloc and LAPACKE_free, or whether you need to call some finalization function to free the LAPACKE memory pool.

Source code can be instrumented for memory pools (see http://valgrind.org/docs/manual/mc-manual.html#mc-manual.mempools) but I doubt that will be feasible with LAPACKE.

A+
Paul

[Valgrind-users] Insight as to why Valgrind shows memory leak for LAPACKE_dgbsv

[Troy H. <sal...@gm...>]

This is the first time I've ever used Intel's MKL LAPACKE and Valgrind.
Unfortunately, I get an error with something I have little to no experience
with. I could use some advice on how to cure a potential memory leak. I'm
using Intel's MKL library, so I highly assume this issue is my fault, but
I'm not exactly sure what to look for or how to debug the issue.

Here is my code (I'm not a programmer)

    int NSUB,NSUPER,NDIAG;
    double *BAND_MX, *SOL;

    NSUB = 3;
    NSUPER = NSUB;
    NDIAG = NSUB + 1 + NSUPER;

    // Intel MKL local variables
    MKL_INT n = 50;
    MKL_INT kl = NSUB;
     MKL_INT ku = NSUPER;
    MKL_INT nrhs = 1;
    MKL_INT lda = 50;
    MKL_INT ldb = 1;
    MKL_INT info;
     MKL_INT *ipiv;

    // Solution array & Banded matrix
    BAND_MX = (double*)calloc(M*(NDIAG+NSUB),sizeof(double));
    SOL = (double*)calloc(M,sizeof(double));

    ipiv = (MKL_INT*)calloc(M,sizeof(MKL_INT));

Then I add in a bunch of values into `BAND_MX`, which I believe isn't the
issue. At the very least, the array would be filled with zeros. So I must
be missing something else? Here is my call to the routine, where Valgrind
has a breakpoint (line 127).

    info = LAPACKE_dgbsv(LAPACK_ROW_MAJOR, n, kl, ku, nrhs, BAND_MX, lda,
ipiv, SOL, ldb );


Valgrind output:

    Multiple markers at this line
        - 256 bytes in 1 blocks are possibly lost in loss record 5 of 12
[PID: 12922]
        - Line breakpoint: LUx.c [line: 127]
        - 32,928 bytes in 1 blocks are possibly lost in loss record 8 of 12
[PID: 12922]
        - 32,928 bytes in 1 blocks are possibly lost in loss record 7 of 12
[PID: 12922]
        - 80,160 bytes in 1 blocks are possibly lost in loss record 10 of
12 [PID:
         12922]
        - 69,664 bytes in 1 blocks are possibly lost in loss record 9 of 12
[PID: 12922]
        - 320,160 bytes in 1 blocks are possibly lost in loss record 12 of
12 [PID:
         12922]
        - 80,160 bytes in 1 blocks are possibly lost in loss record 11 of
12 [PID:
         12922]

Is there something that I'm clearly doing wrong? I should also note I'm
using eclipse to do this in. I'm more a custom to using Matlab, where I can
view the array details while debugging, but I haven't found eclipse to be
as user friendly. So again, any advice on how to debug this would be great!

Here are some more of the details from the log file (just a few of them):

record 5

    ==14411==    at 0x4C2AB80: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
    ==14411==    by 0x5899F49: mm_account_ptr_by_tid..0 (in
/usr/local/INTEL/compilers_and_libraries_2016.2.181/linux/mkl/lib/intel64_lin/libmkl_core.so)
    ==14411==    by 0x5898399: mkl_serv_allocate (in
/usr/local/INTEL/compilers_and_libraries_2016.2.181/linux/mkl/lib/intel64_lin/libmkl_core.so)
    ==14411==    by 0x51FE053: LAPACKE_dgbsv_work (in
/usr/local/INTEL/compilers_and_libraries_2016.2.181/linux/mkl/lib/intel64_lin/libmkl_intel_lp64.so)

record 7

    ==14411==    at 0x4C2AB80: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
    ==14411==    by 0x5898A3D: mkl_serv_allocate (in
/usr/local/INTEL/compilers_and_libraries_2016.2.181/linux/mkl/lib/intel64_lin/libmkl_core.so)
    ==14411==    by 0x62A1772: mkl_lapack_xdgbtrf (in
/usr/local/INTEL/compilers_and_libraries_2016.2.181/linux/mkl/lib/intel64_lin/libmkl_core.so)
    ==14411==    by 0x746F2EA: mkl_lapack_dgbtrf (in
/usr/local/INTEL/compilers_and_libraries_2016.2.181/linux/mkl/lib/intel64_lin/libmkl_sequential.so)
    ==14411==    by 0x5DA7FF0: mkl_lapack_dgbsv (in
/usr/local/INTEL/compilers_and_libraries_2016.2.181/linux/mkl/lib/intel64_lin/libmkl_core.so)
    ==14411==    by 0x50CFC92: DGBSV (in
/usr/local/INTEL/compilers_and_libraries_2016.2.181/linux/mkl/lib/intel64_lin/libmkl_intel_lp64.so)
    ==14411==    by 0x51FE148: LAPACKE_dgbsv_work (in
/usr/local/INTEL/compilers_and_libraries_2016.2.181/linux/mkl/lib/intel64_lin/libmkl_intel_lp64.so)

I can post more records if need be. I also have a post on stack overflow,
but it was recommended I send an email here.

http://stackoverflow.com/questions/36197527/insight-as-to-why-valgrind-shows-memory-leak-for-lapacke-dgbsv?noredirect=1#comment60030370_36197527

Thanks

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

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

Hi Paul... that's is the problem.. valgrind it doesn't work in Qt Creator,
nither in console... but I need to know if I have a memory leaks, because my
application is a server which has many connections.

what can I do about it ? valgrind is the only tool which I know to check
memory leaks

regards



--
View this message in context: http://valgrind.10908.n7.nabble.com/valgrind-it-doesn-t-work-with-Qt-Creator-in-OS-X-tp56167p56292.html
Sent from the Valgrind - Users mailing list archive at Nabble.com.

Re: [Valgrind-users] helgrind, clang and thread_local

[David F. <fa...@kd...>]

On Monday 21 March 2016 14:56:09 Alexander Potapenko wrote:
> > Helgrind bug, or is clang silently ignoring thread_local?
> Clang documentation (http://clang.llvm.org/cxx_status.html) says
> thread_local support requires libc++abi 3.6+ or libsupc++ 4.8+.
> Does your binary use any of those?

Oh. I use libstdc++, that's why, then.

I had no idea that the feature check for clang could pass and then the
feature would fail at runtime due to using another c++ standard library. Tricky.

libc++ and libsupc++ don't seem to be packaged for OpenSUSE 13.2,
(while clang is) so I'll ignore this for now. Thanks!

-- 
David Faure, fa...@kd..., http://www.davidfaure.fr
Working on KDE Frameworks 5

Re: [Valgrind-users] helgrind, clang and thread_local

[Alexander P. <gl...@go...>]

On Sat, Mar 19, 2016 at 10:02 PM, David Faure <fa...@kd...> wrote:
> The following code (from Qt5's qlogging.cpp)
>
> static thread_local bool msgHandlerGrabbed = false;
>
> static bool grabMessageHandler()
> {
>     if (msgHandlerGrabbed)
>         return false;
>
>     msgHandlerGrabbed = true;
>     return true;
> }
>
> static void ungrabMessageHandler()
> {
>     msgHandlerGrabbed = false;
> }
>
> (purpose: avoiding recursion)
>
> when compiled with clang 3.5.0, and called from multiple threads, leads to this helgrind warning:
>
> ==1218== Possible data race during write of size 1 at 0x1E1F86F0 by thread #17
> ==1218== Locks held: none
> ==1218==    at 0x783637B: grabMessageHandler() (qlogging.cpp:1543)
> ==1218==    by 0x783640B: qt_message_print(QtMsgType, QMessageLogContext const&, QString const&) (qlogging.cpp:1571)
> ==1218==    by 0x783658A: qt_message_output(QtMsgType, QMessageLogContext const&, QString const&) (qlogging.cpp:1622)
> ==1218==    by 0x798DC32: QDebug::~QDebug() (qdebug.cpp:150)
> ==1218==    by 0x4F24EF6: CompletionThread::done() (kurlcompletion.cpp:232)
> ==1218==    by 0x4F1ECCD: DirectoryListThread::run() (kurlcompletion.cpp:368)
> ==1218==    by 0x784B0B6: QThreadPrivate::start(void*) (qthread_unix.cpp:340)
> ==1218==    by 0x4C3005E: mythread_wrapper (hg_intercepts.c:389)
> ==1218==    by 0x9DAE0A3: start_thread (pthread_create.c:309)
> ==1218==    by 0x869100C: clone (clone.S:111)
> ==1218==
> ==1218== This conflicts with a previous write of size 1 by thread #16
> ==1218== Locks held: none
> ==1218==    at 0x7836399: ungrabMessageHandler() (qlogging.cpp:1549)
> ==1218==    by 0x78364BC: qt_message_print(QtMsgType, QMessageLogContext const&, QString const&) (qlogging.cpp:1579)
> ==1218==    by 0x783658A: qt_message_output(QtMsgType, QMessageLogContext const&, QString const&) (qlogging.cpp:1622)
> ==1218==    by 0x798DC32: QDebug::~QDebug() (qdebug.cpp:150)
> ==1218==    by 0x4F24EF6: CompletionThread::done() (kurlcompletion.cpp:232)
> ==1218==    by 0x4F1ECCD: DirectoryListThread::run() (kurlcompletion.cpp:368)
> ==1218==    by 0x784B0B6: QThreadPrivate::start(void*) (qthread_unix.cpp:340)
> ==1218==    by 0x4C3005E: mythread_wrapper (hg_intercepts.c:389)
> ==1218==  Address 0x1e1f86f0 is in a rw- anonymous segment
>
> Helgrind bug, or is clang silently ignoring thread_local?
Clang documentation (http://clang.llvm.org/cxx_status.html) says
thread_local support requires libc++abi 3.6+ or libsupc++ 4.8+.
Does your binary use any of those?

> --
> David Faure, fa...@kd..., http://www.davidfaure.fr
> Working on KDE Frameworks 5
>
>
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users



-- 
Alexander Potapenko
Software Engineer

Google Germany GmbH
Erika-Mann-Straße, 33
80636 München

Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg

[Valgrind-users] helgrind, clang and thread_local

[David F. <fa...@kd...>]

The following code (from Qt5's qlogging.cpp)

static thread_local bool msgHandlerGrabbed = false;

static bool grabMessageHandler()
{
    if (msgHandlerGrabbed)
        return false;

    msgHandlerGrabbed = true;
    return true;
}

static void ungrabMessageHandler()
{
    msgHandlerGrabbed = false;
}

(purpose: avoiding recursion)

when compiled with clang 3.5.0, and called from multiple threads, leads to this helgrind warning:

==1218== Possible data race during write of size 1 at 0x1E1F86F0 by thread #17
==1218== Locks held: none
==1218==    at 0x783637B: grabMessageHandler() (qlogging.cpp:1543)
==1218==    by 0x783640B: qt_message_print(QtMsgType, QMessageLogContext const&, QString const&) (qlogging.cpp:1571)
==1218==    by 0x783658A: qt_message_output(QtMsgType, QMessageLogContext const&, QString const&) (qlogging.cpp:1622)
==1218==    by 0x798DC32: QDebug::~QDebug() (qdebug.cpp:150)
==1218==    by 0x4F24EF6: CompletionThread::done() (kurlcompletion.cpp:232)
==1218==    by 0x4F1ECCD: DirectoryListThread::run() (kurlcompletion.cpp:368)
==1218==    by 0x784B0B6: QThreadPrivate::start(void*) (qthread_unix.cpp:340)
==1218==    by 0x4C3005E: mythread_wrapper (hg_intercepts.c:389)
==1218==    by 0x9DAE0A3: start_thread (pthread_create.c:309)
==1218==    by 0x869100C: clone (clone.S:111)
==1218== 
==1218== This conflicts with a previous write of size 1 by thread #16
==1218== Locks held: none
==1218==    at 0x7836399: ungrabMessageHandler() (qlogging.cpp:1549)
==1218==    by 0x78364BC: qt_message_print(QtMsgType, QMessageLogContext const&, QString const&) (qlogging.cpp:1579)
==1218==    by 0x783658A: qt_message_output(QtMsgType, QMessageLogContext const&, QString const&) (qlogging.cpp:1622)
==1218==    by 0x798DC32: QDebug::~QDebug() (qdebug.cpp:150)
==1218==    by 0x4F24EF6: CompletionThread::done() (kurlcompletion.cpp:232)
==1218==    by 0x4F1ECCD: DirectoryListThread::run() (kurlcompletion.cpp:368)
==1218==    by 0x784B0B6: QThreadPrivate::start(void*) (qthread_unix.cpp:340)
==1218==    by 0x4C3005E: mythread_wrapper (hg_intercepts.c:389)
==1218==  Address 0x1e1f86f0 is in a rw- anonymous segment

Helgrind bug, or is clang silently ignoring thread_local?

-- 
David Faure, fa...@kd..., http://www.davidfaure.fr
Working on KDE Frameworks 5

Re: [Valgrind-users] Multi-threading

[Dor B. D. <dor...@am...>]

Thanks Paul.

Dor

-----Original Message-----
From: pa...@fr... [mailto:pa...@fr...] 
Sent: יום ה 17 מרץ 2016 12:01
To: val...@li...
Subject: Re: [Valgrind-users] Multi-threading


----- Original Message -----
> Can you give me the link and save me the drilling effort, please ?
> 
> 
> One more thing, let's assume I continue using this way the valgrind to 
> create my call graphs. Does a huge memory dedicated for this purpose, 
> in my case 32gb ram may cause other issues due to the mentioned 
> serialization process he does ?
> 
> Dor

Hi

Here is the search page for the archives:

https://sourceforge.net/p/valgrind/mailman/search

If you search for "multi thread" then you should find a few discussions like 

"multi threaded valgrind: a first (hacked) prototype for discussions"

and

"mtV : improve Valgrind to run multiple threads in parallel"

The discussion that I was referring to is on the valgrind-developers mailing list, with the subject "Using lock in tool"

A+
Paul

------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
_______________________________________________
Valgrind-users mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users

This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement,
you may review at http://www.amdocs.com/email_disclaimer.asp

Re: [Valgrind-users] Multi-threading

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

----- Original Message -----
> Can you give me the link and save me the drilling effort, please ?
> 
> 
> One more thing, let's assume I continue using this way the valgrind
> to create my call graphs. Does a huge memory dedicated for this
> purpose, in my case 32gb ram may cause other issues due to the
> mentioned serialization process he does ?
> 
> Dor

Hi

Here is the search page for the archives:

https://sourceforge.net/p/valgrind/mailman/search

If you search for "multi thread" then you should find a few discussions like 

"multi threaded valgrind: a first (hacked) prototype for discussions"

and

"mtV : improve Valgrind to run multiple threads in parallel"

The discussion that I was referring to is on the valgrind-developers mailing list, with the subject "Using lock in tool"

A+
Paul

Re: [Valgrind-users] Multi-threading

[Dor B. D. <dor...@am...>]

Can you give me the link and save me the drilling effort, please ? 


One more thing, let's assume I continue using this way the valgrind to create my call graphs. Does a huge memory dedicated for this purpose, in my case 32gb ram may cause other issues due to the mentioned serialization process he does ? 

Dor

-----Original Message-----
From: pa...@fr... [mailto:pa...@fr...] 
Sent: יום ה 17 מרץ 2016 11:21
To: val...@li...
Subject: Re: [Valgrind-users] Multi threading


----- Original Message -----
> Hi,
>
> I am running valgrind in order to get a call graph, I am running top 
> and I keep seeing only one thread 100% cpu working for valgrind.
> 
> Does valgrind have any parameters that I can set for him, so it will 
> use all my machine cores (16 for example) ?

Hi

In short, Valgrind serializes threads to run on one core.

This questions comes up fairly regularly on this list. Check the archives, there was a recent post with a link to a presentation on what has been done and what would be required to have multithreading in Valgrind.

A+
Paul

------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
_______________________________________________
Valgrind-users mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users

This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement,
you may review at http://www.amdocs.com/email_disclaimer.asp

Re: [Valgrind-users] Multi threading

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

----- Original Message -----
> Hi,
>
> I am running valgrind in order to get a call graph, I am running top
> and I keep seeing only one thread 100% cpu working for valgrind.
> 
> Does valgrind have any parameters that I can set for him, so it will
> use all my machine cores (16 for example) ?

Hi

In short, Valgrind serializes threads to run on one core.

This questions comes up fairly regularly on this list. Check the archives, there was a recent post with a link to a presentation on what has been done and what would be required to have multithreading in Valgrind.

A+
Paul