Re: [External] Re: OmniORB-4.2.2 compiled with gcc8 and C++14 leads into crash

Hi Duncan,

Thanks for your valuable time and the prompt response.

Platfrom: AIX6.1

You need to figure out why your build broke the exception handling:

Dynamic exception specification throw(type) is deprecated in C++17 https://en.cppreference.com/w/cpp/language/except_spec

When compiled the OmniORB-4.2.2 source with “gcc8 and C++17”, we resolved the compilation errors related to dynamic exception specifications those are unsupported in C++17. Mentioned few headers below,
virtual void visit(const char* value,Source source) throw (BadParam) = 0;
void addOptions(const char* options[][2]) throw (Unknown,BadParam);
Removed all the dynamic exception specifications (“throw”) to compile with C++17 below,
virtual void visit(const char* value,Source source) = 0;
void addOptions(const char* options[][2]);

If we remove the exception specification throw (BadParam) from function header, it does allow the function to throw exception at any type.
So we thought it should not impact anything.

Does this change break the exception handling? If so, how to resolve this issue and make it work with C++17?

Thanks & Regards,
P. Prasath.

-----Original Message-----
From: Duncan Grisby <[email protected]>
Sent: Friday, March 29, 2019 3:50 PM
To: Prasath Palaniappan <[email protected]>; [email protected]
Cc: Shankar Chinnusamy <[email protected]>
Subject: [External] Re: [omniORB] OmniORB-4.2.2 compiled with gcc8 and C++14 leads into crash


CAUTION: EXTERNAL EMAIL. Verify before you click links or open attachments. Questions? Contact GIS.



On Mon, 2019-03-25 at 06:19 +0000, Prasath via omniORB-list wrote:

[...]
> But now for project need, we have upgraded the compiler and std
> library from “gcc4.8 and C++14” to “gcc8 and C++17”. So that we
> compiled the source OmniORB-4.2.2 with “gcc8 and C++17”.

[...]
> We tested the project (Our Application + OmniORB-4.2.2) which is
> completely compiled with “gcc8 and C++17”. But the process got crashed
> with terminate caught due to throwing dynamic exception on
> communication failure.

Something is clearly wrong with your build of it then.

[...]
> omniORB: Orderly connection shutdown:
> giop:tcp:[::ffff:10.41.46.93]:33260
> omniORB: throw giopStream::CommFailure from
> giopImpl12.cc:1243(0,NO,COMM_FAILURE_UnMarshalArguments)

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.

> Terminate caught

But this shows that the exception handler didn't trigger. The problem is not in omniORB, but something about the way it was compiled.

[...]
> Turnoff the exception – We commented out the exception throw code at
> line number:512 in “src\lib\omniORB\orbcore\giopStream.cc”
> throw CommFailure(minor,status,retry);

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.

You need to figure out why your build broke the exception handling.

You haven't mentioned what platform you are using.

Duncan.

--
 -- Duncan Grisby         --
  -- [email protected]<mailto:[email protected]>     --
   -- http://www.grisby.org --


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.

_______________________________________________
omniORB-list mailing list
[email protected]
http://www.omniorb-support.com/mailman/listinfo/omniorb-list