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 <withnall endlessm com>
To: Enrico Mioso <mrkiko rs gmail com>, 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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]