Bug 124211 - Poor error-handling when jobserver token acquisition fails
Summary: Poor error-handling when jobserver token acquisition fails
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: driver (show other bugs)
Version: 16.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: lto
Depends on:
Blocks:
 
Reported: 2026-02-23 11:08 UTC by Sam James
Modified: 2026-02-23 12:22 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2026-02-23 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sam James 2026-02-23 11:08:54 UTC
In opts-common.cc:

bool
jobserver_info::get_token ()
{
  int fd = pipe_path.empty () ? rfd : pipefd;
  char c;
  unsigned n = read (fd, &c, 1);
  if (n != 1)
    {
      gcc_assert (errno == EAGAIN);
      return false;
    }
  else
    return true;
}

We've had cases where that errno is something else. This leads to an ICE if the jobserver (from MAKEFLAGS="--jobserver-auth=fifo:/dev/foo") is in any way unreadable (e.g. doesn't exist or bad permissions).

Unfortunately, connect doesn't check for an error on open either which makes this worse (the assert would probably be okay otherwise):

void
jobserver_info::connect ()
{
  if (!pipe_path.empty ())
    {
#if HOST_HAS_O_NONBLOCK
      pipefd = open (pipe_path.c_str (), O_RDWR | O_NONBLOCK);
      is_connected = true;
#else
      is_connected = false;
#endif
    }
  else
    is_connected = true;
}
Comment 1 Richard Biener 2026-02-23 12:22:00 UTC
IMO fatal_error is the prefered way to deal with these kind of errors (when recovery otherwise isn't easily possible, like by running single-threaded?)