[omniORB] [External] Re: OmniORB-4.2.2 compiled with gcc8 and C++14 leads into crash
Serguei Kolos
serguei.kolos at cern.ch
Tue Apr 23 11:50:45 BST 2019
Hi Prasath
I still believe that the issue is not related to omniORB. In our project
we have been using
omniORB-4.2.2 compiled with gcc 8.2.0 (using c++1z option which is a
synonym of the c++17)
for the x86_64-pc-linux-gnu platform and it works flawlessly. It should
be either a compiler
configuration issue or something inside your project.
By the way did you try to run any of the omniORB examples compiled with
gcc 8.2.0?
Cheers,
Serguei
PS: Here is our compiler configuration
g++ -v
Using built-in specs.
COLLECT_GCC=g++
Target: x86_64-pc-linux-gnu
Configured with: configure --prefix=/gcc/8.2.0/x86_64-centos7
-with-system-zlib --disable-multilib --enable-languages=all
--with-gnu-ld --with-ld=/binutils/2.30/x86_64-centos7/bin/ld
--with-gnu-as --with-as=/binutils/2.30/x86_64-centos7/bin/as
Thread model: posix
gcc version 8.2.0 (GCC)
On 4/23/19 12:05 PM, Prasath_Palaniappan at amat.com wrote:
>
> Hi Serguei,
>
> Thanks for the suggestion.
>
> Actually I have done the same what you suggested. I have removed the
> 'throw(...)' specifications completelyfrom all the functions.
>
> I am getting the issue with that only.
>
> Thanks & Regards,
>
> P. Prasath.
>
> *From:*Serguei Kolos <serguei.kolos at cern.ch>
> *Sent:* Tuesday, April 23, 2019 3:25 PM
> *To:* Prasath Palaniappan <Prasath_Palaniappan at amat.com>;
> duncan at grisby.org; omniorb-list at omniorb-support.com
> *Cc:* Shankar Chinnusamy <Shankar_Chinnusamy at amat.com>
> *Subject:* Re: [omniORB] [External] Re: 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.
>
> Hi Prasath
>
> You mentioned that in order to compile omniORB with c++17 option you
> have removed the 'throw'
> specifications from some functions declarations. How did you actually
> do that? Could it be
> that you have made this modification in the following way:
>
> void f() throw (BadParam) => void f() throw ()
>
> The crash which you get normally happens in one of the two cases:
>
> 1) A function declares 'throw(A)' but actually throws a different
> exception 'B'.
> 2) A function is declared as not throwing any exception using
> 'throw()' declaration but actually throws an exception.
>
> So I would suggest you to check that you have removed the 'throw(...)'
> specifications completely
> from all the functions concerned and don't have 'throw()' terms left
> anywhere in these functions
> declarations.
>
> Cheers,
> Serguei
>
> On 4/23/19 11:01 AM, Prasath via omniORB-list wrote:
>
> Hi Duncan,
>
> Thanks for the response.
>
> Please find the answers below,
>
> *Where did the compiler come from? *
>
> gcc 8.2 (gcc-8.2.0.tar.gz) is downloaded from https://gcc.gnu.org/
>
> *Did you compile it yourself? *
>
> Yes, we compiled it (gcc-8.2.0.tar.gz). Arguments to gcc configure
> script below,
>
> $./configure --prefix=/usr/local/gcc-8.2-powerpc-ibm-aix6.1.0.0
> --build=powerpc-ibm-aix6.1.0.0 --without-gnu-as
> --with-as=/usr/bin/as --without-gnu-ld --with-ld=/usr/bin/ld
> --disable-nls --disable-shared --enable-languages=c++
> --enable-checking=release --enable-bootstrap
> -enable-version-specific-runtime-libs
>
> $make install
>
> *What does "g++ -v" report?*
>
> bash-4.4$ ./g++ -v
>
> Using built-in specs.
>
> COLLECT_GCC=./g++
>
> COLLECT_LTO_WRAPPER=/usr/local/gcc-8.2-powerpc-ibm-aix6.1.0.0/libexec/gcc/powerpc-ibm-aix6.1.0.0/8.2.0/lto-wrapper
>
> Target: powerpc-ibm-aix6.1.0.0
>
> Configured with:
> /disks/smithers3/workplaces/build/gcc-8.2/gcc-8.2.0/configure
> --prefix=/usr/local/gcc-8.2-powerpc-ibm-aix6.1.0.0
> --build=powerpc-ibm-aix6.1.0.0 --without-gnu-as
> --with-as=/usr/bin/as --without-gnu-ld --with-ld=/usr/bin/ld
> --disable-nls --disable-shared --enable-languages=c++
> --enable-checking=release --enable-bootstrap
> -enable-version-specific-runtime-libs
>
> Thread model: aix
>
> gcc version 8.2.0 (GCC)
>
> *How did you configure omniORB? What were the arguments to its
> configure script?*
>
> $./configure --prefix=/usr/local/dev
>
> $make
>
> $make install
>
> As per your advice, we removed all the throw specifications and it
> got compiled successfully.
>
> And tested again but we are getting the same termination. For your
> reference, I have attached the completed log (it also has crash
> stack) with this mail.
>
> Please provide your thoughts to proceed further.
>
> Thanks & Regards,
>
> P. Prasath.
>
> -----Original Message-----
> From: Duncan Grisby <duncan at grisby.org> <mailto:duncan at grisby.org>
> Sent: Tuesday, April 16, 2019 5:58 PM
> To: Prasath Palaniappan <Prasath_Palaniappan at amat.com>
> <mailto:Prasath_Palaniappan at amat.com>;
> omniorb-list at omniorb-support.com
> <mailto:omniorb-list at omniorb-support.com>
> Cc: Shankar Chinnusamy <Shankar_Chinnusamy at amat.com>
> <mailto:Shankar_Chinnusamy at amat.com>
> Subject: Re: [omniORB] [External] Re: 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 Wed, 2019-04-10 at 11:03 +0000, Prasath via omniORB-list wrote:
>
> > OmniORB-4.2.2 has dynamic exception specifications those are
>
> > unsupported in C++17.
>
> > So we removed those unsupported dynamic exception specifications
> and
>
> > compiled the OmniORB-4.2.2 with "gcc8 and C++17".
>
> > virtual void visit(const char* value,Source source) throw
> (BadParam) =
>
> > 0;
>
> Yes, that is the right thing to do. Just remove all the throw
> specifications. The only place that has those throw specifications
> is in the option processing code, which is not involved at all in
> the errors you are seeing. Whatever the problem is, it has
> absolutely nothing to do with those throw specifications.
>
> > Apart from those changes what else need to be done to compile the
>
> > OmniORB-4.2.2 with "gcc8 and C++17" properly?
>
> Nothing. It works fine with just that change.
>
> > Clarifications:
>
> > As you mentioned that you have removed throw specifications in
>
> > OmniORB-4.3 to support future compilers and it is in development
>
> > branch. If so, could you please let us know when it will be
> released?
>
> There is no current timeframe for omniORB 4.3 to be released, but
> that is irrelevant here. There are no other changes in 4.3 that
> are related to this.
>
> The compiler has generated incorrect code, or the C++ runtime is
> faulty. An exception is being thrown but it not being caught as it
> should be by the exception handler.
>
> Where did the compiler come from? Did you compile it yourself?
> What does "g++ -v" report?
>
> How did you configure omniORB? What were the arguments to its
> configure script?
>
> Duncan.
>
> --
>
> -- Duncan Grisby --
>
> -- duncan at grisby.org <mailto:duncan at grisby.org> --
>
> -- 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
>
> omniORB-list at omniorb-support.com <mailto:omniORB-list at omniorb-support.com>
>
> http://www.omniorb-support.com/mailman/listinfo/omniorb-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20190423/b7a5daae/attachment-0001.html>
More information about the omniORB-list
mailing list