Correct way to deallocate an unix signal source

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Correct way to deallocate an unix signal source

Gtk+ - Apps Dev mailing list
Hello all,

and thank you for your great work in the GLib library, and the entire GTK ecosystem! :)

I am facing an issue, where it seems I am not deallocating correctly an UNIX signal source. I use
my_state->unix_signals_src = g_unix_signal_source_new(SIGINT);
g_source_set_callback(my_state->unix_signals_src, my_unix_signals_cb, my_state, NULL);
my_state->unix_signals_src_tag = g_source_attach(my_state->unix_signals_src, my_state->ctx);
g_source_unref(my_state->unix_signals_src);

then, on the exit path of my program, I have something like:

if (!my_state->sigint_received)
   g_source_destroy(my_state->unix_signals_src);

my_state->unix_signals_src_tag = 0;

... all goes as expected on the surface, but, should my program exit via ctrl+c or not, valgrind gives me the following complains:

==18189== Memcheck, a memory error detector
==18189== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==18189== Using Valgrind-3.15.0.GIT and LibVEX; rerun with -h for copyright info
==18189== Command: ./agh
==18189== Parent PID: 18184
==18189==
==18189==
==18189== HEAP SUMMARY:
==18189==     in use at exit: 21,966 bytes in 264 blocks
==18189==   total heap usage: 60,785 allocs, 60,521 frees, 23,790,536 bytes allocated
==18189==
==18189== 168 bytes in 1 blocks are possibly lost in loss record 246 of 256
==18189==    at 0x48372B2: calloc (vg_replace_malloc.c:762)
==18189==    by 0x4012386: allocate_dtv (in /usr/lib/ld-2.28.so)
==18189==    by 0x4012D63: _dl_allocate_tls (in /usr/lib/ld-2.28.so)
==18189==    by 0x4E6A58D: pthread_create@@GLIBC_2.1 (in /usr/lib/libpthread-2.28.so)
==18189==    by 0x48D697A: UnknownInlinedFun (gthread-posix.c:1188)
==18189==    by 0x48D697A: g_thread_new_internal (gthread.c:892)
==18189==    by 0x48D6B01: g_thread_new (gthread.c:848)
==18189==    by 0x48F77A2: g_get_worker_context (gmain.c:5895)
==18189==    by 0x48F7807: ref_unix_signal_handler_unlocked.lto_priv.64 (gmain.c:5231)
==18189==    by 0x48BDBDB: UnknownInlinedFun (gmain.c:5339)
==18189==    by 0x48BDBDB: g_unix_signal_source_new (glib-unix.c:222)
==18189==    by 0x10D515: agh_sources_setup (agh.c:224)
==18189==    by 0x10D30F: main (agh.c:159)
==18189==
==18189== LEAK SUMMARY:
==18189==    definitely lost: 0 bytes in 0 blocks
==18189==    indirectly lost: 0 bytes in 0 blocks
==18189==      possibly lost: 168 bytes in 1 blocks
==18189==    still reachable: 11,846 bytes in 35 blocks
==18189==                       of which reachable via heuristic:
==18189==                         newarray           : 832 bytes in 16 blocks
==18189==         suppressed: 9,952 bytes in 228 blocks
==18189== Reachable blocks (those to which a pointer was found) are not shown.
==18189== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==18189==
==18189== For lists of detected and suppressed errors, rerun with: -s
==18189== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 18 from 18)


This output can be obtained even using the glib.supp file as found in glib repository.
Looking at the file specified by valgrind, glib-unix.c, line 222, I can see:
return _g_main_create_unix_signal_watch (signum);

How can I avoid this problem, finalizing that watch?
Or, what do you recommend me to try?
I plan to try changing the way i intercept signals tomorrow, but I would apreciate your recommendations a lot guys.

Thank you very very much:

P.S.: please, keep me in CC, as I am not part of the list.
Enrico

_______________________________________________
gtk-app-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Correct way to deallocate an unix signal source

Philip Withnall
Hi,

On Thu, 2019-03-14 at 00:09 +0100, Enrico Mioso wrote:

> I am facing an issue, where it seems I am not deallocating correctly
> an UNIX signal source. I use
> my_state->unix_signals_src = g_unix_signal_source_new(SIGINT);
> g_source_set_callback(my_state->unix_signals_src, my_unix_signals_cb,
> my_state, NULL);
> my_state->unix_signals_src_tag = g_source_attach(my_state-
> >unix_signals_src, my_state->ctx);
> g_source_unref(my_state->unix_signals_src);
>
> then, on the exit path of my program, I have something like:
>
> if (!my_state->sigint_received)
>    g_source_destroy(my_state->unix_signals_src);
>
> my_state->unix_signals_src_tag = 0;
This code seems fine to me, within the context you’ve provided. I
assume you’re also correctly unreffing the GMainContext at the end of
your program.

