Feature request, warnings for non safe calls within signal handlers

Feature request, warnings for non safe calls within signal handlers

[Jonathan Andrews]

I'm assuming this doesn't already happen, i've not seen it before, the
newest gcc I use is 4.3.2 

Would it be possible to add a warning to gcc C when code in an signal
handler (alarm) uses non thread safe calls.

My documentation for linux is old enough it has zero warning other than
a possible interaction between alarm() and sleep().

I've found the information I need in the signal man page from an updated
debian, but this is largely news to me :-(

I filed this report:
http://sourceware.org/bugzilla/show_bug.cgi?id=13845


Gcc's own documentation is incomplete on the subject

The example here risks not just printing incorrect values but stopping
completely waiting in a futex forever.
http://www.gnu.org/software/libc/manual/html_node/Non_002datomic-Example.html#Non_002datomic-Example

No warning here
http://www.gnu.org/software/libc/manual/html_node/Setting-an-Alarm.html

Typical alarm example, also not safe
http://www.ccplusplus.com/2011/10/alarm-function-example-in-c.html


http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_04

"unspecified" is a very vague warning.  Its sometimes acceptable for
something to give the wrong answer for its output but its never
acceptable for a process to stall and never resume.  If this kind of
thing is the outcome then gcc needs to babysit me more :-)

Thanks,
Jon

Re: Feature request, warnings for non safe calls within signal handlers

[Ian Lance Taylor]

Jonathan Andrews <jon@jonshouse.co.uk> writes:

> Would it be possible to add a warning to gcc C when code in an signal
> handler (alarm) uses non thread safe calls.

It would be fairly hard to do this in a useful way.  A signal handler
could call a function defined in some other file.  If the compiler can't
see that function, it would not be able to warn about that function or
any functions that it might call.  So the best we could do is warn about
system functions that are known to be non-async-signal-safe.

Even that set is hard to determine.  There are some functions that older
versions of the POSIX standard considered to be async-signal-safe that
newer versions do not consider to be safe.  And standards aside, the
exact set depends on your operating system, and in fact on the exact
version of your operating system.


> Gcc's own documentation is incomplete on the subject

Well, it's not really a compiler issue.


> The example here risks not just printing incorrect values but stopping
> completely waiting in a futex forever.
> http://www.gnu.org/software/libc/manual/html_node/Non_002datomic-Example.html#Non_002datomic-Example
>
> No warning here
> http://www.gnu.org/software/libc/manual/html_node/Setting-an-Alarm.html

Here you are talking about glibc, which is a different project
maintained by different people.


> http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_04
>
> "unspecified" is a very vague warning.  Its sometimes acceptable for
> something to give the wrong answer for its output but its never
> acceptable for a process to stall and never resume.  If this kind of
> thing is the outcome then gcc needs to babysit me more :-)

Calling a non-async-signal-safe function is not "unspecified," it is
"undefined."  In a standard, "undefined" is a term of art: it means that
absolutely anything can happen, which certainly includes having the
program stop and never resume.


Your request for a warning is reasonable, I just don't see a way to
implement it such that it is useful.

Ian

Re: Feature request, warnings for non safe calls within signal handlers

[Jens Bauer]

Hi Jon and Ian,

On Wed, 14 Mar 2012 19:54:48 -0700, Ian Lance Taylor wrote:
> Jonathan Andrews <jon@jonshouse.co.uk> writes:
> 
>> Would it be possible to add a warning to gcc C when code in an signal
>> handler (alarm) uses non thread safe calls.
> 
> Your request for a warning is reasonable, I just don't see a way to
> implement it such that it is useful.

I like that idea.
When compiling applications on Apple's Mac OS X, they have keywords to inform about "deprecated" functions at compile-time.
A similar solution might be possible, providing that the authors of the libraries and functions being called, mark those as "thread_safe" or "interrupt_safe".
Ofcourse, a compiler might be able to recursively go through functions and hunt for things that identifies whether or not a function is thread-safe, a'la the optimizer, however at present, this might be too complex.

It would, for instance be a bit difficult to see whether a function that writes to a shared memory location is thread-safe, because writing to this location *could* be a semaphore or behind a semaphore.

Note: Remember there's a difference between thread-safe and interrupt-safe. Whether or not I should mention 'reentry-safe' or not, I don't know.. Well, hereby done. ;)


Love,
Jens

Re: Feature request, warnings for non safe calls within signal handlers

[David Brown]

On 15/03/2012 06:01, Jens Bauer wrote:
> Hi Jon and Ian,
>
> On Wed, 14 Mar 2012 19:54:48 -0700, Ian Lance Taylor wrote:
>> Jonathan Andrews<jon@jonshouse.co.uk>  writes:
>>
>>> Would it be possible to add a warning to gcc C when code in an
>>> signal handler (alarm) uses non thread safe calls.
>>
>> Your request for a warning is reasonable, I just don't see a way
>> to implement it such that it is useful.
>
> I like that idea. When compiling applications on Apple's Mac OS X,
> they have keywords to inform about "deprecated" functions at
> compile-time. A similar solution might be possible, providing that
> the authors of the libraries and functions being called, mark those
> as "thread_safe" or "interrupt_safe". Ofcourse, a compiler might be
> able to recursively go through functions and hunt for things that
> identifies whether or not a function is thread-safe, a'la the
> optimizer, however at present, this might be too complex.
>
> It would, for instance be a bit difficult to see whether a function
> that writes to a shared memory location is thread-safe, because
> writing to this location *could* be a semaphore or behind a
> semaphore.
>
> Note: Remember there's a difference between thread-safe and
> interrupt-safe. Whether or not I should mention 'reentry-safe' or
> not, I don't know.. Well, hereby done. ;)
>

