Re: Exception not caught with gcc-8.2.0

[Prasath P <ijprasath@gmail.com>]

Hi All,

I am eagerly waiting for a solution to fix this bug. Kindly anyone help us
to resolve this issue or please let me know if we have any workaround to
resolve it?

Thanks & Regards,
P. Prasath.

On Tue, Jan 14, 2020 at 12:52 PM Prasath P <ijprasath@gmail.com> wrote:

> Hi Florian Dorsch,
> Thanks for the response.
>
> Hi All,
> Any other suggestion to fix this bug? or could you please let me know that
> will it be fixed in which gcc version?
>
> Thanks & Regards,
> P. Prasath.
>
>
> On Wed, Dec 11, 2019 at 10:19 PM Florian Dörsch <gcc@fd.mytrap.de> wrote:
>
>> Hi,
>>
>> thats a bug in the gcc on AIX.
>>
>> see https://www.spinics.net/lists/gcchelp/msg49970.html
>>
>> topic "g++ and IBM AIX: another exception handling bug?" of this
>> mailinglist
>>
>> Am 11.12.2019 um 15:11 schrieb Prasath P:
>> > Hi All,
>> >
>> >
>> >
>> > Greetings!!!
>> >
>> >
>> >
>> > Our application is a C++ application and compiled it with gcc-8.2.0
>> > compiler on AIX6.1.
>> >
>> >
>> >
>> > In our application, we are using omniORB-4.2.0 library. Earlier we used
>> > gcc-4.2.3 to compile omniORB and our application.
>> >
>> > omniORB + application works fine with gcc-4.2.3. But we upgraded the
>> > compiler from gcc-4.2.3 to gcc-8.2.0. On both compiler, we compiled
>> omniORB
>> > + application with C++11.
>> >
>> > But when we run the omniORB + application which is compiled with
>> gcc-8.2.0,
>> > application gets crashed because it unable to catch the Exception and
>> lead
>> > into termination.
>> >
>> > *Log snippet:*
>> >
>> > omniORB: (3) 2019-11-04 03:14:00.589286: throw giopStream::CommFailure
>> from
>> > giopStream.cc:808(0,NO,COMM_FAILURE_UnMarshalArguments)
>> >
>> > terminate called after throwing an instance of
>> > 'omni::giopStream::CommFailure'
>> >
>> > IOT/Abort trap (core dumped)
>> >
>> > *Crash Stack:*
>> >
>> > ---------- tid# 53018837 (pthread ID:   3599) ----------
>> >
>> > 0x090000000056f910  _p_nsleep(??, ??) + 0x10
>> >
>> > 0x0900000000038e64  nsleep(??, ??) + 0xe4
>> >
>> > 0x090000000015dc08  sleep(??) + 0x88
>> >
>> > 0x0000000100612310
>> >
>> _ZN12_GLOBAL__N_115Unix_SigHandler13processSignalEPNS_15Unix_SigDetailsEN4csys9SigActionE.isra.0(??,
>> > ??, ??) + 0x348
>> >
>> > 0x0000000100612c50  handleSignalFatal(??, ??, ??) + 0x28
>> >
>> > <signal>
>> >
>> > 0x090000000056ff14  pthread_kill(??, ??) + 0xd4
>> >
>> > 0x090000000056f764  _p_raise(??) + 0x44
>> >
>> > 0x09000000000393e8  raise(??) + 0x48
>> >
>> > 0x0900000000055de4  abort() + 0xc4
>> >
>> > 0x0000000100171fa4  _ZN12_GLOBAL__N_115catch_terminateEv() + 0xbc
>> >
>> > 0x00000001000189a4  _ZN10__cxxabiv111__terminateEPFvvE(??) + 0x24
>> >
>> > 0x00000001000090e0  _ZSt9terminatev() + 0x14
>> >
>> > 0x00000001000185e4  __cxa_throw(??, ??, ??) + 0x6c
>> >
>> > 0x0000000101db4e20
>> >
>> _ZN4omni10giopStream11CommFailure6_raiseEjN5CORBA16CompletionStatusEbPKcjS5_PNS_10giopStrandE(??,
>> > ??, ??, ??, ??, ??, ??) + 0x1dc
>> >
>> > 0x00000001025ddf30
>> >
>> _ZN4omni10giopImpl1230unmarshalWildCardRequestHeaderEPNS_10giopStreamE(??)
>> > + 0x108
>> >
>> > 0x00000001025de2c4
>> > _ZN4omni10giopImpl1217inputMessageBeginEPNS_10giopStreamEPFvS2_E(??,
>> ??) +
>> > 0x1d4
>> >
>> > 0x0000000101db1b40  _ZN4omni6GIOP_S10dispatcherEv(??) + 0x88
>> >
>> > 0x0000000101daef3c  _ZN4omni10giopWorker7executeEv(??) + 0x60
>> >
>> > 0x0000000101d9c36c  _ZN15omniAsyncWorker8real_runEv(??) + 0xfc
>> >
>> > 0x0000000101d9dfc0
>> > _ZN19omniAsyncPoolServer9workerRunEP15omniAsyncWorker(??, ??) + 0x74
>> >
>> > 0x0000000101d9be10  _ZN15omniAsyncWorker7mid_runEv(??) + 0x74
>> >
>> > 0x0000000101d9d9c8  _ZN15omniAsyncWorker3runEPv(??, ??) + 0x134
>> >
>> > 0x0000000101cf972c  omni_thread_wrapper(??) + 0x170
>> >
>> > 0x0900000000557e10  _pthread_body(??) + 0xf0
>> >
>> >
>> >
>> > Actually this exception should get caught and ignored quietly in the
>> catch
>> > block below,
>> >
>> > omniORB-4.2.0/src/lib/omniORB/orbcore/GIOP_S.cc
>> >
>> > CORBA::Boolean
>> >
>> > GIOP_S::dispatcher() {
>> >
>> > ……
>> >
>> >    catch(const giopStream::CommFailure&) {
>> >
>> >      return 0;
>> >
>> >    }
>> >
>> > }
>> >
>> > This exception gets caught properly with the above catch when we compile
>> > and run using gcc-4.8.3.
>> >
>> > Catch block does not get effect when we run the application which is
>> > compiled with gcc-8.2.0.
>> >
>> > To understand that weather is this because of type issue, we tried with
>> > handling all types of exceptions “catch(…)”. but that is also not
>> working.
>> >
>> >
>> >
>> > To isolate the issue, we compiled the example code (call_back) of
>> omniORB
>> > library with gcc-8.2.0 and tested it. Observed the same termination on
>> > throwing exception.
>> >
>> > To make sure the example code is works fine with gcc-4.8.3, we compiled
>> the
>> > example with gcc-4.8.3 and observed that is working properly without
>> > termination.
>> >
>> >
>> >
>> > Also we looked into gcc page and tried the below options.
>> >
>> > https://gcc.gnu.org/install/configure.html
>> >
>> > aix - AIX thread support.
>> >
>> > Posix - Generic POSIX/Unix98 thread support.
>> >
>> >
>> >
>> > Recompiled gcc-8.2.0 with option “--enable-threads=lib” (lib as “aix”
>> and
>> > “posix”) and again built omniORB example with this rebuilt gcc-8.2.0.
>> >
>> > But observed the same issue. We got the issue with omniORB + gcc-8.2.0
>> > built with option “--enable-threads=aix” and then rebuilt with option
>> > “--enable-threads=posix”.
>> >
>> >
>> >
>> > Also we compiled omniORB with gcc-8.2.0 with C++17 and observed the same
>> > termination.
>> >
>> >
>> >
>> > OmniORB-4.2.0 (omniORB-4.2.0.tar.bz2
>> > <
>> https://sourceforge.net/projects/omniorb/files/omniORB/omniORB-4.2.0/omniORB-4.2.0.tar.bz2/download
>> >)
>> > library is an open source library. We can download it from here,
>> >
>> > https://sourceforge.net/projects/omniorb/files/omniORB/omniORB-4.2.0/
>> >
>> > Example code is in the path omniORB-4.2.0/src/examples/call_back
>> >
>> >
>> > Could you please guide us to fix this issue? Please download the omniORB
>> > and build the source and examples to reproduce the issue.
>> >
>> >
>> >
>> > Thanks & Regards,
>> >
>> > P. Prasath.
>> >
>>
>