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 (_state->mainloop, g_main_loop_unref);
g_clear_pointer (_state->ctx, g_main_context_unref);
which is equivalent, but simplifies things a bit.
Philip
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Correct way to deallocate an unix signal source
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
To: Enrico Mioso
Cc: gtk-app-devel-list@gnome.org
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 (_state->mainloop, g_main_loop_unref);
g_clear_pointer (_state->ctx, g_main_context_unref);
which is equivalent, but simplifies things a bit.
Philip
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Correct way to deallocate an unix signal source
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
To: Enrico Mioso , gtk-app-devel-list@gnome.org
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
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
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 gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Correct way to deallocate an unix signal source
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 gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
