<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from rtf -->
<style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<font face="Calibri" size="2"><span style="font-size:11pt;">
<div>Hi Duncan,</div>
<div>&nbsp;</div>
<div>Thanks for your valuable time and the prompt response.</div>
<div>&nbsp;</div>
<div><b>Platfrom</b>: AIX6.1</div>
<div>&nbsp;</div>
<div><b>You need to figure out why your build broke the exception handling</b><b>:</b></div>
<div>&nbsp;</div>
<div>Dynamic exception specification <b>throw(type)</b> is deprecated in C&#43;&#43;17<b> </b><a href="https://en.cppreference.com/w/cpp/language/except_spec"><font color="#0563C1"><u>https://en.cppreference.com/w/cpp/language/except_spec</u></font></a></div>
<div>&nbsp;</div>
<div>When compiled the OmniORB-4.2.2 source with “gcc8 and C&#43;&#43;17”, we resolved the compilation errors related to dynamic exception specifications those are unsupported in C&#43;&#43;17. Mentioned few headers below,</div>
<div><font color="#833C0B">virtual void visit(const char* value,Source source) <b>throw (BadParam)</b> = 0;</font></div>
<div><font color="#833C0B">void addOptions(const char* options[][2]) <b>throw (Unknown,BadParam)</b>;</font></div>
<div>Removed all the dynamic exception specifications (“<font color="#833C0B"><b>throw</b></font>”) to compile with C&#43;&#43;17 below,</div>
<div><font color="#833C0B">virtual void visit(const char* value,Source source) = 0;</font></div>
<div><font color="#833C0B">void addOptions(const char* options[][2]);</font></div>
<div>&nbsp;</div>
<div>If we remove the exception specification <font color="#833C0B"><b>throw (BadParam)</b></font><font color="#833C0B"><b> </b></font>from function header, it does allow the function to throw exception at any type.</div>
<div>So we thought it should not impact anything. </div>
<div>&nbsp;</div>
<div>Does this change break the exception handling? If so, how to resolve this issue and make it work with C&#43;&#43;17?</div>
<div>&nbsp;</div>
<div>Thanks &amp; Regards,</div>
<div>P. Prasath.</div>
<a name="_MailEndCompose"></a>
<div>&nbsp;</div>
<div>-----Original Message-----<br>

From: Duncan Grisby &lt;duncan@grisby.org&gt; <br>

Sent: Friday, March 29, 2019 3:50 PM<br>

To: Prasath Palaniappan &lt;Prasath_Palaniappan@amat.com&gt;; omniorb-list@omniorb-support.com<br>

Cc: Shankar Chinnusamy &lt;Shankar_Chinnusamy@amat.com&gt;<br>

Subject: [External] Re: [omniORB] OmniORB-4.2.2 compiled with gcc8 and C&#43;&#43;14 leads into crash</div>
<div>&nbsp;</div>
<div>&nbsp;</div>
<div>CAUTION: EXTERNAL EMAIL. Verify before you click links or open attachments. Questions? Contact GIS.</div>
<div>&nbsp;</div>
<div>&nbsp;</div>
<div>&nbsp;</div>
<div>On Mon, 2019-03-25 at 06:19 &#43;0000, Prasath via omniORB-list wrote:</div>
<div>&nbsp;</div>
<div>[...]</div>
<div>&gt; But now for project need, we have upgraded the compiler and std </div>
<div>&gt; library from “gcc4.8 and C&#43;&#43;14” to “gcc8 and C&#43;&#43;17”. So that we </div>
<div>&gt; compiled the source OmniORB-4.2.2 with “gcc8 and C&#43;&#43;17”.</div>
<div>&nbsp;</div>
<div>[...]</div>
<div>&gt; We tested the project (Our Application &#43; OmniORB-4.2.2) which is </div>
<div>&gt; completely compiled with “gcc8 and C&#43;&#43;17”. But the process got crashed </div>
<div>&gt; with terminate caught due to throwing dynamic exception on </div>
<div>&gt; communication failure.</div>
<div>&nbsp;</div>
<div>Something is clearly wrong with your build of it then.</div>
<div>&nbsp;</div>
<div>[...]</div>
<div>&gt; omniORB: Orderly connection shutdown:</div>
<div>&gt; giop:tcp:[::ffff:10.41.46.93]:33260</div>
<div>&gt; omniORB: throw giopStream::CommFailure from</div>
<div>&gt; giopImpl12.cc:1243(0,NO,COMM_FAILURE_UnMarshalArguments)</div>
<div>&nbsp;</div>
<div>This is omniORB's normal way of handling a connection being closed. It throws the internal giopStream::CommFailure exception and catches it higher up the call chain.</div>
<div>&nbsp;</div>
<div>&gt; Terminate caught</div>
<div>&nbsp;</div>
<div>But this shows that the exception handler didn't trigger. The problem is not in omniORB, but something about the way it was compiled.</div>
<div>&nbsp;</div>
<div>[...]</div>
<div>&gt; Turnoff the exception – We commented out the exception throw code at </div>
<div>&gt; line number:512 in “src\lib\omniORB\orbcore\giopStream.cc”</div>
<div>&gt; throw CommFailure(minor,status,retry);</div>
<div>&nbsp;</div>
<div>Clearly that is not the right thing to do. The code throws the exception on purpose. If you break the code by no longer throwing the exception, the server will no longer properly clean up connections.</div>
<div>&nbsp;</div>
<div>You need to figure out why your build broke the exception handling.</div>
<div>&nbsp;</div>
<div>You haven't mentioned what platform you are using.</div>
<div>&nbsp;</div>
<div>Duncan.</div>
<div>&nbsp;</div>
<div>--</div>
<div> -- Duncan Grisby&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; --</div>
<div>&nbsp; -- <a href="mailto:duncan@grisby.org">duncan@grisby.org</a>&nbsp;&nbsp;&nbsp;&nbsp; --</div>
<div>&nbsp;&nbsp; -- <a href="http://www.grisby.org">http://www.grisby.org</a> --</div>
<div>&nbsp;</div>
<div>&nbsp;</div>
<div><font face="Calibri">The content of this message is APPLIED MATERIALS CONFIDENTIAL. If you are not the intended recipient, please notify me, delete this email and do not use or distribute this email. </font></div>
</span></font>
</body>
</html>