Bug 93563 - volatile signal re-enterancy guards ...
Summary: volatile signal re-enterancy guards ...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
Version:
(earliest affected)
5.0.0.0.beta1
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: ToBeReviewed
Keywords: difficultyBeginner, easyHack, skillCpp, topicCleanup
Depends on:
Blocks:
 
Reported: 2015-08-21 07:01 UTC by Michael Meeks
Modified: 2017-02-14 08:57 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Meeks 2015-08-21 07:01:07 UTC
cf. http://www.gnu.org/software/libc/manual/html_node/Nonreentrancy.html#Nonreentrancy

When we have re-enterancy guards in our signal handlers - we should use the 'volatile' keyword eg.

oslSignalAction SAL_CALL VCLExceptionSignal_impl( void* /*pData*/, oslSignalInfo* pInfo)
{
    static bool bIn = false;

    // if we crash again, bail out immediately
    if ( !bIn )


should be static volatile bool bIn = false; =)

It would be good to chase through the code a little bit in this regard as there are several signal handlers that (I suspect) do similar things - and sub-methods that assume similar things.

Thanks !
Comment 1 Robinson Tryon (qubit) 2015-12-10 11:40:59 UTC Comment hidden (obsolete)
Comment 2 Robinson Tryon (qubit) 2016-02-18 14:51:46 UTC Comment hidden (obsolete)
Comment 3 Michael Meeks 2016-05-01 10:20:02 UTC
Lets assume for the sake of argument that the other signal handlers have been reviewed & audited =)
Comment 4 Stephan Bergmann 2016-05-03 08:56:25 UTC
Strictly speaking, variables used to communicate with signal handlers need to be precisely of type "std::sig_atomic_t volatile", not "<arbitrary type> volatile".  And, without further synchronization, they only work within a single thread.  But our signal handlers are operating on very thin ice anyway, as the behavior of anything beyond POF (see C++ Standard's [support.runtime]) is implementation-defined---which would include any synchronization to make such variables accessible across multiple threads.