Alexandre,<br><br>fair enough ... you&#39;re right ... it&#39;s always omniORB which processes the CORBA calls.<br>Thanks a lot for your hint.<br><br>Friedhelm<br><br><div><span class="gmail_quote">On 6/22/07, <b class="gmail_sendername">
Alexandre DENIS</b> &lt;<a href="mailto:Alexandre.Denis@labri.fr">Alexandre.Denis@labri.fr</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Friday 22 June 2007, Friedhelm Wolf wrote:<br><br>&gt; I attatched a core dump which shows, that there are TAO calls made<br>&gt; within a omni ORB requests. Please correct me if I misinterpret this<br>&gt; dump (I&#39;m no expert at all), but it seems, that the symbols don&#39;t get
<br>&gt; mingled. (maybe because the whole TAO stuff is dynamically loaded at<br>&gt; runtime).<br><br>This backtrace shows that CORBA::Object::is_nil from omniORB was applied<br>to a TAO object.<br><br>&gt; But I guess the problem with the _CORBA_bad_param_freebuf() error is
<br>&gt; due to global symbols too and&nbsp;&nbsp;so I better find a way to use the ORBs<br>&gt; in two separate<br>&gt; processes.<br><br>Indeed, it would be much better to have different ORBs in different<br>processes.<br><br>-a.
<br><br><br></blockquote></div><br>