[omniORB] COMM_FAILURE for "long" sequences

Mårten Björkman celle at nada.kth.se
Tue Mar 22 15:12:12 GMT 2005


It seems that things are implemented more efficiently than I originally 
thought. I just
assumed that data is in fact allocated and copied at the assignment.

The reason why I don't like to allocate data in the constructor is 
because image sizes
and formats might change. On the other hand, I could reallocate data 
once formats
and sizes change.

I does in fact explain some oddities I experienced when sending JPEG 
images. From
time to time the stream seemed to be truncated.

Thank you,

Mårten

Duncan Grisby wrote:

>On Tuesday 22 March, =?ISO-8859-1?Q?M=E5rten_Bj=F6rkman?= wrote:
>
>  
>
>>Thank you Duncan! I moved the allocation of memory to the constructor
>>of the server and then it worked. However, if I do like this
>>
>>void SeqTestServ::GetData(SeqTest::Data_out img, long int &size)
>>{
>>  unsigned char *dat = new unsigned char[totsize];
>>  img = new SeqTest::Data(totsize, totsize, dat, false);
>>  size = totsize;
>>  delete [] dat;
>>}
>>
>>it does not work, if totsize is larger than about 128K.
>>    
>>
>
>You have deleted the data before you return it!  It's pure luck that it
>works at all. The sequence constructor you are using does not copy the
>data -- it just holds a pointer to it.
>
>  
>
>>I suppose one way of solving it in my image case would be to allocate
>>memory using
>>
>>img = new SegTest::Data(totsize);
>>
>>and then let my image work on that memory before sending it away. Do
>>you have suggestion? I do not particularly like to allocate data in
>>the constructor.
>>    
>>
>
>Yes, that is a safe way to do it. Why do you not like allocating data in
>the constructor?
>
>  
>
>> If that is the problem than it is surprising that the
>>same piece of code has worked for two years with smaller images. :)
>>    
>>
>
>As I say, it's pure luck. You are most likely seeing an artifact of the
>way the memory allocator works. I guess it maps large allocations in a
>different way to small ones. It doesn't really matter why, though --
>what you are trying to do is definitely wrong.
>
>Cheers,
>
>Duncan.
>
>  
>




More information about the omniORB-list mailing list