[PATCH] D124607: Add an error message to the default SIGPIPE handler

[Nemanja Ivanovic via Phabricator via llvm-commits]

nemanjai added a comment.

In D124607#3515118 <https://reviews.llvm.org/D124607#3515118>, @dmcyk wrote:

> @t.p.northover made the commit, but it broke clang-ppc64le-linux-multistage buildbot <https://lab.llvm.org/buildbot/#/builders/121/builds/19309>, so it's been reverted.
> In the test the input to FileCheck was empty, so maybe the signal handler didn't trigger for some reason.
>
> The test does work on x86 Linux and macOS, so I've tried a ppc64le VM running CentOS 8.
> The VM is too slow to compile the entire llvm, but I've tested a simple program with a SIGPIPE signal handler, the same python script and that worked as expected.
> So the failure seems to be specific to RHEL or the buildbot environment. Maybe someone from #powerpc <https://reviews.llvm.org/tag/powerpc/> can help test this?

The issue does not seem to be related to PowerPC. The problem appears to be that `llvm-nm` finishes writing too fast for this to trigger the signal handler. With a shared library build (such as this bot), there are only 551 lines of output when running `$LLVM_BUILD/bin/llvm-nm $LLVM_BUILD/bin/llvm-nm`. That does not appear to be enough. You can either run a tool that runs longer or run `llvm-nm` with something that produces more output. When sorting for length of the output of `llvm-nm` for all the binaries in the `bin` directory, it appears that `llvm-tblgen` is among the longest ones. And certainly, if I change:

  # RUN: not %python %s llvm-nm llvm-nm 2>&1 | FileCheck %s

to

  # RUN: not %python %s llvm-nm llvm-tblgen 2>&1 | FileCheck %s

The test case succeeds. However, it would probably be ideal to devise a way to test this in a way that is guaranteed to invoke the signal handler.
It's up to you how you want to approach this.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D124607/new/

https://reviews.llvm.org/D124607