This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libstdc++/84766] New: __verbose_terminate_handler mistakes parallel unhandled exceptions for recursive std::terminate() calls


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84766

            Bug ID: 84766
           Summary: __verbose_terminate_handler mistakes parallel
                    unhandled exceptions for recursive std::terminate()
                    calls
           Product: gcc
           Version: 7.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: anovak at soe dot ucsc.edu
  Target Milestone: ---

The default terminate handler, __gnu_cxx::__verbose_terminate_handler(), in 
gcc/libstdc++-v3/libsupc++/vterminate.cc, begins thusly:

  void __verbose_terminate_handler()
  {
    static bool terminating;
    if (terminating)
      {
        fputs("terminate called recursively\n", stderr);
        abort ();
      }
    terminating = true;
  ...

The function uses a static bool flag, which it checks. If it is already set, it
knows std::terminate() has already been called, so it complains of a recursive
std::terminate() call and immediately aborts. If it isn't already set, it
continues with printing some exception info before calling abort().

However, this function doesn't seem to handle the case of multiple threads. It
is possible for one thread to have an unhandled exception, causing terminate
(and the handler) to be called, and then for a second thread to also have an
unhandled exception before abort() can stop the process. That second thread
will also call terminate, and the handler will report a "recursive" call to
terminate, even though the call really wasn't recursive. This also prevents the
second thread from outputting a nice formatted exception message.

Can the terminating flag be made thread local? Or can the message be changed to
describe "concurrent" or "reentrant" calls to terminate instead of "recursive"
ones?

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]