write(2) called from within signal handler is flagged as unsafe?

[r...@newrelic.com]

On linux, in a simple test program, I send myself a signal; which is caught by a signal handler. The signal handler calls write(2).

The tsan runtime (both clang and gcc 4.9.1 build binaries) complains:

WARNING: ThreadSanitizer: signal-unsafe call inside of a signal (pid=26847)

    #0 write <null>:0 (backtrace+0x00000002af4b)

    #1 sigusr1_handler(int) /home/rrh/play.d/tsan/backtrace.cpp:13 (backtrace+0x00000006f04d)

    #2 rtl_sighandler(int) <null>:0 (backtrace+0x00000001c4aa)

    #3 main /home/rrh/play.d/tsan/backtrace.cpp:21 (backtrace+0x00000006f08b)

I'm confused, since the man page for signal

   http://man7.org/linux/man-pages/man7/signal.7.html

states that write() must be safely callable  from within a signal handler.

[Dmitry Vyukov]

Hi,

Can you show the reproducer?

> --
> You received this message because you are subscribed to the Google Groups
> "thread-sanitizer" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to thread-sanitiz...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[r...@newrelic.com]

Attached is a small program "backtrace.cpp" that shows the issue.

[Dmitry Vyukov]

Thanks!
I see the bug in tsan now.

[Dmitry Vyukov]

Fixed by http://llvm.org/viewvc/llvm-project?view=revision&revision=219784
I've added the test so that it doesn't break in future.
Thanks again!

[r...@newrelic.com]

I'm happy to help.

How/when does this change percolate out to gcc?

There's a whole bunch of syscalls that are legal from the context of a signal handler.  I'm wondering if any of the others will also have similar problems.

[Dmitry Vyukov]

On Wed, Oct 15, 2014 at 6:28 PM, <r...@newrelic.com> wrote:
> I'm happy to help.
>
> How/when does this change percolate out to gcc?

Do you mean gcc tip or release?
If release, then I guess it will be the next release.

> There's a whole bunch of syscalls that are legal from the context of a
> signal handler. I'm wondering if any of the others will also have similar
> problems.

I"ve fixed a common source of such false positives. All operations on
file descriptors were affected.
I've greped sources for similar issues and did not found any.