________________________________
Van: Michael [mailto:omniorb at bindone.de]
Verzonden: do 22-1-2009 15:26
Aan: Will Denissen; 'omniorb-list at omniorb-support.com'
Onderwerp: Re: [omniORB] omniorb 4.1.3 and large messages
You can change giopMaxMsgSize in omniORB.cfg to a higher value. You
The giopMaxMsgSize is the limit for which omniorb will throw a CORBA::MARSHAL exception.
So raising the value would only make the DIM range of unkown behaviour larger.
shouldn't use arrays, because they are allocated on the stack (therefore
Is there an possibility/option to let the server allocate on the heap? It would probably solve these kinds of problems.
I would assume the different exceptions), use a sequence instead
(typedef sequence<octet> OctSeq)
I am not in the position to modify types.
Will Denissen wrote:
> Dear Duncan,
>
> I have modified the standard echo example into
> one simple function st_fi with one inout parameter of a big fixed size
> structure type.
>
> Depending on the size of the dimension DIM, the client and server react
> differently (see echo.idl)
>
> --- echo.idl
> ------------------------------------------------------------------------
> ------
> // Client: Server:
>
> //const long DIM = 2097152; // 2MB CORBA::MARSHAL OK
> //const long DIM = 2097100; // CORBA::MARSHAL OK
> //const long DIM = 2097000; // CORBA::COMM_FAILURE
> Segmentation Fault after a while
> //const long DIM = 1100000; // CORBA::COMM_FAILURE
> Segmentation Fault after a while
> //const long DIM = 1048576; // 1MB sys exc TRANSIENT
> Segmentation Fault after a while
> //const long DIM = 1000000; // OK OK
>
> const long DIM = 1048576;
>
> struct st_fi_t {
> octet x[DIM];
> };
>
> interface Echo {
> void st_fi(inout st_fi_t p1);
> };
>
> --- end of echo.idl
> ------------------------------------------------------------------------
>
>
> Have you any idea why omniorb is reacting like this?
> How do I know what the exact bounderies are that will give a robust
> correctly working omniorb?
> Is it possible to build in extra checks into omniorb to prevent/detect
> this kind of unwanted behaviour?
>
> PS:
> If you need to reproduce the results.
> The server implementation of st_fi is just empty (see serv.cc).
> The client just calls st_fi once with it parameter allocated on the heap
> (see clnt.cc)
> The executables are build and started with (makefile, start_client,
> start_server).
> The used options file is sample.cfg.
> I am using omniorb 4.1.3 on Solaris 5.8 and gcc 4.1.2
>
> Will.
>
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> omniORB-list mailing list
> omniORB-list at omniorb-support.com
> http://www.omniorb-support.com/mailman/listinfo/omniorb-list
--
The information contained in this communication and any attachments is confidential and may be privileged, and is for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. Unless explicitly stated otherwise in the body of this communication or the attachment thereto (if any), the information is provided on an AS-IS basis without any express or implied warranties or liabilities. To the extent you are relying on this information, you are doing so at your own risk. If you are not the intended recipient, please notify the sender immediately by replying to this message and destroy all copies of this message and any attachments. ASML is neither liable for the proper and complete transmission of the information contained in this communication, nor for any delay in its receipt.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20090122/00f4c185/attachment.htm