Exception not caught with gcc-8.2.0

Exception not caught with gcc-8.2.0

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

Re: Exception not caught with gcc-8.2.0

[Florian Dörsch]

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

Re: Exception not caught with gcc-8.2.0

[Prasath P]

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

Re: Exception not caught with gcc-8.2.0

[Prasath P]

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

Re: Exception not caught with gcc-8.2.0

[Prasath P]

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.

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@gmail.com> 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@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.
>>> >
>>>
>>

Re: Exception not caught with gcc-8.2.0

[Jonathan Wakely]

On Tue, 4 Aug 2020 at 12:55, Prasath P via Gcc-help
<gcc-help@gcc.gnu.org> 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@gmail.com> 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@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.
> >>> >
> >>>
> >>

Re: Exception not caught with gcc-8.2.0

[Brian Groose]

I'm not q

On Tue, Aug 4, 2020 at 10:17 AM Jonathan Wakely via Gcc-help
<gcc-help@gcc.gnu.org> wrote:
>
> On Tue, 4 Aug 2020 at 12:55, Prasath P via Gcc-help
> <gcc-help@gcc.gnu.org> 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@gmail.com> 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@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.
> > >>> >
> > >>>
> > >>

Re: Exception not caught with gcc-8.2.0

[Brian Groose]

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@groose.com> wrote:
>
> I'm not q
>
> On Tue, Aug 4, 2020 at 10:17 AM Jonathan Wakely via Gcc-help
> <gcc-help@gcc.gnu.org> wrote:
> >
> > On Tue, 4 Aug 2020 at 12:55, Prasath P via Gcc-help
> > <gcc-help@gcc.gnu.org> 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@gmail.com> 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@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.
> > > >>> >
> > > >>>
> > > >>

Re: Exception not caught with gcc-8.2.0

[Jonathan Wakely]

CC David

On Thu, 6 Aug 2020 at 16:28, Brian Groose <brian@groose.com> 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@groose.com> wrote:
> >
> > I'm not q
> >
> > On Tue, Aug 4, 2020 at 10:17 AM Jonathan Wakely via Gcc-help
> > <gcc-help@gcc.gnu.org> wrote:
> > >
> > > On Tue, 4 Aug 2020 at 12:55, Prasath P via Gcc-help
> > > <gcc-help@gcc.gnu.org> 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@gmail.com> 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@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.
> > > > >>> >
> > > > >>>
> > > > >>

Re: Exception not caught with gcc-8.2.0

[Prasath P]

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@gmail.com>
wrote:

> CC David
>
> On Thu, 6 Aug 2020 at 16:28, Brian Groose <brian@groose.com> 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@groose.com> wrote:
> > >
> > > I'm not q
> > >
> > > On Tue, Aug 4, 2020 at 10:17 AM Jonathan Wakely via Gcc-help
> > > <gcc-help@gcc.gnu.org> wrote:
> > > >
> > > > On Tue, 4 Aug 2020 at 12:55, Prasath P via Gcc-help
> > > > <gcc-help@gcc.gnu.org> 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@gmail.com>
> 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@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.
> > > > > >>> >
> > > > > >>>
> > > > > >>
>