Re: Need help in debugging glib crash
- Date: Tue, 26 May 2015 00:40:09 +0900
- From: Tristan Van Berkom <tristan@xxxxxxxxxxxxxxxx>
- Subject: Re: Need help in debugging glib crash
On Mon, 2015-05-25 at 16:42 +0300, Alexander Pyhalov wrote:
> On 05/25/2015 15:33, Alexander Pyhalov wrote:
> > Hello.
> > Here the program crashed.
> > So, we see that emit_in_idle() was called after entering to
> > g_file_monitor_dispose() function, which if I understand this correctly
> > lead to crash. Perhaps, some additional handling is necessary in
> > g_file_monitor_dispose() so that we don't try to emit signal to
> > "disposing" object ? Do you have some thoughts on how to debug further
> > and fix this issue?
> Now I'm looking on the following patch:
Since the introduction of GIO and async routines; occurrences where
an object fails to cancel one of it's ongoing operations in dispose()
have not been entirely uncommon.
The best would be to start with filing a bug in bugzilla and attaching
a test case which reproduces the crash.
Also, it's possible that the crash you're seeing might be reproducible
already with this existing test case.
> --- gfilemonitor.c 2015-05-25 16:15:05.066580976 +0300
> +++ glib-2.43.4/gio/gfilemonitor.c 2015-05-25 16:15:49.053863042 +0300
> @@ -442,7 +442,7 @@
> change->event_type = event_type;
> g_mutex_lock (&monitor->priv->mutex);
> - if (!priv->pending_file_change_source)
> + if (!priv->pending_file_change_source && !priv->cancelled)
> source = g_idle_source_new ();
> priv->pending_file_change_source = source;
> Does it make sense? The idea is to avoid calling emit_cb after
> g_file_monitor_dispose has already been called. I'm not sure if it's
> correct approach, as we can not be sure that g_file_monitor_dispose will
> work atomically.
gtk-devel-list mailing list