Re: cvs commit: ports/devel/ORBit Makefile ports/devel/ORBit/files patch-src::IIOP::giop-msg-buffer.c
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
Re: cvs commit: ports/devel/ORBit Makefile ports/devel/ORBit/files patch-src::IIOP::giop-msg-buffer.c
On Fri, Oct 26, 2001 at 05:49:08PM +0300, Maxim Sobolev wrote: > 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. 2800 entries? Well, from the writev(2) manual page: In addition, writev() may return one of the following errors: ... [EINVAL] Iovcnt was less than or equal to 0, or greater than UIO_MAXIOV. And at least on -stable, UIO_MAXIOV is defined as 1024.. G'luck, Peter -- Thit sentence is not self-referential because "thit" is not a word. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: ports/devel/ORBit Makefile ports/devel/ORBit/files patch-src::IIOP::giop-msg-buffer.c
Peter Pentchev wrote: > > On Fri, Oct 26, 2001 at 05:49:08PM +0300, Maxim Sobolev wrote: > > 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. > > 2800 entries? Well, from the writev(2) manual page: > > In addition, writev() may return one of the following errors: > > ... > > [EINVAL] Iovcnt was less than or equal to 0, or greater than > UIO_MAXIOV. > > And at least on -stable, UIO_MAXIOV is defined as 1024.. Ah, ok. I've overlooked it somehow. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: ports/devel/ORBit Makefile ports/devel/ORBit/files patch-src::IIOP::giop-msg-buffer.c
On Fri, Oct 26, 2001 at 06:06:59PM +0300, Maxim Sobolev wrote: > Peter Pentchev wrote: > > > > On Fri, Oct 26, 2001 at 05:49:08PM +0300, Maxim Sobolev wrote: [snip] > > > > > > 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. > > > > 2800 entries? Well, from the writev(2) manual page: > > > > In addition, writev() may return one of the following errors: > > > > ... > > > > [EINVAL] Iovcnt was less than or equal to 0, or greater than > > UIO_MAXIOV. > > > > And at least on -stable, UIO_MAXIOV is defined as 1024.. > > Ah, ok. I've overlooked it somehow. So basically, you still want a loop, but it could be a writev(2) loop, not a write(2) loop, to keep some of the writev(2) performance benefit. G'luck, Peter -- If the meanings of 'true' and 'false' were switched, then this sentence wouldn't be false. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: ports/devel/ORBit Makefile ports/devel/ORBit/files patch-src::IIOP::giop-msg-buffer.c
Peter Pentchev wrote: > > On Fri, Oct 26, 2001 at 06:06:59PM +0300, Maxim Sobolev wrote: > > Peter Pentchev wrote: > > > > > > On Fri, Oct 26, 2001 at 05:49:08PM +0300, Maxim Sobolev wrote: > [snip] > > > > > > > > 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. > > > > > > 2800 entries? Well, from the writev(2) manual page: > > > > > > In addition, writev() may return one of the following errors: > > > > > > ... > > > > > > [EINVAL] Iovcnt was less than or equal to 0, or greater than > > > UIO_MAXIOV. > > > > > > And at least on -stable, UIO_MAXIOV is defined as 1024.. > > > > Ah, ok. I've overlooked it somehow. > > So basically, you still want a loop, but it could be a writev(2) loop, > not a write(2) loop, to keep some of the writev(2) performance benefit. Yes, I've figured it already, because doing 2,800 syscalls when you can do a 3 instead is a bad idea. :) -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: ports/devel/ORBit Makefile ports/devel/ORBit/files patch-src::IIOP::giop-msg-buffer.c
On Fri, Oct 26, 2001 at 06:31:56PM +0300, Maxim Sobolev wrote: > Peter Pentchev wrote: > > > > On Fri, Oct 26, 2001 at 06:06:59PM +0300, Maxim Sobolev wrote: > > > Peter Pentchev wrote: > > > > > > > > On Fri, Oct 26, 2001 at 05:49:08PM +0300, Maxim Sobolev wrote: > > [snip] > > > > > > > > > > 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. > > > > > > > > 2800 entries? Well, from the writev(2) manual page: > > > > > > > > In addition, writev() may return one of the following errors: > > > > > > > > ... > > > > > > > > [EINVAL] Iovcnt was less than or equal to 0, or greater than > > > > UIO_MAXIOV. > > > > > > > > And at least on -stable, UIO_MAXIOV is defined as 1024.. > > > > > > Ah, ok. I've overlooked it somehow. > > > > So basically, you still want a loop, but it could be a writev(2) loop, > > not a write(2) loop, to keep some of the writev(2) performance benefit. > > Yes, I've figured it already, because doing 2,800 syscalls > when you can do a 3 instead is a bad idea. :) Oh, and BTW - writev(2) can also return EINVAL if the total size exceeds some maximum value (the manual page mentions a 32-bit integer). G'luck, Peter -- I am not the subject of this sentence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