Your final paragraph here gives some hints about the size of this idea - 
both in its potential usefulness, and in the work required to implement 
it.  Trying to implement some sort of checking for "signal handler safe" 
or "thread safe" or "interrupt safe" functions is a waste of effort.  It 
would have to be much more general to be effective - then "interrupt 
safe" or "signal handler safe" would simply be a specialisation of the 
concept.

What you need here is a way of tagging the compilation state with some 
sort of attributes, and a way of having functions and other parts of the 
code check those attributes for particular features.  These features 
must be definable in the user code, not just in the compiler, so they 
should probably have string names and integer values.  So then you'd 
have things like this:

__require_tag("gotLock1")
void foo(void) { ... code assuming lock1 is acquired .... }

void bar(void) {
	getLock(lock1);
	__set_tag("gotLock1");
	foo();
	__unset_tag("gotLock1");
	releaseLock(lock1);
}

Trying to call "foo" from code that has not set the "gotLock1" tag will 
give an error or warning.

Once you have this idea, there are all sorts of possibilities.  Some of 
these include:

Alternative paths in functions depending on the tags (if you have the 
"interruptsDisabled" tag on a single-processor system, then you can take 
short-cuts when accessing "atomic" data).  Or the "foo" function could 
be made to acquire and release the lock if needed.  This would be 
particularly efficient in inline functions.

Functions could affect the tags of their callers - "getLock" could set a 
tag on return.

You could use tags to say that "lock1" was always needed before getting 
"lock2" - thus spotting ordering errors that could lead to deadlocks.

You could have "unsafe" functions, that may only be called by code that 
sets the "unsafe" tag.  This could easily be combined with code 
development policies, such as requiring extra code reviews for anything 
"unsafe".

Code that must be run on a particular cpu in an SMP system could be tagged.

There are lots of uses for embedded systems and odd processors.  For 
example, on the msp430, gcc disables interrupts whenever it needs to use 
the hardware multiplier.  With an "interruptsDisabled" tag, it could 
generate smaller and faster code in some situations.


The potential for such a tag system is enormous, both for enhancing 
warning and error checking, and thus code quality, and for generating 
smaller and faster object code.  But it would also take a great deal of 
effort to come up with a flexible, consistent and workable syntax for 
the system.

As for implementation, I think it would be possible to come a long way 
by using a pre-preprocessor, as I think it would all be handled in a 
single compilation unit at a time.  In particular, any tag requirements 
for a function or code would be specified in the function declaration, 
not the definition.


mvh.,

David

Re: Feature request, warnings for non safe calls within signal handlers

[Jonathan Wakely]

On 15 March 2012 09:36, David Brown wrote:
> What you need here is a way of tagging the compilation state with some sort
> of attributes, and a way of having functions and other parts of the code
> check those attributes for particular features.  These features must be
> definable in the user code, not just in the compiler, so they should
> probably have string names and integer values.
[snip]

You might be interested in http://www.artima.com/cppsource/codefeatures.html

I believe the polynomial increases in compilation times and the need
for the global "AllCodeFeatures" container are solvable in C++11, e.g.
by using a variadic class template to represent compile-time strings,
which could be compared and sorted at compile-time to provide a total
order without needing all features to be known a priori.

But that's straying off-topic for this list.

Re: Feature request, warnings for non safe calls within signal handlers

[David Brown]

On 15/03/2012 10:58, Jonathan Wakely wrote:
> On 15 March 2012 09:36, David Brown wrote:
>> What you need here is a way of tagging the compilation state with some sort
>> of attributes, and a way of having functions and other parts of the code
>> check those attributes for particular features.  These features must be
>> definable in the user code, not just in the compiler, so they should
>> probably have string names and integer values.
> [snip]
>
> You might be interested in http://www.artima.com/cppsource/codefeatures.html
>
> I believe the polynomial increases in compilation times and the need
> for the global "AllCodeFeatures" container are solvable in C++11, e.g.
> by using a variadic class template to represent compile-time strings,
> which could be compared and sorted at compile-time to provide a total
> order without needing all features to be known a priori.

Thanks for that link.  I have seen the use of C++ templates before for 
this sort of idea (in particular, I have seen it for enforcing ordering 
of locks).  Obviously it has the big advantage of being implemented 
within the existing tools.  But the restriction to C, the ugly syntax 
(templates are useful, but not pretty), and the compile-time overhead 
make them a poor choice here.

Maybe the practical answer is to do this sort of checking independently 
of the compiler, somewhat akin to other static error checking.

 >
 > But that's straying off-topic for this list.