runtime: macOS syscall.Exec can get SIGILL due to preemption signal

[ianlancetaylor]

On macOS 10.14 and 10.15 (at least) a Go program calling syscall.Exec can fail due to SIGILL in the newly execed image because of preemption signals.

This is a bug in macOS. Here is a C program that demonstrates the problem. This program will occasionally fail with SIGILL.

For Go, we should have a workaround, which means in syscall.Exec we should disable preemption via signal. We already have hooks that we can use for this (syscall.runtime_BeforeExec and syscall.runtime_AfterExec).

#include <sys/errno.h>
#include <assert.h>
#include <pthread.h>
#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
 
extern char **environ;
 
static pthread_t sleep_thread;
 
void sighandler(int signal) {}
 
void* signal_thread_main(void* unused_args) {
  while (1) {
    int ret = pthread_kill(sleep_thread, SIGURG);
    assert(ret == 0);
  }
  return NULL;
}
 
void* exec_thread_main(void* unused_args) {
  char* exec_args[] = {"/usr/bin/python", "--version", NULL};
  int ret;
 
  ret = execve(exec_args[0], exec_args, environ);
  assert(ret == 0);
  return NULL;
}
 
void* sleep_thread_main(void* unused_args) {
  unsigned int to_sleep = 60;
  while (to_sleep > 0) {
    to_sleep = sleep(to_sleep);
  }
  return NULL;
}
 
int main(int argc, char* argv[]) {
  pthread_t signal_thread, exec_thread;
  int ret;
 
  signal(SIGURG, &sighandler);
 
  ret = pthread_create(&sleep_thread, NULL, &sleep_thread_main, NULL);
  assert(ret == 0);
 
  ret = pthread_create(&signal_thread, NULL, &signal_thread_main, NULL);
  assert(ret == 0);
 
  sleep(1);  // Give signalling time to start                             
  ret = pthread_create(&exec_thread, NULL, &exec_thread_main, NULL);
  assert(ret == 0);
 
  sleep(30);
}

[ianlancetaylor]

@gopherbot Please open backport issues

This issue can cause any Go program that uses syscall.Exec on macOS to crash during the exec. We should backport the fix (when we have it) so that this will work for older releases.

[gopherbot]

Backport issue(s) opened: #41703 (for 1.14), #41704 (for 1.15).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://golang.org/wiki/MinorReleases.

[ianlancetaylor]

FYI, a bug was reportedly filed with Apple at https://feedbackassistant.apple.com/feedback/8759414 (but I can't see that report because I don't have an Apple ID).

[randall77]

I have an Apple ID and I can't see it.
Feedback assistant seems to make things private by default. There are only 15 bugs I have access to, and that can't be all the bugs in existence.

[bcmills]

I have access to the Google Apple account from which the report was filed (obtained for #33041 (comment)) and can confirm that that feedback report describes this issue.

[gopherbot]

Change https://golang.org/cl/262438 mentions this issue: runtime: stop preemption during syscall.Exec on Darwin

[gopherbot]

Change https://golang.org/cl/262717 mentions this issue: [release-branch.go1.15] runtime: stop preemption during syscall.Exec on Darwin

[gopherbot]

Change https://golang.org/cl/262737 mentions this issue: [release-branch.go1.14] runtime: stop preemption during syscall.Exec on Darwin

[gopherbot]

Change https://golang.org/cl/262738 mentions this issue: syscall: use MustHaveExec in TestExec

[gopherbot]

Change https://golang.org/cl/262817 mentions this issue: runtime: wait for preemption signals before syscall.Exec

[rsc]

Reopening until CL 262817 is submitted. (Test is failing right now.)

[gopherbot]

Change https://golang.org/cl/264020 mentions this issue: [possible] syscall: use MustHaveExec in TestExec

[gopherbot]

Change https://golang.org/cl/264021 mentions this issue: [release-branch.go1.14] syscall: use MustHaveExec in TestExec

[gopherbot]

Change https://golang.org/cl/264022 mentions this issue: [release-branch.go1.15] runtime: wait for preemption signals before syscall.Exec

[gopherbot]

Change https://golang.org/cl/264023 mentions this issue: [release-branch.go1.14] runtime: wait for preemption signals before syscall.Exec

[gopherbot]

Change https://golang.org/cl/275293 mentions this issue: runtime: avoid receiving preemotion signal while exec'ing