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