exception in art v2
Dear art experts,
while debugging the code, I , and independently, one of my Mu2e colleagues noticed that, unlike art v1,
an art v2-based executable (mu2e) in the very beginning throws an exception, successfully handles it,
and continues. Exception happens before the user code gets executed somewhere in the art internals and
as far as I can tell, it happens for any input .fcl file.
I wonder if this feature is known/needed.
From the user prospective, when encountered for the first time during the debugging session,
this feature is rather confusing: gdb intercepts the exception, and one immediately starts
thinking of a bug in his code. Less experienced people just do not know how to proceed
with the debugging. However, a simple gdb 'continue' helps, so I don't think it is a high
Below is an example of how one can reproduce the issue in the Mu2e environment using
the git head or any of the last tags of the Mu2e offline code.
It would be great if experts could look at it.
------------------------------------------------------------------------------ murat@mu2egpvm04:/mu2e/app/users/murat/mback>gdb GNU gdb (GDB) 7.12 Copyright (C) 2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word". (gdb) file mu2e Reading symbols from mu2e...done. (gdb) set args -c Analyses/test/genReco.fcl -n 10 (gdb) catch throw Catchpoint 1 (throw) (gdb) r Starting program: /cvmfs/mu2e.opensciencegrid.org/artexternals/art/v2_06_02a/slf6.x86_64.e10.debug/bin/mu2e -c Analyses/test/genReco.fcl -n 10 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Catchpoint 1 (exception thrown), __cxxabiv1::__cxa_throw (obj=0x603210, tinfo=0x7fffecfa0840 <typeinfo for int>, dest=0x0) at ../../.././libstdc++-v3/libsupc++/eh_throw.cc:62 62 ../../.././libstdc++-v3/libsupc++/eh_throw.cc: No such file or directory. (gdb) where #0 __cxxabiv1::__cxa_throw (obj=0x603210, tinfo=0x7fffecfa0840 <typeinfo for int>, dest=0x0) at ../../.././libstdc++-v3/libsupc++/eh_throw.cc:62 #1 0x00007fffedccffeb in tbb::internal::gcc_rethrow_exception_broken () at ../../src/tbb/tbb_misc.cpp:188 #2 0x00007fffedcd4208 in tbb::internal::governor::acquire_resources () at ../../src/tbb/governor.cpp:80 #3 0x00007fffedceb196 in tbb::internal::__TBB_InitOnce::add_ref () at ../../src/tbb/tbb_main.cpp:126 #4 0x00007fffedceb9eb in tbb::internal::__TBB_InitOnce::__TBB_InitOnce (this=0x7fffedf17282 <tbb::internal::__TBB_InitOnceHiddenInstance>) at ../../src/tbb/tbb_main.h:71 #5 0x00007fffedceb95f in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at ../../src/tbb/tbb_main.cpp:75 #6 0x00007fffedceb9a9 in _GLOBAL__sub_I_tbb_main.cpp(void) () at ../../src/tbb/tbb_main.cpp:567 #7 0x00007fffedceee86 in __do_global_ctors_aux () from /cvmfs/mu2e.opensciencegrid.org/artexternals/tbb/v2017_3c/Linux64bit+2.6-2.12-e10-debug/lib/libtbb_debug.so.2 #8 0x00007fffedcb4fbb in _init () from /cvmfs/mu2e.opensciencegrid.org/artexternals/tbb/v2017_3c/Linux64bit+2.6-2.12-e10-debug/lib/libtbb_debug.so.2 #9 0x00007fffeccab518 in ?? () #10 0x000000333540e705 in _dl_init_internal () from /lib64/ld-linux-x86-64.so.2 #11 0x0000003335400b3a in _dl_start_user () from /lib64/ld-linux-x86-64.so.2 #12 0x0000000000000005 in ?? () #13 0x00007fffffff7a28 in ?? () #14 0x00007fffffff7a82 in ?? () #15 0x00007fffffff7a85 in ?? () #16 0x00007fffffff7a9f in ?? () #17 0x00007fffffff7aa2 in ?? () #18 0x0000000000000000 in ?? () (gdb) q A debugging session is active. Inferior 1 [process 30974] will be killed. Quit anyway? (y or n) y
#2 Updated by Kyle Knoepfel about 2 years ago
- Category set to Third Party
- Status changed from New to Accepted
- Estimated time set to 2.00 h
We agree that it is bad practice to be using the throwing and catching of exceptions as flow control. However, according to the stack trace you provided, the exception throw/catch is happening at static initialization time of the TBB library. We can investigate to see whether TBB can be built in a way so that such handling of exceptional conditions is avoided.
#3 Updated by Kyle Knoepfel about 2 years ago
- Status changed from Accepted to Resolved
- % Done changed from 0 to 100
The problem is understood. TBB attempts to diagnose and mitigate a GCC standard library bug (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62258) with
std::rethrow_exception(), which is present in versions of GCC older than 6.0. This code is not invoked for later versions of GCC; we have verified this for GCC 6.3 (
e14 qualifier). Despite the inconvenience, the way forward is to upgrade to a newer compiler--specifically, the
e14 builds of