<div>Will,</div><div><br></div>You don't say what platform this is but omniORB does things in threads. I would assume other ORBs do too. It is generally a bad idea to use large arrays in threads because they likely have limited stack space. Try changing your example to use a sequence<octet>.<div>
<br></div><div>Bruce<br><br><div class="gmail_quote">On Thu, Jan 22, 2009 at 9:26 AM, Michael <span dir="ltr"><<a href="mailto:omniorb@bindone.de">omniorb@bindone.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
You can change giopMaxMsgSize in omniORB.cfg to a higher value. You<br>
shouldn't use arrays, because they are allocated on the stack (therefore<br>
I would assume the different exceptions), use a sequence instead<br>
(typedef sequence<octet> OctSeq)<br>
<div><div></div><div class="Wj3C7c"><br>
Will Denissen wrote:<br>
> Dear Duncan,<br>
><br>
> I have modified the standard echo example into<br>
> one simple function st_fi with one inout parameter of a big fixed size<br>
> structure type.<br>
><br>
> Depending on the size of the dimension DIM, the client and server react<br>
> differently (see echo.idl)<br>
><br>
> --- echo.idl<br>
> ------------------------------------------------------------------------<br>
> ------<br>
> // Client: Server:<br>
><br>
> //const long DIM = 2097152; // 2MB CORBA::MARSHAL OK<br>
> //const long DIM = 2097100; // CORBA::MARSHAL OK<br>
> //const long DIM = 2097000; // CORBA::COMM_FAILURE<br>
> Segmentation Fault after a while<br>
> //const long DIM = 1100000; // CORBA::COMM_FAILURE<br>
> Segmentation Fault after a while<br>
> //const long DIM = 1048576; // 1MB sys exc TRANSIENT<br>
> Segmentation Fault after a while<br>
> //const long DIM = 1000000; // OK OK<br>
><br>
> const long DIM = 1048576;<br>
><br>
> struct st_fi_t {<br>
> octet x[DIM];<br>
> };<br>
><br>
> interface Echo {<br>
> void st_fi(inout st_fi_t p1);<br>
> };<br>
><br>
> --- end of echo.idl<br>
> ------------------------------------------------------------------------<br>
><br>
><br>
> Have you any idea why omniorb is reacting like this?<br>
> How do I know what the exact bounderies are that will give a robust<br>
> correctly working omniorb?<br>
> Is it possible to build in extra checks into omniorb to prevent/detect<br>
> this kind of unwanted behaviour?<br>
><br>
> PS:<br>
> If you need to reproduce the results.<br>
> The server implementation of st_fi is just empty (see serv.cc).<br>
> The client just calls st_fi once with it parameter allocated on the heap<br>
> (see clnt.cc)<br>
> The executables are build and started with (makefile, start_client,<br>
> start_server).<br>
> The used options file is sample.cfg.<br>
> I am using omniorb 4.1.3 on Solaris 5.8 and gcc 4.1.2<br>
><br>
> Will.<br>
><br>
><br>
><br>
><br>
><br>
</div></div>> ------------------------------------------------------------------------<br>
><br>
> _______________________________________________<br>
> omniORB-list mailing list<br>
> <a href="mailto:omniORB-list@omniorb-support.com">omniORB-list@omniorb-support.com</a><br>
> <a href="http://www.omniorb-support.com/mailman/listinfo/omniorb-list" target="_blank">http://www.omniorb-support.com/mailman/listinfo/omniorb-list</a><br>
<br>
_______________________________________________<br>
omniORB-list mailing list<br>
<a href="mailto:omniORB-list@omniorb-support.com">omniORB-list@omniorb-support.com</a><br>
<a href="http://www.omniorb-support.com/mailman/listinfo/omniorb-list" target="_blank">http://www.omniorb-support.com/mailman/listinfo/omniorb-list</a><br>
</blockquote></div><br></div>