Re: Debugging g_main_context_poll

[Kent Sandvik <sandvik gmail com>]

On Sun, 05 Sep 2004 10:21:43 -0400, Owen Taylor <otaylor redhat com> wrote:
> On Sat, 2004-09-04 at 16:07, Kent Sandvik wrote:
> > Hi, are there any good techniques to debug apps that seem to get stuck
> > in the g_main_context_poll, i.e. find out what poll_func() is hanging?
> >
> > I know of the G_MAIN_POLL_DEBUG flag in glib/gmain.c, but I don't get
> > enough info about the poll_func() that is causing the problem.
> >
> > This  is in the context of trying to debug the GDK/DirectFB layer
> > using sylpheed-gtk-2.0, and the send_progress dialog box ends up in
> > the g_main_context_poll. i.e. sits in poll()...
> 
> You do know that sitting in poll() is how GTK+ programs generally
> spend 99% of their time? It's the way that GTK+ wait for new events,
> etc. So, "stuck in poll()" just means that the application is waiting
> for something that hasn't occurred yet.

Yes, but the issue is to find out what it's hanging upon, for example
an alert  triggered from a modal dialog that is waiting for a close
button but in directfb/GTK windowed mode there's no stacking of
windows if window decoration is disabled, and how to find those cases.
I need to figure out more how to print out meaning from GPollFDs and 
GPollFuncs and associate it with a certain part of code that is
waiting. --Kent