Re: Exception not caught with gcc-8.2.0

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux