Hi All, Could you please let us know whether this issue has been resolved? Kindly let us know. Thanks & Regards, P. Prasath On Sun, 21 Mar 2021, 20:18 Prasath P, <ijprasath@xxxxxxxxx> wrote: > Hi All, > > Thanks in Advance. > > As l already said, we have tried with gcc-9.2.0. As per fix https://gcc > .gnu.org/bugzilla/show_bug.cgi?id=85907, it have been fixed in 8.2.0. But > we are facing with 9.2.0 itself. > > Kindly help us with a solution to fix this issue. > > Thanks & Regards, > P. Prasath. > > > > On Thu, Aug 6, 2020 at 10:11 PM Jonathan Wakely <jwakely.gcc@xxxxxxxxx> > wrote: > >> CC David >> >> On Thu, 6 Aug 2020 at 16:28, Brian Groose <brian@xxxxxxxxxx> wrote: >> > >> > I'm not quite sure if this is the same issue, but I logged a bug for a >> > similar issue, including a reference to a gcc patch someone else has >> > made in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85907 >> > >> > I do see that someone says it should be working fine in 8.2.0, but >> > perhaps that's not accurate? >> > >> > On Thu, Aug 6, 2020 at 11:25 AM Brian Groose <brian@xxxxxxxxxx> wrote: >> > > >> > > I'm not q >> > > >> > > On Tue, Aug 4, 2020 at 10:17 AM Jonathan Wakely via Gcc-help >> > > <gcc-help@xxxxxxxxxxx> wrote: >> > > > >> > > > On Tue, 4 Aug 2020 at 12:55, Prasath P via Gcc-help >> > > > <gcc-help@xxxxxxxxxxx> wrote: >> > > > > >> > > > > Hi All, >> > > > > >> > > > > I have tried with gcc-9.2.0 and got into the same issue >> "exception is not >> > > > > caught" which I faced earlier with gcc-8.2.0 but it worked well >> with >> > > > > gcc-4.2.3. >> > > > > I have sent multiple reminders and have been waiting for the >> solution >> > > > > earnestly. >> > > > >> > > > It's still a bug, but thanks for the reminders. >> > > > >> > > > > >> > > > > Kindly someone please look into this issue and help me to resolve >> it. >> > > > > >> > > > > Thanks & Regards, >> > > > > P. Prasath. >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > On Tue, Jul 14, 2020 at 11:20 AM Prasath P <ijprasath@xxxxxxxxx> >> wrote: >> > > > > >> > > > > > 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@xxxxxxxxx> >> 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@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. >> > > > > >>> > >> > > > > >>> >> > > > > >> >> >