[omniORB] COMM_FAILURE for "long" sequences

celle at nada.kth.se celle at nada.kth.se
Mon Mar 21 17:59:50 GMT 2005


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 
(ISO-8859-1,UTF-16)
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 
giopStream.cc:1154(0,YES,COMM_FAILURE_MarshalResults)

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 
giopStream.cc:876(0,MAYBE,COMM_FAILURE_WaitingForReply)

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];

/////////////////////////





More information about the omniORB-list mailing list