entr segfaults, but only when built by Homebrew

[mechfish]

The recent v4.9 release of the entr command-line utility surprised me by segfaulting on my machine (2015 MacBook Pro running Mojave) almost, but not quite, every time I run it:

$ ag -l | entr -d echo foo
Segmentation fault: 11

So I downloaded the entr source code directly from Github and built it. The executable I build myself runs fine every time.

I compared my hand-built executable with the one produced by brew reinstall. When I run brew reinstall -s --verbose --debug entr it tells me that it's just running configure and make, just as the original project specifies:

...
==> ./configure
cp Makefile.macos Makefile
==> make
clang  -D_MACOS_PORT -DRELEASE=\"4.9\" missing/fmemopen.c entr.c -o entr 
==> make install
install entr /usr/local/Cellar/entr/4.9/bin
install -m 644 entr.1 /usr/local/Cellar/entr/4.9/share/man/man1
/usr/local/Homebrew/Library/Homebrew/shims/scm/git --version
...

... this produces a file in /usr/local/Cellar/entr/4.9/bin/entr that is 21092 bytes long and segfaults. But when I pull the source from Github outside of brew and run configure followed by the same clang command I get an executable that is 25364 bytes long and seems to work perfectly.

I did check to make sure Homebrew and I are using the same source tarball, and we are. I tried running otool -L on both executables and it gives identical output (both link a single library, /usr/lib/libSystem.B.dylib).

Evidently my invocation of clang is somehow not the same as Homebrew's, despite looking the same as Homebrew's debug output and being generated by the same Makefile. Where in Homebrew do I find the compiler options that are causing it to generate a different executable?

[carlocab]

Looking at the details build log might help. They're probably in ~/Library/Logs/Homebrew/entr.

[mechfish]

Just the info I needed! Lo, there is a file in there called 02.make.cc:

superenv executed: clang -pipe -w -Os -march=nehalem -D_MACOS_PORT -DRELEASE="4.9" missing/fmemopen.c entr.c -o entr -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk --sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk -isystem/usr/local/include -isystem/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/include/libxml2 -isystem/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/System/Library/Frameworks/OpenGL.framework/Versions/Current/Headers -L/usr/local/lib -L/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/System/Library/Frameworks/OpenGL.framework/Versions/Current/Libraries -Wl,-headerpad_max_install_names

I will tinker with all this a bit and see if I can figure out which option is the deadly one.

[mechfish]

Unsurprisingly, the only clang thing I understand – "when in doubt, remove the -O option and try again" – totally worked and builds a working executable.

I will try to figure out how to turn this observation into a proposed patch for the Homebrew formula.

[carlocab]

Try adding

ENV.O0

at the start of the install method in the formula. If building with optimisations breaks the formula this should probably be reported upstream.

[mechfish]

Thanks -- that fixes the formula.

I'll debug upstream next. Maybe the fastest approach to fixing this is to just get an upstream bugfix release.

[mechfish]

After entirely too long a time I figured out the regression in v4.9 of entr and filed an issue upstream: eradman/entr#74

If this doesn't move quickly I'll submit a temporary fix to Homebrew in a day or two.

Thanks for your help in rapidly navigating to the correct logs and settings!