Ian Dowse wrote: > > In message <[EMAIL PROTECTED]>, Maxim Sobolev writ > es: > > Nautilus from working properly. The problem disappeared when I've replaced > > writev(2) call with appropriate loop based around ordinary write(2). Perhaps > > this should be investigated and the real source of the problem fixed instead, > > but I do not have a time for this right now. For those who interested I'm > > ready to provide a step-by step instruction on how to reproduce the bug. > > Hi, > > If you have the details handy, a post to -hackers is likely to be > quite constructive at getting the problem analysed and resolved.
Ok, details are below. GNOME oaf is a CORBA-based RPC framework. It uses UNIX domain sockets to communicate between client application and oafd daemon that serves requests. Usually the communication looks like the following: 1. Client connects to the oafd daemon via domain socket and sends marshalled RPC request. 2. The daemon reads request, demarshalls it and executes either internally or by invoking external program/shared library. 3. The daemon marshalls result of the call and passes it back to the client via the same socket. On the step 3, when marshalling results of the call, daemon creates a large collection of small buffers (usually 5-10 bytes long each) arranged as array of struct iovec and then sends this whole buffer to the client using writev(2) call. In my particular case there were some 2,800 entries in the buffer and when the daemon tried to send it to the client writev(2) was returning -1 and setting errno to be EINVAL, which confused the server and the client causing RPC to fail. To check that all buffers are indeed valid I have replaced writev(2) with a simple loop based around write(2), and the problem disappeared. See http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/ORBit/files/patch-src%3a%3aIIOP%3a%3agiop-msg-buffer.c for details. I suspect that there is some problem associated with the writev(2)'s handling of EAGAIN (in my write(2)-based replacement I've observed EAGAIN on some 800th element of the buffer). If the problem is confirmed, it should be either fixed, or somehow noted in the manual page. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