> This output can be obtained even using the glib.supp file as found in
> glib repository.
> Looking at the file specified by valgrind, glib-unix.c, line 222, I
> can see:
> return _g_main_create_unix_signal_watch (signum);

That valgrind trace looks like an intentional one-time leak, since the
allocation is within pthread_create().

I’d be very happy to accept a patch to GLib to add this to glib.supp. ☺

Philip

_______________________________________________
gtk-app-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Correct way to deallocate an unix signal source

Gtk+ - Apps Dev mailing list
Dear Philip,

thank you very much for your answer and patience. I will send a patch soon! :)

Regarding the code, at exit I do the following:
if (my_state->mainloop) {
  g_main_loop_unref(my_state->mainloop);
  my_state->mainloop = NULL;
}

if (my_state->ctx) {
  g_main_context_unref(my_state->ctx);
  my_state->ctx = NULL;
}


Thank you to all reading this,

Enrico

On Mon, 18 Mar 2019, Philip Withnall wrote:

> Date: Mon, 18 Mar 2019 10:42:11
> From: Philip Withnall <[hidden email]>
> To: Enrico Mioso <[hidden email]>, [hidden email]
> Subject: Re: Correct way to deallocate an unix signal source
>
> Hi,
>
> On Thu, 2019-03-14 at 00:09 +0100, Enrico Mioso wrote:
>> I am facing an issue, where it seems I am not deallocating correctly
>> an UNIX signal source. I use
>> my_state->unix_signals_src = g_unix_signal_source_new(SIGINT);
>> g_source_set_callback(my_state->unix_signals_src, my_unix_signals_cb,
>> my_state, NULL);
>> my_state->unix_signals_src_tag = g_source_attach(my_state-
>>> unix_signals_src, my_state->ctx);
>> g_source_unref(my_state->unix_signals_src);
>>
>> then, on the exit path of my program, I have something like:
>>
>> if (!my_state->sigint_received)
>>    g_source_destroy(my_state->unix_signals_src);
>>
>> my_state->unix_signals_src_tag = 0;
>
> This code seems fine to me, within the context you’ve provided. I
> assume you’re also correctly unreffing the GMainContext at the end of
> your program.
>
>> This output can be obtained even using the glib.supp file as found in
>> glib repository.
>> Looking at the file specified by valgrind, glib-unix.c, line 222, I
>> can see:
>> return _g_main_create_unix_signal_watch (signum);
>
> That valgrind trace looks like an intentional one-time leak, since the
> allocation is within pthread_create().
>
> I’d be very happy to accept a patch to GLib to add this to glib.supp. ☺
>
> Philip
>
_______________________________________________
gtk-app-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Correct way to deallocate an unix signal source

Philip Withnall
On Mon, 2019-03-18 at 14:38 +0100, Enrico Mioso wrote:

> Regarding the code, at exit I do the following:
> if (my_state->mainloop) {
>   g_main_loop_unref(my_state->mainloop);
>   my_state->mainloop = NULL;
> }
>
> if (my_state->ctx) {
>   g_main_context_unref(my_state->ctx);
>   my_state->ctx = NULL;
> }
That looks fine. If you depend on GLib ≥ 2.34, you can instead do:

g_clear_pointer (&my_state->mainloop, g_main_loop_unref);
g_clear_pointer (&my_state->ctx, g_main_context_unref);

which is equivalent, but simplifies things a bit.

Philip

_______________________________________________
gtk-app-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Correct way to deallocate an unix signal source

Gtk+ - Apps Dev mailing list
That's great! Thanks! Yeah, I'll keep it on my mind. I currently choose to depend on GLib 2.58 to do something like:
g_source_set_callback(lctx->logwatcher, G_SOURCE_FUNC(agh_ubus_logstream_channel_io), lctx, NULL);

so there should be no issues in case.

Thank again!!
Enrico


On Mon, 18 Mar 2019, Philip Withnall wrote:

> Date: Mon, 18 Mar 2019 14:51:25
> From: Philip Withnall <[hidden email]>
> To: Enrico Mioso <[hidden email]>
> Cc: [hidden email]
> Subject: Re: Correct way to deallocate an unix signal source
>
> On Mon, 2019-03-18 at 14:38 +0100, Enrico Mioso wrote:
>> Regarding the code, at exit I do the following:
>> if (my_state->mainloop) {
>>   g_main_loop_unref(my_state->mainloop);
>>   my_state->mainloop = NULL;
>> }
>>
>> if (my_state->ctx) {
>>   g_main_context_unref(my_state->ctx);
>>   my_state->ctx = NULL;
>> }
>
> That looks fine. If you depend on GLib ≥ 2.34, you can instead do:
>
> g_clear_pointer (&my_state->mainloop, g_main_loop_unref);
> g_clear_pointer (&my_state->ctx, g_main_context_unref);
>
> which is equivalent, but simplifies things a bit.
>
> Philip
>
_______________________________________________
gtk-app-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list