Re: Exception not caught with gcc-8.2.0

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

 



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