[Tsan] Fix the signal_recursive.cc test to build on FreeBSD

[emaste]

test/tsan/signal_recursive.cc

14–18

Is the specific signal of interest here, or do we just need two arbitrary signals? If the latter, can we just use SIGUSR1 instead?

[kutuzov.viktor.84]

test/tsan/signal_recursive.cc

14–18

To me they look like two arbitrary "informative" signals that do not need any special handling. From this point of view, SIGINFO may be somewhat more expressive than SIGUSR1, but I'm not sure.

Dmitry, can you please let us know if SIGPWR and SIGXCPU have been chosen for a reason?

[dvyukov]

These weird signals were copied from a user bug report. You, you can just replace them with SIGUSR1/2.

[kutuzov.viktor.84]

Reworked to use SIGUSR1/2 signals.

[dvyukov]

LGTM

[emaste]

LGTM

Closed by commit rL220550 (authored by vkutuzov).

test/tsan/signal_recursive.cc

 // RUN: %clang_tsan -O1 %s -o %t && %run %t 2>&1 | FileCheck %s
 
 // Test case for recursive signal handlers, adopted from:
 // https://code.google.com/p/thread-sanitizer/issues/detail?id=71
 
 #include <pthread.h>
 #include <semaphore.h>
 #include <signal.h>
 #include <unistd.h>
 #include <errno.h>
 #include <stdlib.h>
 #include <stdio.h>
 
-static const int kSigSuspend = SIGPWR;
-static const int kSigRestart = SIGXCPU;
+static const int kSigSuspend = SIGUSR1;
+static const int kSigRestart = SIGUSR2;
 static sigset_t g_suspend_handler_mask;
 
 static sem_t g_thread_suspend_ack_sem;
 
 static bool g_busy_thread_received_restart;
 
 static volatile bool g_busy_thread_garbage_collected;
 
 static void SaveRegistersInStack() {
   // Mono walks thread stacks to detect unreferenced objects.
   // If last object reference is kept in register the object will be collected