Re: gconfd process eating CPU

[Mark McLoughlin <markmc redhat com>]

On Mon, 2005-01-10 at 18:21 -0600, Brian Cameron wrote:

> >>4335/1 1:	 1.0220	                -> liblinc:linc_connection_read(0x34900, 0x14418c, 0x0, 0x0)
> >>4335/1 1:	 1.0222	                  -> liblinc:d_printf(0xff1e5bb0, 0x0, 0xa, 0x0)
> >>4335/1 1:	 1.0224	                  <- liblinc:d_printf() = 0xff1e5bb0
> >>4335/1 1:	 1.0228	                <- liblinc:linc_connection_read() = 0
> > 
> >   -> Here we read the connection and find that it returns zero. That 
> >      means the other side of the connection has closed. Looking at 
> >      recent ORBit code I'd expect linc_connection_state_changed() to
> >      be called and we'd close our side and remove the source
> 
> This makes sense, although looking at the code for link_connection_io_handler
> (both the older code and the current CVS code), I don't see how
> link_connection_state_changed could get called in this scenario.

	Right, linc_connection_read() returns LINC_IO_FATAL_ERROR if read()
returns zero. So, the other side isn't closing the connection then - or
at least that's not what a zero return from linc_connection_read()
means.

	So, linc_connection_read() is being passed len == 0. Looking at the
code, the only way that could really happen is if a previous read
returned an error and state_changed (LINC_DISCONNECTED) didn't cause the
watch to be removed.

	Dunno, you'd need a debug log from the time when the connection got
into that state.

Cheers,
Mark.