valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] A weird memory leak with openmp task depend

[Floyd, P. <pj...@wa...>]

Hi

You need to tell us more details

Which OS?

Which version of Valgrind?

What CPU?

Which compiler?

Which version of OMP?

A+

Paul

[Valgrind-users] A weird memory leak with openmp task depend

[<569...@qq...>]

Dear All，


I have a memory leak with the following example. I don't know why, please help me.
#include <stdio.h&gt;
#include <stdlib.h&gt;
#include <omp.h&gt;


Code:
int main()
{
&nbsp; &nbsp; int a = 0;
&nbsp; &nbsp; int b = 0;
&nbsp; &nbsp; int j = 0;
&nbsp; &nbsp; for (j = 0; j < 3;j++)
&nbsp; &nbsp; {
&nbsp; &nbsp; #pragma omp parallel
&nbsp; &nbsp; #pragma omp single
&nbsp; &nbsp; &nbsp; &nbsp; {


&nbsp; &nbsp; &nbsp; &nbsp; #pragma omp task depend(out: b)
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; {
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; printf("task 1=%d\n", a);
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; }
&nbsp; &nbsp; &nbsp; &nbsp; #pragma omp task depend(in: b)
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; {
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; printf("task 2=%d\n", a);
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; }


&nbsp; &nbsp; &nbsp; &nbsp; }
&nbsp; &nbsp; }
&nbsp; &nbsp; return 0;
}

error msg: 136 bytes in 1 bloacks are definitely lost in loss record 3 of 8
by 0x4008CB: main.-omp_fn.0(test.c: 19)




Best&nbsp;
Gang Chen
Sichuan&nbsp; University

[Valgrind-users] client program compiled with pie

[Mark R. <ma...@cs...>]

How do I find the loaded address of a client program that was compiled
with -pie?   I.e., how to I map the current execution address  - such as
0x4021151 - to the address in the elf file - such as 0x1193?  With -nopie
the two are identical.

Thank you,
Mark

Re: [Valgrind-users] Timer delete

[Paul F. <pj...@wa...>]

Hi

I've done most of the work to get the pthread stack cache turned off 
with glibc >= 2.34.

