c++windowswinapicrash-dumpsmsvcrt

CPP Exception handler not called for exceptions during mutex lock


We had a code that created a deadlock as below (simplified version)

std::shared_timed_mutex read_file_mutex;
std::shared_lock<std::shared_timed_mutex> read_file_lock(read_file_mutex
    , std::defer_lock);
if (read_file_lock.try_lock_for(std::chrono::milliseconds(200))) {
  ...
  ...
  if (read_file_lock.try_lock_for(std::chrono::milliseconds(200))) {

The second try_lock throws an exception as expected for resource deadlock from MSVC shared_mutex during validation:

void _Validate() const {
  // check if the mutex can be locked
  if (!_Pmtx)
    _THROW(system_error(
        _STD make_error_code(errc::operation_not_permitted)));
  if (_Owns)
    _THROW(system_error(
        _STD make_error_code(errc::resource_deadlock_would_occur)));
}

Question is when above exception is raised why is it invoking watson handler with invalid parameter exception when we have registered our own invalid parameter exception handler? This is causing the program to terminate without generating crash dump.

We have exception handlers set for UnhandledExceptionFilter, _set_invalid_parameter_handler, _set_purecall_handler, Abort Signal handler etc as mentioned here All other types of exceptions are calling our handlers fine, where we signal a secondary process to generate crash dump. Invalid parameter exception as given in this example also calls our handler just fine.

_invalid_parameter_handler old_handler, new_handler;

SetUnhandledExceptionFilter(&UnhandledExceptionHandler);
new_handler = HandleInvalidParameter;
old_handler = _set_invalid_parameter_handler(new_handler);
_set_purecall_handler(PureVirtualCallHandler);

void (*rv)(int) = signal(SIGABRT, HandleAbortSignal);
_set_abort_behavior(0, 0);
EnableCrashingOnCrashes();
PreventSetUnhandledExceptionFilter();

What is so special about exception from shared_timed_mutex or system_error exceptions? What needs to be done to register the handler for this properly?

Software is 32bit running on 64 bit Windows 10. Compiler used is clang


Solution

  • It turns out disabling cpp exceptions on some applications (which has mix of C/CPP code) causes mixed behaviors in included cpp libraries using exceptions. SOME types of exceptions in these libraries call registered exception handlers properly but some other types of exceptions like system_error do not call registered handlers but invoke watson directly