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@xxxxxxxxxxxx> 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. > > >
