Re: Windows GTK hang 'not responding'

[Anna <christiana hipointcoffee com>]

Where is select() being run from?  Is it from within the GTK+ main loop
or from somewhere in your application or in another library?  I think
GTK+ uses poll() to listen for input...  which may be implemented with
select()...  but all the same...  if it's the select() call that GTK+ is
running then there must be something weird going on.  If you are calling
select(), then GTK+ will be unresponsive...  because it cannot respond
to input if a callback is sitting in a blocking function.  If this is
your problem (you're running select() and not allowing GTK+ to run
select()/poll() for you) then you may want to see if there's a way to
hand your file descriptors over to the main GTK+ for listening.  I don't
think there's a way to make select() listen for mouse events.

- Anna



On Fri, Apr 28, 2006 at 08:38:59AM -0400, Derek Piper wrote:
> 
> 	Hi,
> 
> 	No, it's not a basic networking thing. I've written socket programs 
> before. :) The program itself isn't freezing, that's what I was saying 
> I've been able to determine. It's just waiting normally in select (for 
> network packets) whenever I get a 'hang' dump grab for windbg. So, 
> that's not of any help to track down the problem. Thinking it was 
> something with select() under windows, I set the timeout to zero and 
> then called 'Sleep()' manually to test it. Sure enough, whenever it's 
> 'grabbed' the program is sleeping which makes sense as it's not really 
> hung and that's where a lot of programs will be if you were to take a 
> snapshot of them.
> 	The program is still operating, I get debugging printfs through my 
> 	main loop and also it is still reading from the network and recording  to 
> disk. The ONLY thing that appears to hang is the GTK part. Windows just 
> says it's window is 'unresponsive'.
> 	So, it's along the GTK lines I was seeking some advice.
> 
> 	Derek
> 
> Anna wrote:
> >On Thu, Apr 27, 2006 at 01:56:24PM -0400, Derek Piper wrote:
> >
> >>	Hi,
> >>
> >>	I have a strange bug I'm trying to track down. I've been able to 
> >>determine that the program is not hanging in itself, it's the window 
> >>that just 'freezes'.
> >>	The program I have has a 'telnet' mode, and I am able to telnet to 
> >>	the program even when the GTK window has 'hung'. When I enter a 
> >>	command, the window 'unfreezes'.
> >>	This is using GLib 2.10.1 and GTK 2.8.17 DLLs run from a 
> >>	'standalone' environment, i.e. PATH set to include the relevant DLLs 
> >>	etc. The error still occurs using GTK 2.8.9 (the latest Windows 
> >>installer) and also on GTK 2.6.10 (Windows).
> >>	Has anyone else had that sort of thing happen or have any idea as to 
> >>why it's happening? Trying to get a 'hang' dump of my program only 
> >>reveals it's waiting in the select(), or in a sleep. My program was 
> >>originally written without an interface (apart from telnet) but I added 
> >>the GTK interface and call this code in a function:
> >
> >
> >what's the select() waiting for?  are you just using it to sleep?  I
> >don't understand your comment about "or in a sleep".  If your program is
> >hanging and you discover it's just sitting in a sleep() too long, why
> >not just adjust the amount of time it's sleep()ing for?  and, the
> >select() call should return when whatever it's wainting for arives.  You
> >can give select() a timeout.  why not do that?  have you tried running
> >it under a debugger?  the fact that it runs fine on Debian but hangs on
> >windows says "timing issue" to me.  things are probably running in a
> >slightly different order in Windows than in Linux, causing...  something
> >like...  a file descriptor to be in a writable state while you're still
> >waiting for readable.  good luck.
> >
> >- Anna
> >
> >
> 
> -- 
> Derek Piper - dcpiper indiana edu - (812) 856 0111
> IRI 323, School of Informatics
> Indiana University, Bloomington, Indiana