Archived issue #0030541
Draw Harness - impossible disabling signals
Description
OSD::SetSignal() is called unconditionally at Draw Harness startup.
Although this improves application stability, it doesn't allow simply reproducing crashes of applications that doesn't setup OSD::SetSignal().
Hence, it is proposed adding some extra option like CSF_FPE or Draw Harness parameter disabling signals.
Alternatively, new function OSD::UnsetSignal() can be implemented to disarm signals (and extended dsetsignal syntax).
Although this improves application stability, it doesn't allow simply reproducing crashes of applications that doesn't setup OSD::SetSignal().
Hence, it is proposed adding some extra option like CSF_FPE or Draw Harness parameter disabling signals.
Alternatively, new function OSD::UnsetSignal() can be implemented to disarm signals (and extended dsetsignal syntax).
Steps to reproduce
dsetsignal unset
Public activity
2 archived notes
Participants are labeled by their role within this record.
The feature has been implemented within #30775: OSD::SetSignal() has got an option to unset handler instead of setting it. Thus calling DRAW command "dsetsignal unset" you will now get the state of the application with no handlers set. Please review.
Note however that application built on Windows with default option /EHa will be able to catch exceptions in "catch(...)" statement even without application-defined handlers installed. Thus signal like access violation will not kill DRAW.
Note however that application built on Windows with default option /EHa will be able to catch exceptions in "catch(...)" statement even without application-defined handlers installed. Thus signal like access violation will not kill DRAW.
The main purpose is to be able reproducing user reports like #0029979 in Draw Harness, since by default access violations issues are handled as "normal" exceptions by Data Exchange algorithms, so that they are hidden from report (if do not dig deep inside).
Related records