After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 759580 - Memory leak in UNIX signal handler
Memory leak in UNIX signal handler
Status: RESOLVED DUPLICATE of bug 627423
Product: glib
Classification: Platform
Component: mainloop
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2015-12-17 10:11 UTC by Roman Savchenko
Modified: 2017-09-12 17:42 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Roman Savchenko 2015-12-17 10:11:46 UTC
==3865== Memcheck, a memory error detector
==3865== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==3865== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==3865== Command: build/test-c++
==3865== 
==3865== 
==3865== HEAP SUMMARY:
==3865==     in use at exit: 4,076 bytes in 40 blocks
==3865==   total heap usage: 50 allocs, 10 frees, 4,362 bytes allocated
==3865== 
==3865== 272 bytes in 1 blocks are possibly lost in loss record 39 of 40
==3865==    at 0x4C2CC70: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3865==    by 0x4012E54: allocate_dtv (dl-tls.c:296)
==3865==    by 0x4012E54: _dl_allocate_tls (dl-tls.c:460)
==3865==    by 0x574ADA0: allocate_stack (allocatestack.c:589)
==3865==    by 0x574ADA0: pthread_create@@GLIBC_2.2.5 (pthread_create.c:500)
==3865==    by 0x4EC1E61: g_system_thread_new (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==3865==    by 0x4EA51DE: g_thread_new_internal (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==3865==    by 0x4EA528A: g_thread_new (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==3865==    by 0x4E80EB1: g_get_worker_context (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==3865==    by 0x4E80EFF: ref_unix_signal_handler_unlocked (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==3865==    by 0x4E80F98: _g_main_create_unix_signal_watch (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==3865==    by 0x4EC1409: g_unix_signal_add_full (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==3865==    by 0x400971: main (main.cpp:14)
==3865== 
==3865== LEAK SUMMARY:
==3865==    definitely lost: 0 bytes in 0 blocks
==3865==    indirectly lost: 0 bytes in 0 blocks
==3865==      possibly lost: 272 bytes in 1 blocks
==3865==    still reachable: 3,804 bytes in 39 blocks
==3865==         suppressed: 0 bytes in 0 blocks
==3865== Reachable blocks (those to which a pointer was found) are not shown.
==3865== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==3865== 
==3865== For counts of detected and suppressed errors, rerun with: -v
==3865== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)


Reason: 

GMainContext *
g_get_worker_context (void)
{
  static gsize initialised;

  if (g_once_init_enter (&initialised))
    {
      /* mask all signals in the worker thread */
#ifdef G_OS_UNIX
      sigset_t prev_mask;
      sigset_t all;

      sigfillset (&all);
      pthread_sigmask (SIG_SETMASK, &all, &prev_mask);
#endif
      glib_worker_context = g_main_context_new ();
      g_thread_new ("gmain", glib_worker_main, NULL); // <<<---- this thread is not referenced
#ifdef G_OS_UNIX
      pthread_sigmask (SIG_SETMASK, &prev_mask, NULL);
#endif
      g_once_init_leave (&initialised, TRUE);
    }

  return glib_worker_context;
}
Comment 1 Colin Walters 2015-12-17 15:15:18 UTC
The worker context is shared state that at present (I believe) we don't have a way for applications to clean up.

There's an epic bug on adding more hooks/infrastructure to GLib for this that I am too lazy to find right now.

Basically for now, add this to your suppressions file.
Comment 2 Daniel Boles 2017-09-12 17:20:02 UTC
(In reply to Colin Walters from comment #1)
> There's an epic bug on adding more hooks/infrastructure to GLib for this
> that I am too lazy to find right now.

Bug 627423, most likely

*** This bug has been marked as a duplicate of bug 627423 ***
Comment 3 Philip Withnall 2017-09-12 17:42:34 UTC
(In reply to Colin Walters from comment #1)
> Basically for now, add this to your suppressions file.

Or, if it’s still a problem, please re-open this bug with a patch for glib.supp to add it to the suppressions file which we distribute with GLib.