Re: [Valgrind-users] Timer delete
[[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 [[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 Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Timer delete
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 [[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 Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Timer delete
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 #include #include #include #include #include #include #include #include #include #include #include #include #include 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= sev.sigev_value.sival_ptr= /*Createtimer*/ rv=timer_create(CLOCK_REALTIME,,); 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 Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Timer delete
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 ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Timer delete
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 Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
[Valgrind-users] Timer delete
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 ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users