(see https://bugs.kde.org/show_bug.cgi?id=444488).

This doesn't help with this example, and it looks to me that this is a 
problem with libc / rtld.


A+

Paul

Re: [Valgrind-users] Timer delete

[Paul F. <pj...@wa...>]

> Yes, the cache disabling is quite hacky, as mentionnd in the doc:
> "Valgrind disables the cache using some internal
>   knowledge of the glibc stack cache implementation and by
>   examining the debug information of the pthread
>   library. This technique is thus somewhat fragile and might
>   not work for all glibc versions. This has been successfully
>   tested with various glibc versions (e.g. 2.11, 2.16, 2.18)
>   on various platforms."
>
>
>
> As you indicate, it looks broken on the more recent glibc version you tried.
>
> Philippe
>
Indeed. Looks like this:


Author: Florian Weimer <fw...@re...>  2021-05-10 10:31:41
Committer: Florian Weimer <fw...@re...>  2021-05-10 10:31:41
Parent: d017b0ab5a181dce4145f3a1b3b27e3341abd201 (elf: Introduce 
__tls_pre_init_tp)
Child:  ee07b3a7222746fafc5d5cb2163c9609b81615ef (nptl: Simplify the 
change_stack_perm calling convention)
Branches: master, remotes/origin/arm/morello/main, 
remotes/origin/arm/morello/v1, remotes/origin/arm/morello/v2, 
remotes/origin/azanella/bz23960-dirent, remotes/origin/azanella/clang, 
remotes/origin/codonell/c-utf8, remotes/origin/codonell/ld-audit, 
remotes/origin/fw/localedef-utf8, remotes/origin/maskray/relr, 
remotes/origin/maskray/x86-mpx, remotes/origin/master, 
remotes/origin/nsz/bug23293, remotes/origin/nsz/bug23293-v5, 
remotes/origin/nsz/bug23293-v6, remotes/origin/release/2.34/master, 
remotes/origin/release/2.35/master, remotes/origin/release/2.36/master, 
remotes/origin/siddhesh/realpath-and-getcwd
Follows: glibc-2.33.9000
Precedes: glibc-2.34

     nptl: Move more stack management variables into _rtld_global

     Permissions of the cached stacks may have to be updated if an object
     is loaded that requires executable stacks, so the dynamic loader
     needs to know about these cached stacks.

     The move of in_flight_stack and stack_cache_actsize is a 
requirement for
     merging __reclaim_stacks into the fork implementation in libc.

     Tested-by: Carlos O'Donell <ca...@re...>
     Reviewed-by: Carlos O'Donell <ca...@re...>

It looks like "stack_cache_actsize" in libc moved to be 
_dl_stack_cache_actsize in ld-linux-x86-64.so.2


A+

Paul

Re: [Valgrind-users] Timer delete

[Mark W. <ma...@kl...>]

On Sat, Nov 12, 2022 at 12:46:41PM +0100, Philippe Waroquiers wrote:
> On Sat, 2022-11-12 at 12:21 +0100, Paul Floyd wrote:
> > So my conclusion is that there are two problems
> > 1. Some cleanup code missing in __libc_freeres that is causing this leak 
> > (libc problem)
> > 2. no-stackcache not working. This is more a Valgrind problem, but it 
> > does rely on twiddling libc internals, so it's not too surprising that 
> > it breaks. That needs work on the Valgrind side.
> Yes, the cache disabling is quite hacky, as mentionnd in the doc:
> "Valgrind disables the cache using some internal
>  knowledge of the glibc stack cache implementation and by
>  examining the debug information of the pthread
>  library. This technique is thus somewhat fragile and might
>  not work for all glibc versions. This has been successfully
>  tested with various glibc versions (e.g. 2.11, 2.16, 2.18)
>  on various platforms."
> 
> As you indicate, it looks broken on the more recent glibc version you tried.

This is https://bugs.kde.org/show_bug.cgi?id=444488
Use glibc.pthread.stack_cache_size tunable

  Since glibc 2.34 the internal/private stack_cache_maxsize variable
  isn't available anymore, which causes "sched WARNING: pthread stack
  cache cannot be disabled!" when the simhint no_nptl_pthread_stackcache
  is set (e.g. in helgrind/tests/tls_threads.vgtest)

Cheers,

Mark

Re: [Valgrind-users] Timer delete

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

On Sat, 2022-11-12 at 12:21 +0100, Paul Floyd wrote:

> Philiipe wrote:
> > Possibly --sim-hints=no-nptl-pthread-stackcache might help (if I
> > re-read the manual entry for this sim-hint).
> 
> 
> As the manpage says, the pthread stackcache stuff is mainly for Helgrind.
....


> 
> I don't see how this would affect a leak though.

This sim-hint also influences memcheck behaviour related to __thread (i.e. tls) variables.
Here is the extract of the doc:
"When using the memcheck tool, disabling the cache ensures the memory used by glibc to 
handle __thread variables is directly released when a thread terminates."
(at least that was likely true in 2014, when the above was written).


> 
> I did some tests to check that __libc_freeres is being called (and it is 
> being called).
> 
> So my conclusion is that there are two problems
> 1. Some cleanup code missing in __libc_freeres that is causing this leak 
> (libc problem)
> 2. no-stackcache not working. This is more a Valgrind problem, but it 
> does rely on twiddling libc internals, so it's not too surprising that 
> it breaks. That needs work on the Valgrind side.
Yes, the cache disabling is quite hacky, as mentionnd in the doc:
"Valgrind disables the cache using some internal
 knowledge of the glibc stack cache implementation and by
 examining the debug information of the pthread
 library. This technique is thus somewhat fragile and might
 not work for all glibc versions. This has been successfully
 tested with various glibc versions (e.g. 2.11, 2.16, 2.18)
 on various platforms."



As you indicate, it looks broken on the more recent glibc version you tried.

Philippe

Re: [Valgrind-users] Timer delete

[Paul F. <pj...@wa...>]

On 11/12/22 01:46, John Reiser wrote:

> It's a bug (or implementation constraint) in glibc timer.

> When I run it under valgrind-3.19.0 with glibc-debuginfo and
> glibc-debugsource installed (2.35-17.fc36.x86_64):
>  [Notice the annotation "LOOK HERE"]

> ==281161== Command: ./a.out
> ==281161==
> --281161:0:   sched WARNING: pthread stack cache cannot be disabled!  
> <<<<< LOOK HERE <<<<<


And also


Philiipe wrote:
> Possibly --sim-hints=no-nptl-pthread-stackcache might help (if I
> re-read the manual entry for this sim-hint).


As the manpage says, the pthread stackcache stuff is mainly for Helgrind.

What the code does is use debuginfo to find the GNU libc variable that 
describes the size of the stack cache, and forces it to be some large 
value. That causes libthead to think that the cache is full (when it is 
still really empty) and not use the cache. That means that every time a 
thread gets created a new stack will get allocated rather than allocated 
and recycled in the cache.

The caching causes problems with Helgrind for applications using thread 
local storage in sequences like

write to TLS var on thread 2
thread 2 exit
thread 3 created recycles thread2's TLS
read from TLS var on thread 3

Helgrind just sees unprotected reads and writes from the same address 
without knowing that it isn't the same variable.

This test is currently failing for me (Fedora 36  amd64):

paulf> perl tests/vg_regtest helgrind/tests/tls_threads 

tls_threads:     valgrind   -q --sim-hints=no-nptl-pthread-stackcache 
./tls_threads
*** tls_threads failed (stderr) ***

(More details here 
https://github.com/paulfloyd/freebsd_valgrind/issues/113 since I've 
looked into how to implement something similar for FreeBSD).

I don't see how this would affect a leak though.

I did some tests to check that __libc_freeres is being called (and it is 
being called).

So my conclusion is that there are two problems
1. Some cleanup code missing in __libc_freeres that is causing this leak 
(libc problem)
2. no-stackcache not working. This is more a Valgrind problem, but it 
does rely on twiddling libc internals, so it's not too surprising that 
it breaks. That needs work on the Valgrind side.


FWIW on FreeBSD (no stack cache disable or libc freeres) I also get a 
bunch of leaks that I need to suppress.

A+
Paul

Re: [Valgrind-users] Timer delete

[Domenico P. <pan...@gm...>]

>  [[snip horrible formatting]] 
It looks so good.
Probably your email client messed up it.

Thanks so much for answer.
Good job,
Domenico


Il 12/11/22 01:46, John Reiser ha scritto:
> On 11/11/22 13:23, Domenico Panella wrote:
>> Operating System: Slackware 15.0 (Current) Kernel Version: 5.19.17 
>> (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Core™ i7-8565U 
>> CPU @ 1.80GHz
>>
>> A small example:
>>
>> #include<stdbool.h>
>  [[snip horrible formatting]]
>>
>
> It's a bug (or implementation constraint) in glibc timer.
>
> When I run it under valgrind-3.19.0 with glibc-debuginfo and 
> glibc-debugsource
> installed (2.35-17.fc36.x86_64):  [Notice the annotation "LOOK HERE"]
> =====
> $ valgrind --leak-check=full --sim-hints=no-nptl-pthread-stackcache 
> ./a.out
> ==281161== Memcheck, a memory error detector
> ==281161== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et 
> al.
> ==281161== Using Valgrind-3.19.0 and LibVEX; rerun with -h for 
> copyright info
> ==281161== Command: ./a.out
> ==281161==
> --281161:0:   sched WARNING: pthread stack cache cannot be disabled!  
> <<<<< LOOK HERE <<<<<
> ==281161==
> ==281161== HEAP SUMMARY:
> ==281161==     in use at exit: 272 bytes in 1 blocks
> ==281161==   total heap usage: 3 allocs, 2 frees, 512 bytes allocated
> ==281161==
> ==281161== 272 bytes in 1 blocks are possibly lost in loss record 1 of 1
> ==281161==    at 0x484A464: calloc (vg_replace_malloc.c:1328)
> ==281161==    by 0x4012E42: UnknownInlinedFun (rtld-malloc.h:44)
> ==281161==    by 0x4012E42: allocate_dtv (dl-tls.c:375)
> ==281161==    by 0x4013841: _dl_allocate_tls (dl-tls.c:634)
> ==281161==    by 0x48F5A98: allocate_stack (allocatestack.c:428)
> ==281161==    by 0x48F5A98: pthread_create@@GLIBC_2.34 
> (pthread_create.c:647)
> ==281161==    by 0x4900864: __timer_start_helper_thread 
> (timer_routines.c:147)
> ==281161==    by 0x48F9E36: __pthread_once_slow (pthread_once.c:116)
> ==281161==    by 0x49002CA: timer_create@@GLIBC_2.34 (timer_create.c:70)
> ==281161==    by 0x4011E2: main (timer.c:40)
> ==281161==
> ==281161== LEAK SUMMARY:
> ==281161==    definitely lost: 0 bytes in 0 blocks
> ==281161==    indirectly lost: 0 bytes in 0 blocks
> ==281161==      possibly lost: 272 bytes in 1 blocks
> ==281161==    still reachable: 0 bytes in 0 blocks
> ==281161==         suppressed: 0 bytes in 0 blocks
> ==281161==
> ==281161== For lists of detected and suppressed errors, rerun with: -s
> ==281161== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
> =====
>
>
>
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Timer delete

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

On 11/11/22 13:23, Domenico Panella wrote:
> Operating System: Slackware 15.0 (Current) Kernel Version: 5.19.17 (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Core™ i7-8565U CPU @ 1.80GHz
> 
> A small example:
> 
> #include<stdbool.h>
  [[snip horrible formatting]]
> 

It's a bug (or implementation constraint) in glibc timer.

When I run it under valgrind-3.19.0 with glibc-debuginfo and glibc-debugsource
installed (2.35-17.fc36.x86_64):  [Notice the annotation "LOOK HERE"]
=====
$ valgrind --leak-check=full --sim-hints=no-nptl-pthread-stackcache ./a.out
==281161== Memcheck, a memory error detector
==281161== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==281161== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==281161== Command: ./a.out
==281161==
--281161:0:   sched WARNING: pthread stack cache cannot be disabled!  <<<<< LOOK HERE <<<<<
==281161==
==281161== HEAP SUMMARY:
==281161==     in use at exit: 272 bytes in 1 blocks
==281161==   total heap usage: 3 allocs, 2 frees, 512 bytes allocated
==281161==
==281161== 272 bytes in 1 blocks are possibly lost in loss record 1 of 1
==281161==    at 0x484A464: calloc (vg_replace_malloc.c:1328)
==281161==    by 0x4012E42: UnknownInlinedFun (rtld-malloc.h:44)
==281161==    by 0x4012E42: allocate_dtv (dl-tls.c:375)
==281161==    by 0x4013841: _dl_allocate_tls (dl-tls.c:634)
==281161==    by 0x48F5A98: allocate_stack (allocatestack.c:428)
==281161==    by 0x48F5A98: pthread_create@@GLIBC_2.34 (pthread_create.c:647)
==281161==    by 0x4900864: __timer_start_helper_thread (timer_routines.c:147)
==281161==    by 0x48F9E36: __pthread_once_slow (pthread_once.c:116)
==281161==    by 0x49002CA: timer_create@@GLIBC_2.34 (timer_create.c:70)
==281161==    by 0x4011E2: main (timer.c:40)
==281161==
==281161== LEAK SUMMARY:
==281161==    definitely lost: 0 bytes in 0 blocks
==281161==    indirectly lost: 0 bytes in 0 blocks
==281161==      possibly lost: 272 bytes in 1 blocks
==281161==    still reachable: 0 bytes in 0 blocks
==281161==         suppressed: 0 bytes in 0 blocks
==281161==
==281161== For lists of detected and suppressed errors, rerun with: -s
==281161== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
=====

Re: [Valgrind-users] Timer delete

[Domenico P. <pan...@gm...>]

Operating System: Slackware 15.0 (Current) Kernel Version: 5.19.17 
(64-bit) Graphics Platform: X11 Processors: 8 × Intel® Core™ i7-8565U 
CPU @ 1.80GHz

A small example:

#include<stdbool.h>

#include<stdlib.h>

#include<assert.h>

#include<time.h>

#include<string.h>

#include<stdio.h>

#include<ctype.h>

#include<sys/time.h>

#include<stddef.h>

#include<errno.h>

#include<math.h>

#include<sys/types.h>

#include<inttypes.h>

#include<signal.h>

void

expired(){

printf("Test");

}

intmain()

{

intrv=0;

longinterval=30;

timer_ttimerId=0;

constchar*data=NULL;

structsigeventsev={0};

structitimerspecits={.it_value.tv_sec=1,

.it_value.tv_nsec=0,

.it_interval.tv_sec=interval,

.it_interval.tv_nsec=0

};

sev.sigev_notify=SIGEV_THREAD;

sev.sigev_notify_function=&expired;

sev.sigev_value.sival_ptr=&data;

/*Createtimer*/

rv=timer_create(CLOCK_REALTIME,&sev,&timerId);

rv=timer_delete(timerId);

returnrv;

}


valgrind --leak-check=full --sim-hints=no-nptl-pthread-stackcache main 
==5693== Memcheck, a memory error detector ==5693== Copyright (C) 
2002-2022, and GNU GPL'd, by Julian Seward et al. ==5693== Using 
Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info ==5693== 
Command: wrapper ==5693== --5693:0:   sched WARNING: pthread stack cache 
cannot be disabled! ==5693== ==5693== HEAP SUMMARY: ==5693==     in use 
at exit: 272 bytes in 1 blocks ==5693==   total heap usage: 3 allocs, 2 
frees, 512 bytes allocated ==5693== ==5693== 272 bytes in 1 blocks are 
possibly lost in loss record 1 of 1 ==5693==    at 0x48475FF: calloc 
(vg_replace_malloc.c:1328) ==5693==    by 0x4012075: _dl_allocate_tls 
(in /lib64/ld-2.36.so) ==5693==    by 0x4916B49: 
pthread_create@@GLIBC_2.34 (in /lib64/libc-2.36.so) ==5693==    by 
0x492122D: __timer_start_helper_thread (in /lib64/libc-2.36.so) ==5693== 
    by 0x491AE66: __pthread_once_slow (in /lib64/libc-2.36.so) ==5693== 
    by 0x4920D3A: timer_create@@GLIBC_2.34 (in /lib64/libc-2.36.so) 
==5693==    by 0x4011E2: main (timer_delete.c:37) ==5693== ==5693== LEAK 
SUMMARY: ==5693==    definitely lost: 0 bytes in 0 blocks ==5693== 
    indirectly lost: 0 bytes in 0 blocks ==5693==      possibly lost: 
272 bytes in 1 blocks ==5693==    still reachable: 0 bytes in 0 blocks 
==5693==         suppressed: 0 bytes in 0 blocks ==5693== ==5693== For 
lists of detected and suppressed errors, rerun with: -s ==5693== ERROR 
SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

Domenico


Il 11/11/22 18:13, Paul Floyd ha scritto:
>
>
> On 11/11/22 17:47, Domenico Panella wrote:
>> Hi,
>>
>> I am getting a memory leak in my program about timer_delete function.
>>
>> According valgrind output,
>>
>> It seems that the timer_delete function doesn't release the memory.
>>
>> ==18483== HEAP SUMMARY:
>> ==18483==     in use at exit: 272 bytes in 1 blocks
>> ==18483==   total heap usage: 54 allocs, 53 frees, 9,354 bytes allocated
>> ==18483==
>> ==18483== 272 bytes in 1 blocks are possibly lost in loss record 1 of 1
>> ==18483==    at 0x48475FF: calloc (vg_replace_malloc.c:1328)
>> ==18483==    by 0x4012075: _dl_allocate_tls (in /lib64/ld-2.36.so)
>> ==18483==    by 0x491EB49: pthread_create@@GLIBC_2.34 (in 
>> /lib64/libc-2.36.so)
>> ==18483==    by 0x492922D: __timer_start_helper_thread (in 
>> /lib64/libc-2.36.so)
>> ==18483==    by 0x4922E66: __pthread_once_slow (in /lib64/libc-2.36.so)
>> ==18483==    by 0x4928D3A: timer_create@@GLIBC_2.34 (in 
>> /lib64/libc-2.36.so)
>> ==18483==    by 0x401711: main (main.c:224)
>> ==18483==
>> ==18483== LEAK SUMMARY:
>> ==18483==    definitely lost: 0 bytes in 0 blocks
>> ==18483==    indirectly lost: 0 bytes in 0 blocks
>> ==18483==      possibly lost: 272 bytes in 1 blocks
>> ==18483==    still reachable: 0 bytes in 0 blocks
>> ==18483==         suppressed: 0 bytes in 0 blocks
>> ==18483==
>> ==18483== For lists of detected and suppressed errors, rerun with: -s
>> ==18483== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
>>
>> What do i wrong?
>
> Which OS and CPU?
>
> Is this repeatable?
>
> It's possible that this is some memory that ought to be freed by the 
> glibc freeres function.
>
> Can you also post a small examp,e that reproduces the issue?
>
> A+
> Paul
>
>
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Timer delete

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

On Fri, 2022-11-11 at 18:13 +0100, Paul Floyd wrote:
> 
> On 11/11/22 17:47, Domenico Panella wrote:
> > Hi,
> > 
> > I am getting a memory leak in my program about timer_delete function.
> > 
> > According valgrind output,
> > 
> > It seems that the timer_delete function doesn't release the memory.
> > 
> > ==18483== HEAP SUMMARY:
> > ==18483==     in use at exit: 272 bytes in 1 blocks
> > ==18483==   total heap usage: 54 allocs, 53 frees, 9,354 bytes allocated
> > ==18483==
> > ==18483== 272 bytes in 1 blocks are possibly lost in loss record 1 of 1
> > ==18483==    at 0x48475FF: calloc (vg_replace_malloc.c:1328)
> > ==18483==    by 0x4012075: _dl_allocate_tls (in /lib64/ld-2.36.so)
> > ==18483==    by 0x491EB49: pthread_create@@GLIBC_2.34 (in 
> > /lib64/libc-2.36.so)
> > ==18483==    by 0x492922D: __timer_start_helper_thread (in 
> > /lib64/libc-2.36.so)
> > ==18483==    by 0x4922E66: __pthread_once_slow (in /lib64/libc-2.36.so)
> > ==18483==    by 0x4928D3A: timer_create@@GLIBC_2.34 (in 
> > /lib64/libc-2.36.so)
> > ==18483==    by 0x401711: main (main.c:224)
> > ==18483==
> > ==18483== LEAK SUMMARY:
> > ==18483==    definitely lost: 0 bytes in 0 blocks
> > ==18483==    indirectly lost: 0 bytes in 0 blocks
> > ==18483==      possibly lost: 272 bytes in 1 blocks
> > ==18483==    still reachable: 0 bytes in 0 blocks
> > ==18483==         suppressed: 0 bytes in 0 blocks
> > ==18483==
> > ==18483== For lists of detected and suppressed errors, rerun with: -s
> > ==18483== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
> > 
> > What do i wrong?
> 
> Which OS and CPU?
> 
> Is this repeatable?
> 
> It's possible that this is some memory that ought to be freed by the 
> glibc freeres function.
Possibly --sim-hints=no-nptl-pthread-stackcache might help (if I re-read the manual entry
for this sim-hint).

Philippe

Re: [Valgrind-users] Timer delete

[Paul F. <pj...@wa...>]

On 11/11/22 17:47, Domenico Panella wrote:
> Hi,
> 
> I am getting a memory leak in my program about timer_delete function.
> 
> According valgrind output,
> 
> It seems that the timer_delete function doesn't release the memory.
> 
> ==18483== HEAP SUMMARY:
> ==18483==     in use at exit: 272 bytes in 1 blocks
> ==18483==   total heap usage: 54 allocs, 53 frees, 9,354 bytes allocated
> ==18483==
> ==18483== 272 bytes in 1 blocks are possibly lost in loss record 1 of 1
> ==18483==    at 0x48475FF: calloc (vg_replace_malloc.c:1328)
> ==18483==    by 0x4012075: _dl_allocate_tls (in /lib64/ld-2.36.so)
> ==18483==    by 0x491EB49: pthread_create@@GLIBC_2.34 (in 
> /lib64/libc-2.36.so)
> ==18483==    by 0x492922D: __timer_start_helper_thread (in 
> /lib64/libc-2.36.so)
> ==18483==    by 0x4922E66: __pthread_once_slow (in /lib64/libc-2.36.so)
> ==18483==    by 0x4928D3A: timer_create@@GLIBC_2.34 (in 
> /lib64/libc-2.36.so)
> ==18483==    by 0x401711: main (main.c:224)
> ==18483==
> ==18483== LEAK SUMMARY:
> ==18483==    definitely lost: 0 bytes in 0 blocks
> ==18483==    indirectly lost: 0 bytes in 0 blocks
> ==18483==      possibly lost: 272 bytes in 1 blocks
> ==18483==    still reachable: 0 bytes in 0 blocks
> ==18483==         suppressed: 0 bytes in 0 blocks
> ==18483==
> ==18483== For lists of detected and suppressed errors, rerun with: -s
> ==18483== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
> 
> What do i wrong?

Which OS and CPU?

Is this repeatable?

It's possible that this is some memory that ought to be freed by the 
glibc freeres function.

Can you also post a small examp,e that reproduces the issue?

A+
Paul

[Valgrind-users] Timer delete

[Domenico P. <pan...@gm...>]

Hi,

I am getting a memory leak in my program about timer_delete function.

According valgrind output,

It seems that the timer_delete function doesn't release the memory.

==18483== HEAP SUMMARY:
==18483==     in use at exit: 272 bytes in 1 blocks
==18483==   total heap usage: 54 allocs, 53 frees, 9,354 bytes allocated
==18483==
==18483== 272 bytes in 1 blocks are possibly lost in loss record 1 of 1
==18483==    at 0x48475FF: calloc (vg_replace_malloc.c:1328)
==18483==    by 0x4012075: _dl_allocate_tls (in /lib64/ld-2.36.so)
==18483==    by 0x491EB49: pthread_create@@GLIBC_2.34 (in 
/lib64/libc-2.36.so)
==18483==    by 0x492922D: __timer_start_helper_thread (in 
/lib64/libc-2.36.so)
==18483==    by 0x4922E66: __pthread_once_slow (in /lib64/libc-2.36.so)
==18483==    by 0x4928D3A: timer_create@@GLIBC_2.34 (in 
/lib64/libc-2.36.so)
==18483==    by 0x401711: main (main.c:224)
==18483==
==18483== LEAK SUMMARY:
==18483==    definitely lost: 0 bytes in 0 blocks
==18483==    indirectly lost: 0 bytes in 0 blocks
==18483==      possibly lost: 272 bytes in 1 blocks
==18483==    still reachable: 0 bytes in 0 blocks
==18483==         suppressed: 0 bytes in 0 blocks
==18483==
==18483== For lists of detected and suppressed errors, rerun with: -s
==18483== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

What do i wrong?

Thanks

Re: [Valgrind-users] Valgrind-3.20.0.RC1 is available for testing

[Mathieu M. <ma...@de...>]

Hi Mark !

On Mon, Oct 24, 2022 at 10:01 PM Mark Wielaard <ma...@kl...> wrote:
>
> Hi Mathieu,
>
> On Fri, Oct 21, 2022 at 08:20:01AM +0200, Mathieu Malaterre wrote:
> > Could someone apply the following patch:
> >
> > sed -i -e 's/cortex-a8/generic-armv7-a/g' Makefile.all.am
> >
> > ref:
> > https://bugs.kde.org/show_bug.cgi?id=456200
>
> Sorry this didn't make the release. I would have to retest the build
> on a arm machine without neon and I didn't immediately have one. But
> this change is probably correct if we want to make valgrind work on
> systems that don't have neon. Given that Debian uses this, they
> probably support such arm machines.

Just FYI, this patch is in use in Debian/valgrind package since July
2022 (armhf arch).

Re: [Valgrind-users] Valgrind-3.20.0.RC1 is available for testing

[Mark W. <ma...@kl...>]

Hi Mathieu,

On Fri, Oct 21, 2022 at 08:20:01AM +0200, Mathieu Malaterre wrote:
> Could someone apply the following patch:
> 
> sed -i -e 's/cortex-a8/generic-armv7-a/g' Makefile.all.am
> 
> ref:
> https://bugs.kde.org/show_bug.cgi?id=456200

Sorry this didn't make the release. I would have to retest the build
on a arm machine without neon and I didn't immediately have one. But
this change is probably correct if we want to make valgrind work on
systems that don't have neon. Given that Debian uses this, they
probably support such arm machines.

Cheers,

Mark

[Valgrind-users] Valgrind-3.20.0 is available

[Mark W. <ma...@kl...>]

We are pleased to announce a new release of Valgrind, version 3.20.0,
available from https://valgrind.org/downloads/current.html.

See the release notes below for details of changes.

Our thanks to all those who contribute to Valgrind's development.  This
release represents a great deal of time, energy and effort on the part
of many people.

Happy and productive debugging and profiling,

-- The Valgrind Developers

~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This release supports X86/Linux, AMD64/Linux, ARM32/Linux, ARM64/Linux,
PPC32/Linux, PPC64BE/Linux, PPC64LE/Linux, S390X/Linux, MIPS32/Linux,
MIPS64/Linux, ARM/Android, ARM64/Android, MIPS32/Android, X86/Android,
X86/Solaris, AMD64/Solaris, AMD64/MacOSX 10.12, X86/FreeBSD and
AMD64/FreeBSD.  There is also preliminary support for X86/macOS 10.13,
AMD64/macOS 10.13 and nanoMIPS/Linux.

* ==================== CORE CHANGES ===================

* The option "--vgdb-stop-at=event1,event2,..." accepts the new value abexit.
  This indicates to invoke gdbserver when your program exits abnormally
  (i.e. with a non zero exit code).
* Fix Rust v0 name demangling.
* The Linux rseq syscall is now implemented as (silently) returning ENOSYS.
* Add FreeBSD syscall wrappers for __specialfd and __realpathat.
* Remove FreeBSD dependencies on COMPAT10, which fixes compatibility with
  HardenedBSD
* The option --enable-debuginfod=<no|yes> [default: yes] has been added on
  Linux.
* More DWARF5 support as generated by clang14.

* ==================== FIXED BUGS ====================

The following bugs have been fixed or resolved.  Note that "n-i-bz"
stands for "not in bugzilla" -- that is, a bug that was reported to us
but never got a bugzilla entry.  We encourage you to file bugs in
bugzilla (https://bugs.kde.org/enter_bug.cgi?product=valgrind) rather
than mailing the developers (or mailing lists) directly -- bugs that
are not entered into bugzilla tend to get forgotten about or ignored.

131186  writev reports error in (vector[...])
434764  iconv_open causes ld.so v2.28+ to use optimised strncmp
446754  Improve error codes from alloc functions under memcheck
452274  memcheck crashes with Assertion 'sci->status.what == SsIdle' failed
452779  Valgrind fails to build on FreeBSD 13.0 with llvm-devel (15.0.0)
453055  shared_timed_mutex drd test fails with "Lock shared failed" message
453602  Missing command line option to enable/disable debuginfod
452802  Handle lld 9+ split RW PT_LOAD segments correctly
454040  s390x: False-positive memcheck:cond in memmem on arch13 systems 
456171  [PATCH] FreeBSD: Don't record address errors when accessing the 'kern.ps_strings' sysctl struct
n-i-bz  Implement vgdb invoker on FreeBSD
458845  PowerPC: The L field for the dcbf and sync instruction should be
        3 bits in ISA 3.1.
458915  Remove register cache to fix 458915 gdbserver causes wrong syscall return
459031  Documentation on --error-exitcode incomplete
459477  XERROR messages lacks ending '\n' in vgdb

To see details of a given bug, visit
  https://bugs.kde.org/show_bug.cgi?id=XXXXXX
where XXXXXX is the bug number as listed above.

(3.20.0.RC1: 20 Oct 2022)

Re: [Valgrind-users] [Valgrind-developers] Valgrind-3.20.0.RC1 is available for testing

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

On Sun, 2022-10-23 at 00:11 +0200, Mark Wielaard wrote:
> Hi Philippe,
> 
> On Sat, Oct 22, 2022 at 02:58:28PM +0200, Philippe Waroquiers wrote:
> > I have started running valgrind on valgrind (outer/inner setup).
> > Results should be available tomorrow evening or so ...
> > For the first few tests, seems ok.
> > 
> > Just one strange thing:
> > The outer valgrind crashes on the below test (while the native run of this test is ok).
> > (this is on gcc farm gcc186).
> > 
> > Not very clear to me how the ld-linux.so.2 redirection could be ok in native mode,
> > but would not be ok when the same valgrind runs as an outer.
> > In any case, this is not blocking.
> > 
> > More complete results will follow ...
> 
> Thanks. I have no theory for the outer valgrind crash. But it doesn't
> seem blocking indeed. I am also still running some tests. Please let
> me know of further results. And do the actual release on Monday
> (unless some regression blocker turns up).
> 
> Cheers,
> 
> Mark
> 

For the crash of the outer valgrind: there is in fact some debug info really
missing on gcc186 (also for the inner) for the 32 bits version.

I have looked at the results of this outer/inner setup and found nothing that
seems problematic.

Note that analysis the outer logs is always painful, as the outer reports as "bugs"
the fact the inner uses e.g. some invalid memory because the guest
program run by the inner is designed to test the usage of such invalid memory.

Thanks
Philippe

Re: [Valgrind-users] [Valgrind-developers] Valgrind-3.20.0.RC1 is available for testing

[Mark W. <ma...@kl...>]

Hi Philippe,

On Sat, Oct 22, 2022 at 02:58:28PM +0200, Philippe Waroquiers wrote:
> I have started running valgrind on valgrind (outer/inner setup).
> Results should be available tomorrow evening or so ...
> For the first few tests, seems ok.
> 
> Just one strange thing:
> The outer valgrind crashes on the below test (while the native run of this test is ok).
> (this is on gcc farm gcc186).
> 
> Not very clear to me how the ld-linux.so.2 redirection could be ok in native mode,
> but would not be ok when the same valgrind runs as an outer.
> In any case, this is not blocking.
> 
> More complete results will follow ...

Thanks. I have no theory for the outer valgrind crash. But it doesn't
seem blocking indeed. I am also still running some tests. Please let
me know of further results. And do the actual release on Monday
(unless some regression blocker turns up).

Cheers,

Mark

Re: [Valgrind-users] [Valgrind-developers] Valgrind-3.20.0.RC1 is available for testing

[Mark W. <ma...@kl...>]

Hi,

On Thu, Oct 20, 2022 at 01:25:44PM -0700, Carl Love wrote:
> The only issue noted, as discussed on #valgrind-dev channel, is the
> addition of four post errors for the 3.20RC tree on all of the Power
> platforms.  Specifically:
> 
> cachegrind/tests/ann1                    (post)
> cachegrind/tests/ann2                    (post)
> callgrind/tests/ann1                     (post)
> callgrind/tests/ann2                     (post)
> 
> The output from  cachegrind/tests/ann1.post.diff is:
> 
> --- ann1.post.exp	2021-01-21 09:09:33.000000000 -0600
> +++ ann1.post.out	2022-10-20 14:07:33.272141328 -0500
> @@ -33,6 +33,13 @@
>  --------------------------------------------------------------------
> -----------
> -
>  -- Auto-annotated source: a.c
>  --------------------------------------------------------------------
> -----------
> -
> +@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> @@@@@@@@@
> +@@ WARNING @@ WARNING @@ WARNING @@ WARNING @@ WARNING @@ WARNING @@
> WARNING @@
> +@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> @@@@@@@@@
> +@ Source file 'a.c' is more recent than input file 'cgout-test'.
> +@ Annotations may not be correct.
> +@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> @@@@@@@@@
> +
>  Ir        I1mr ILmr 
>  
>          2    0    0  int main(void) {
> 
> As discussed on the #valgrind-dev channel, this appears to be a
> timestamp issue.  Doing a touch * in directory cachegrind/tests seems
> to fix all four post errors.
> 
> No other issues were noted.  I would vote to do the touch * command and
> go ahead with the release.

I added the touch to the testcases as attached. That makes sure the
cgout-test file is always newer.

Cheers,

Mark

Re: [Valgrind-users] [Valgrind-developers] Valgrind-3.20.0.RC1 is available for testing

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

I have started running valgrind on valgrind (outer/inner setup).
Results should be available tomorrow evening or so ...
For the first few tests, seems ok.

Just one strange thing:
The outer valgrind crashes on the below test (while the native run of this test is ok).
(this is on gcc farm gcc186).

Not very clear to me how the ld-linux.so.2 redirection could be ok in native mode,
but would not be ok when the same valgrind runs as an outer.
In any case, this is not blocking.

More complete results will follow ...

Philippe

cachegrind/tests/x86/fpu-28-108.outer.log:10:valgrind:  Fatal error at startup: a function redirection
cachegrind/tests/x86/fpu-28-108.outer.log:11:valgrind:  which is mandatory for this platform-tool combination
cachegrind/tests/x86/fpu-28-108.outer.log:12:valgrind:  cannot be set up.  Details of the redirection are:
cachegrind/tests/x86/fpu-28-108.outer.log:13:valgrind:  
cachegrind/tests/x86/fpu-28-108.outer.log:14:valgrind:  A must-be-redirected function
cachegrind/tests/x86/fpu-28-108.outer.log:15:valgrind:  whose name matches the pattern:      strlen
cachegrind/tests/x86/fpu-28-108.outer.log:16:valgrind:  in an object with soname matching:   ld-linux.so.2
cachegrind/tests/x86/fpu-28-108.outer.log:17:valgrind:  was not found whilst processing
cachegrind/tests/x86/fpu-28-108.outer.log:18:valgrind:  symbols from the object with soname: ld-linux.so.2
cachegrind/tests/x86/fpu-28-108.outer.log:19:valgrind:  
cachegrind/tests/x86/fpu-28-108.outer.log:20:valgrind:  Possible fixes: (1, short term): install glibc's debuginfo
cachegrind/tests/x86/fpu-28-108.outer.log:21:valgrind:  package on this machine.  (2, longer term): ask the packagers
cachegrind/tests/x86/fpu-28-108.outer.log:22:valgrind:  for your Linux distribution to please in future ship a non-
cachegrind/tests/x86/fpu-28-108.outer.log:23:valgrind:  stripped ld.so (or whatever the dynamic linker .so is called)
cachegrind/tests/x86/fpu-28-108.outer.log:24:valgrind:  that exports the above-named function using the standard
cachegrind/tests/x86/fpu-28-108.outer.log:25:valgrind:  calling conventions for this platform.  The package you need
cachegrind/tests/x86/fpu-28-108.outer.log:26:valgrind:  to install for fix (1) is called
cachegrind/tests/x86/fpu-28-108.outer.log:27:valgrind:  
cachegrind/tests/x86/fpu-28-108.outer.log:28:valgrind:    On Debian, Ubuntu:                 libc6-dbg
cachegrind/tests/x86/fpu-28-108.outer.log:29:valgrind:    On SuSE, openSuSE, Fedora, RHEL:   glibc-debuginfo
cachegrind/tests/x86/fpu-28-108.outer.log:30:valgrind:  
cachegrind/tests/x86/fpu-28-108.outer.log:31:valgrind:  Note that if you are debugging a 32 bit process on a
cachegrind/tests/x86/fpu-28-108.outer.log:32:valgrind:  64 bit system, you will need a corresponding 32 bit debuginfo
cachegrind/tests/x86/fpu-28-108.outer.log:33:valgrind:  package (e.g. libc6-dbg:i386).
cachegrind/tests/x86/fpu-28-108.outer.log:34:valgrind:  
cachegrind/tests/x86/fpu-28-108.outer.log:35:valgrind:  Cannot continue -- exiting now.  Sorry.

On Thu, 2022-10-20 at 01:52 +0200, Mark Wielaard wrote:
> Greetings.
> 
> A first release candidate for 3.20.0 is available at
> https://sourceware.org/pub/valgrind/valgrind-3.20.0.RC1.tar.bz2
> (md5 = 981b9276536843090700c1268549186e)
> 
> Please give it a try on platforms that are important for you.  If no
> serious issues are reported, the 3.20.0 final release will happen on
> 22 October.
> 
> 
> 
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers

Re: [Valgrind-users] Valgrind-3.20.0.RC1 is available for testing

[Mathieu M. <ma...@de...>]

Hi there,

On Thu, Oct 20, 2022 at 9:16 PM Paul Floyd <pj...@wa...> wrote:
>
>
>
> On 10/20/22 01:52, Mark Wielaard wrote:
> > Greetings.
> >
> > A first release candidate for 3.20.0 is available at
> > https://sourceware.org/pub/valgrind/valgrind-3.20.0.RC1.tar.bz2
> > (md5 = 981b9276536843090700c1268549186e)
> >
> > Please give it a try on platforms that are important for you.  If no
> > serious issues are reported, the 3.20.0 final release will happen on
> > 22 October.
>

Could someone apply the following patch:

sed -i -e 's/cortex-a8/generic-armv7-a/g' Makefile.all.am

ref:
https://bugs.kde.org/show_bug.cgi?id=456200

Thanks & Regards

Re: [Valgrind-users] Valgrind-3.20.0.RC1 is available for testing

[Paul F. <pj...@wa...>]

On 10/20/22 01:52, Mark Wielaard wrote:
> Greetings.
> 
> A first release candidate for 3.20.0 is available at
> https://sourceware.org/pub/valgrind/valgrind-3.20.0.RC1.tar.bz2
> (md5 = 981b9276536843090700c1268549186e)
> 
> Please give it a try on platforms that are important for you.  If no
> serious issues are reported, the 3.20.0 final release will happen on
> 22 October.

Hi

And finally, macOS. On my old macbook (10.7) there was a build error 
that I corrected last night.

Otherwise no real change since 3.19
- two regtests fail to build
- 236 regtest failures out of 671 with 1 hang

A+
Paul

Re: [Valgrind-users] Valgrind-3.20.0.RC1 is available for testing

[Paul F. <pj...@wa...>]

On 10/20/22 01:52, Mark Wielaard wrote:
> Greetings.
> 
> A first release candidate for 3.20.0 is available at
> https://sourceware.org/pub/valgrind/valgrind-3.20.0.RC1.tar.bz2
> (md5 = 981b9276536843090700c1268549186e)
> 
> Please give it a try on platforms that are important for you.  If no
> serious issues are reported, the 3.20.0 final release will happen on
> 22 October.


FreeBSD 13.1

LGTM

One slight oddity.

I had a couple of failures (the ann1 and ann2 callgrind and cachegrind 
tests) after doing

autogen && configure && make && make check && make regtest


That seems to be because the timestamp of cgout-test is older than a.c 
causing


+@@ WARNING @@ WARNING @@ WARNING @@ WARNING @@ WARNING @@ WARNING @@ 
WARNING @@
+@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
+@ Source file 'a.c' is more recent than input file 
'../../cachegrind/tests/cgout-test'.
+@ Annotations may not be correct.
+@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
+


A+
Paul

[Valgrind-users] Valgrind-3.20.0.RC1 is available for testing

[Mark W. <ma...@kl...>]

Greetings.

A first release candidate for 3.20.0 is available at
https://sourceware.org/pub/valgrind/valgrind-3.20.0.RC1.tar.bz2
(md5 = 981b9276536843090700c1268549186e)

Please give it a try on platforms that are important for you.  If no
serious issues are reported, the 3.20.0 final release will happen on
22 October.