Re: g_io_channel_read_chars() loop

On Thu, Aug 09, 2001 at 12:59:10PM -0700, Ron Steinke wrote:
> >    1676       do
> >    1677         {
> >    1678           prevchar = nextchar;
> >    1679           nextchar = g_utf8_next_char (nextchar);
> >    1680         }
> >    1681       while (nextchar < channel->encoded_read_buf->str + got_bytes);
> >
> The contents of encoded_read_buf should always be valid UTF-8,
> and the length should always match the length of valid data,
> so it sounds like it's being corrupted elsewhere and you're
> just finding out in g_io_channel_read_chars ().
> What this sounds like is a call to g_string_set_size () to
> add some space to read in data, without a corresponding call
> to g_string_truncate () to set the length of the string
> equal to the length of the valid data. The only place
> in giochannel.c that g_string_set_size () is called
> on encoded_read_buf is in g_io_channel_fill_buffer (),
> which is followed by a call to g_string_truncate () about
> 5-10 lines later. No loops, no branches, nothing.
> This is very puzzling.
> Two other less likely possiblities for the origin of the

	Well, as my later post suggests, I backed out the changes of five
days ago and it started working.  However, I have seen the code paths
you are describing.  I've stepped through them extensively.  I've burned
them on my brain, and came close to going crazy (again).  I still don't
see how they could be wrong, and I only have the loop or crash while not
stepping through it.   This makes me think of a race.
	I note that some GObject changes were made at the same time.
Those were backed out as well.  If they corrupted the IOChannel object,
surely buf->len could be wrong and buf->str wronger still.  It would
also help explain why sometimes my source callback is called after it
returns false, and why it other times segfaults after I have returned
	I don't know this is an IOChannel bug, but I do know it is the
only thing I have experienced it with.  Gtk has no problems.



"In the long run...we'll all be dead."
			jlbec evilplan org

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