[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