Re: IO Channel Flush - Assertion Failure

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

 



On Tue, 2007-12-18 at 12:03 -0800, Peter Long wrote:
> I agree, there seems to be a bug, the question is where the bug lies. 
> I think it is legal for write() to return 0  however I have never experienced 
> that myself. Also write() does return -1 if EINTR or EAGAIN occurs. I 
> have no idea what conditions would cause it to return 0. I would expect
> a value between 1 and count inclusive where count is the number of bytes
> in the buffer past to write() in the third parameter.
> 
> My guess is that the glib code is not where the problem is. Either the OS 
> implementation of write() is buggy or there is a subtle bug in your code. 
> 
> I cannot imagine how you would fix this problem in either g_io_unix_write() 
> or g_io_channel_flush(). If write() return's 0 do you just retry the write(), or 
> do you make up an error status? It depends on what it means to get back a
> 0 from write().

Yep .. until it is not clear if a 0 from write() is legal or what it
means, it is not clear whether and how to alter g_io_unix_write() or
g_io_channel_flush().

> Perhaps someone else knows what would cause write() to return 0. 

> BTW: What OS are you using?

Ubuntu 7.10 with
- libc6-2.6.1
- glib 2.14.1

Just for your info:
The assertion fails rarely, but if it fails, then in the following situation:

g_io_channel_write_chars(many bytes ~ 60K)
g_io_channel_write_chars(4 bytes)
g_io_channel_flush() <- channel buffer contains 4 bytes at this point

Channel encoding is NULL.
No idea why it happens in this special situation.


_______________________________________________
gtk-list mailing list
gtk-list@xxxxxxxxx
http://mail.gnome.org/mailman/listinfo/gtk-list

[Index of Archives]     [Touch Screen Library]     [GIMP Users]     [Gnome]     [KDE]     [Yosemite News]     [Steve's Art]

  Powered by Linux