[omniORB] COMM_FAILURE for "long" sequences

Steve Rowe srowe at photoworks.com
Mon Mar 21 15:17:51 GMT 2005

I'm not sure about this, but have you adjusted your setting for 
giopMaxMsgSize?  I believe you will get a Marshalling exception if this 
isn't big enough for the GIOP message.

Hope that helps

- Steve Rowe

At 08:59 AM 3/21/2005, celle at nada.kth.se wrote:
>Hi all,
>I have been using omniORB for a number of years now, but never come
>across a problem like this. For some reason I get COMM_FAILURE if the
>size of a sequence<octet> is too large. So far I have been transfering
>images of sizes 320x240 using a function GetImage (see the bit of code
>below). However, when I changed the size to 640x480 is suddenly get
>an exception.
>The server trace looks something like this:
>omniORB: Server accepted connection from giop:tcp:192.168.x.x:35693
>omniORB: giopWorker task execute.
>omniORB: Accepted connection from giop:tcp:192.168.x.x:35693
>because of this rule: "* unix,ssl,tcp"
>omniORB: inputMessage: from giop:tcp:192.168.x.x:35693 98 bytes
>omniORB:  recieve codeset service context and set TCS to
>omniORB: sendChunk: to giop:tcp:192.168.x.x:35693 24 bytes
>omniORB: inputMessage: from giop:tcp:192.168.x.x:35693 67 bytes
>omniORB: sendChunk: to giop:tcp:192.168.x.x:35693 28 bytes
>omniORB: sendCopyChunk: to giop:tcp:192.168.x.x:35693 307196 bytes
>omniORB: throw giopStream::CommFailure from
>And the client one as follows:
>omniORB: Client attempt to connect to giop:tcp:192.168.x.x:35652
>omniORB: Client opened connection to giop:tcp:192.168.x.x:35652
>omniORB: sendChunk: to giop:tcp:192.168.x.x:35652 98 bytes
>omniORB: inputMessage: from giop:tcp:192.168.x.x:35652 24 bytes
>omniORB: sendChunk: to giop:tcp:192.168.x.x:35652 67 bytes
>omniORB: inputMessage: from giop:tcp:192.168.x.x:35652 28 bytes
>omniORB: throw giopStream::CommFailure from
>The error occurs in function Send() in tcpConnection.cc. The UNIX
>socket function send() returns EFAULT, which should mean that the
>memory buffer (where data to be sent is stored) can't be accessed.
>If I allocate a buffer (simply using new) the address space will
>vary depending on the size of the buffer. Obviously, large buffers
>will be allocated at address spaces where it can't be used by the
>ORB. To me it seems like a Linux problem rather than a omniORB
>problem, but if you have any comments I would be happy to hear.
>By the way, I use Linux with kernel version 2.4.18smp.
>Have a nice day,
>Mårten Björkman
>///////////// Simplified IDL file
>interface ImageTrans {
>   typedef sequence<octet> SeqImage;
>   void GetImage(in short cam, in boolean jpeg, out SeqImage img,
>     out short width, out short height, out long size);
>////////// Server side function
>void ImageTransfer::GetImage(short cam, bool jpeg,
>   ImageTrans::SeqImage_out seqimg, short &width, short &height,
>   long int &totsize)
>     mutex.lock();
>     width = 320;
>     height = 240;
>     Image<unsigned char> limg(width, height); // Some image class
>     // Some fiddling with the image
>     totsize = width * height;
>     seqimg = new ImageTrans::SeqImage(totsize, totsize,
>        (CORBA::Octet*)limg.GetData(), false);
>     mutex.unlock();
>/////////// Client side call
>     ImageTrans::SeqImage_var img;
>     trans->GetImage(0, false, img, wid, hei, siz);
>     Image<unsigned char> limg(wid, hei);
>     unsigned char *lptr = limg.GetData();
>     for (int i=0;i<wid*hei;i++)
>        lptr[i] = img[i];
>omniORB-list mailing list
>omniORB-list at omniorb-support.com

More information about the omniORB-list mailing list