public inbox for libc-help@sourceware.org
 help / color / mirror / Atom feed
* glibc mq_notify memory leak report
@ 2023-01-09 15:13 Parthiban
  2023-01-09 17:11 ` Florian Weimer
  0 siblings, 1 reply; 2+ messages in thread
From: Parthiban @ 2023-01-09 15:13 UTC (permalink / raw)
  To: libc-help; +Cc: Parthiban

Dear All,

I have the following code snippet and `mq_close`, `mq_unlink` is called in exit path.
But with valgrind, I have the summary about possibly lost.

How to gracefully remove the notification during exit path?

From man mq_close,
If  the  calling process has attached a notification request (see (mq_notify(3)) to this
message queue via mqdes, then this request is removed

Valgrind summary:
```
==381555== HEAP SUMMARY:
==381555==     in use at exit: 5,716 bytes in 13 blocks                                                                                                       
==381555==   total heap usage: 39,786 allocs, 39,773 frees, 267,728,707 bytes allocated
==381555==                                                                                                                                                    
==381555== Thread 1:
==381555== 304 bytes in 1 blocks are possibly lost in loss record 3 of 5      
==381555==    at 0x4846A73: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==381555==    by 0x4011282: calloc (rtld-malloc.h:44)                                                                                                         
==381555==    by 0x4011282: allocate_dtv (dl-tls.c:375)                       
==381555==    by 0x4011C91: _dl_allocate_tls (dl-tls.c:634)
==381555==    by 0x4F244DF: allocate_stack (allocatestack.c:423)
==381555==    by 0x4F244DF: pthread_create@@GLIBC_2.34 (pthread_create.c:650)
==381555==    by 0x4F2E70E: init_mq_netlink (mq_notify.c:183)                
==381555==    by 0x4F28886: __pthread_once_slow (pthread_once.c:116)         
==381555==    by 0x4F2E802: __mq_notify (mq_notify.c:219)           
==381555==    by 0x4F2E802: mq_notify@@GLIBC_2.34 (mq_notify.c:203) 
==381555==    by 0x10C3D1: mq_notify_init (upstream.c:201)         
==381555==    by 0x10E306: mq_handler_init (upstream.c:1019)       
==381555==    by 0x10EDB6: upstream_init_async (upstream.c:1244)
==381555==    by 0x10BFD6: main (main.c:83)                     
==381555==                                                                     
==381555== LEAK SUMMARY:                                                      
==381555==    definitely lost: 0 bytes in 0 blocks                            
==381555==    indirectly lost: 0 bytes in 0 blocks                            
==381555==      possibly lost: 304 bytes in 1 blocks
==381555==    still reachable: 5,412 bytes in 12 blocks
==381555==         suppressed: 0 bytes in 0 blocks     
```

```
static int mq_notify_init(void)
{
        int ret;
        struct sigevent sev;

        sev.sigev_notify = SIGEV_THREAD;
        sev.sigev_notify_function = mq_handler;
        sev.sigev_notify_attributes = NULL;
        sev.sigev_value.sival_ptr = &mq;

        ret = mq_notify(mq, &sev);
        if (ret != 0)
                error("MQ notify register failed: %s", strerror(errno));

        return ret;
}
```
-- 
Thanks,
Parthiban N
https://www.linumiz.com
Berlin, Germany

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: glibc mq_notify memory leak report
  2023-01-09 15:13 glibc mq_notify memory leak report Parthiban
@ 2023-01-09 17:11 ` Florian Weimer
  0 siblings, 0 replies; 2+ messages in thread
From: Florian Weimer @ 2023-01-09 17:11 UTC (permalink / raw)
  To: Parthiban; +Cc: libc-help

* > Dear All,
>
> I have the following code snippet and `mq_close`, `mq_unlink` is
> called in exit path.  But with valgrind, I have the summary about
> possibly lost.
>
> How to gracefully remove the notification during exit path?

I think this is the same issue that was reported here for timer_create
(which also has a helper thread):

  libc timer_create with option SIGEV_THREAD system call having memory
  leaks after timer_delete system call
  <https://sourceware.org/bugzilla/show_bug.cgi?id=29705>

I don't think there is a good way to fix this.  It's not an unbounded
leak, so it does not impact the application while it runs.

Thanks,
Florian


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2023-01-09 17:11 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-01-09 15:13 glibc mq_notify memory leak report Parthiban
2023-01-09 17:11 ` Florian Weimer

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).