Homebrew-core: macOS Catalina tracking bug

Created on 1 Oct 2019 · 18Comments · Source: Homebrew/homebrew-core

Maintainers will use this issue to record our collective progress in understanding, reporting and fixing Catalina-related bugs.

Dear Homebrew users: please file a separate issue (with template filled with information) for Catalina issues not already know.

10.15 outdated

Source

fxcoudert

😄1

Most helpful comment

Spidermonkey

Same libdyld.dylib stack_not_16_byte_aligned_error as everything else.

Can be worked around using -fno-stack-check as well. I've included a simple diff for anyone wanting to build it from source in the short term.

diff --git a/Formula/spidermonkey.rb b/Formula/spidermonkey.rb
index cc497a2..30e88d3 100644
--- a/Formula/spidermonkey.rb
+++ b/Formula/spidermonkey.rb
@@ -21,6 +21,7 @@ class Spidermonkey < Formula
   conflicts_with "narwhal", :because => "both install a js binary"

   def install
+    ENV.append "CXXFLAGS", "-fno-stack-check"
     cd "js/src" do
       # Remove the broken *(for anyone but FF) install_name
       inreplace "config/rules.mk",

davisp on 25 Oct 2019

👍3

All 18 comments

gawk

Builds fine, but has a test failure, which boils down to a tty issue:

% cat toto.awk 
BEGIN   {
    c = "echo 123 > /dev/tty; read x < /dev/tty; echo \"x is $x\""
    PROCINFO[c, "pty"] = 1
    c |& getline; print
    print "abc" |& c
    c |& getline; print
}
% ../gawk -f toto.awk
gawk: toto.awk:4: fatal: could not open `/dev/ttys001', mode `r+'

fxcoudert on 1 Oct 2019

libbluray

Compilation with Xcode 11 leads to segmentation fault, due to stack alignment issue. Reported upstream: https://code.videolan.org/videolan/libbluray/issues/20

Can be worked around with -fno-stack-check

This could either be a) Xcode 11's clang is exposing a latent bug in stack alignment, b) Xcode 11's clang generates wrong code.

fxcoudert on 1 Oct 2019

x265

Has the same stack alignment issue, with a runtime segfault in libdyld.dylib`stack_not_16_byte_aligned_error.

Process 32849 launched: '/usr/local/Cellar/x265/3.2/bin/x265' (x86_64)
Process 32849 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
    frame #0: 0x00007fff6a103476 libdyld.dylib`stack_not_16_byte_aligned_error
libdyld.dylib`stack_not_16_byte_aligned_error:
->  0x7fff6a103476 <+0>: movdqa %xmm0, (%rsp)
    0x7fff6a10347b <+5>: int3   
    0x7fff6a10347c <+6>: nop    
    0x7fff6a10347d <+7>: nop    
Target 0: (x265) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
  * frame #0: 0x00007fff6a103476 libdyld.dylib`stack_not_16_byte_aligned_error
    frame #1: 0x00007ffeefbff9e0
    frame #2: 0x00007fff6a112405 libdyld.dylib`start + 1
    frame #3: 0x00007fff6a112405 libdyld.dylib`start + 1

Reported upstream: https://bitbucket.org/multicoreware/x265/issues/514/wrong-code-generated-on-macos-1015

fxcoudert on 1 Oct 2019

Tiger VNC

The 64-bit tiger-vnc build displays the vnc decktop in physical pixels, not virtual pixels. That means on a Retina MacBook, everything is really tiny. The details are in this discussion at the TigerVnc site:
https://groups.google.com/d/topic/tigervnc-users/duY3xPFdx10/discussion
The root cause is a bug in the 1.3.5 FLTK package used by homebrew. The TigerVnc folks suggest building with an earlier version of FLTK.

sockpup on 8 Oct 2019

jq + oniguruma

jq segfaults when using oniguruma:

$ jq --null-input '"foo" | sub("foo";"bar")'
zsh: segmentation fault  jq --null-input '"foo" | sub("foo";"bar")'

core dumps show that this is failing in the match_at() function in oniguruma.

spikegrobstein on 8 Oct 2019

@spikegrobstein jq: Can you reinstall from source (brew reinstall -s jq oniguruma) and confirm whether the bug is still present?

@sockpup TigerVNC: this should be filed as a bug in FLTK. We are not going to ship an older version, but we might ship a patched version once a fix is known. As far as I know, none of the TigerVNC users or developers filed the bug to FLTK, however…

fxcoudert on 9 Oct 2019

Still happens with reinstall from source:

$ brew reinstall jq oniguruma -s
==> Reinstalling jq 
==> Downloading https://github.com/stedolan/jq/releases/download/jq-1.6/jq-1.6.t
==> Downloading from https://github-production-release-asset-2e65be.s3.amazonaws
######################################################################## 100.0%
==> ./configure --disable-silent-rules --disable-maintainer-mode --prefix=/usr/l
==> make install
🍺  /usr/local/Cellar/jq/1.6: 18 files, 1MB, built in 27 seconds
==> Reinstalling oniguruma 
==> Downloading https://github.com/kkos/oniguruma/releases/download/v6.9.3/onig-
==> Downloading from https://github-production-release-asset-2e65be.s3.amazonaws
######################################################################## 100.0%
==> ./configure --prefix=/usr/local/Cellar/oniguruma/6.9.3
==> make install
🍺  /usr/local/Cellar/oniguruma/6.9.3: 17 files, 1.3MB, built in 15 seconds
$ jq --null-input '"foo" | sub("foo";"bar")'
zsh: segmentation fault  jq --null-input '"foo" | sub("foo";"bar")'

I did discover that the statically compiled macOS binary that is distributed by the jq folks does not exhibit this behaviour, so I'm not sure what exactly they did differently besides statically compile it.

spikegrobstein on 9 Oct 2019

Perhaps upstream compiles it with their own vendored oniguruma instead of the latest and greatest. (I.e., --with-oniguruma-builtin.)

chdiza on 9 Oct 2019

libx264
With ffmpeg run:
ffmpeg -i input.mp4 output.mp4

has error:
[libx264 @ 0x7f89bd004600] using SAR=1/1 Segmentation fault: 11

mike667 on 10 Oct 2019

👍1

Same alignment issue with libsodium:

https://forums.developer.apple.com/thread/121887

jedisct1 on 11 Oct 2019

👍2

Status update on our most-used formulas that are still misbehaving on Catalina:

doxygen (and a lot of other formulas) fail to bottle due to a tar bug: https://github.com/Homebrew/brew/issues/6539
luajit memory issue, reported upstream: https://github.com/LuaJIT/LuaJIT/issues/521
ghc also has a memory issue: https://gitlab.haskell.org/ghc/ghc/issues/17353
macvim has a new version which works on Catalina, but fails on Mojave: https://github.com/Homebrew/homebrew-core/pull/45455
git-lfs needs an update, but the update fails to build: https://github.com/Homebrew/homebrew-core/pull/45467
carthage is hit by a compiler bug, upstream has a fix: https://github.com/Carthage/Carthage/pull/2859
ios-deploy has a fix, which will be in the upcoming release: https://github.com/ios-control/ios-deploy/commit/3ad1c32ad1bccb27716eeda3b5e3f4cc8f5cf065
unison issue is not Catalina-specific, but due to update of ocaml; fixing here https://github.com/Homebrew/homebrew-core/pull/45560

fxcoudert on 19 Oct 2019

salt fails because of problem with /usr/lib/libcrypto.dylib: https://github.com/saltstack/salt/issues/55084

bayandin on 22 Oct 2019

tiger-vnc is unusable as far as I can tell: it shows the screen halve sized, but mouse input is mapped to normal size, i.e. its basically impossible to click on anything

maddanio on 25 Oct 2019

Spidermonkey

Same libdyld.dylib stack_not_16_byte_aligned_error as everything else.

Can be worked around using -fno-stack-check as well. I've included a simple diff for anyone wanting to build it from source in the short term.

diff --git a/Formula/spidermonkey.rb b/Formula/spidermonkey.rb
index cc497a2..30e88d3 100644
--- a/Formula/spidermonkey.rb
+++ b/Formula/spidermonkey.rb
@@ -21,6 +21,7 @@ class Spidermonkey < Formula
   conflicts_with "narwhal", :because => "both install a js binary"

   def install
+    ENV.append "CXXFLAGS", "-fno-stack-check"
     cd "js/src" do
       # Remove the broken *(for anyone but FF) install_name
       inreplace "config/rules.mk",

davisp on 25 Oct 2019

👍3

-fno-stack-check should really be applied to all formulas until the bug is fixed.

jedisct1 on 25 Oct 2019

@maddanio has this been reported to Tiger-VNC and can you give us a link to that bug report?

@davisp can you create a pull request for that please? (make it conditional on DevelopmentTools.clang_build_version >= 1010, see how other formulas do it)

fxcoudert on 26 Oct 2019

There is a trail of tickets around this
https://github.com/TigerVNC/tigervnc/issues/805 describes it
This also
https://github.com/feenkcom/gtoolkit/issues/215
Here the culprit is identified as fltk 1.3.5, using the 1.3.4 should fix:
https://github.com/Homebrew/homebrew-core/issues/37872#issuecomment-479995759
Not sure if maybe fltk is just used wrong via gtoolkit?
https://www.fltk.org/doc-1.3/osissues.html#osissues_macos
Also
https://github.com/TigerVNC/tigervnc/issues/867
Can’t find a ticket with fltk yet

maddanio on 26 Oct 2019

Re. Tiger VNC bug: (which is not specific to Catalina at all… let's try to stop this discussion here)

Either that bug was introduced in FLTK 1.3.5 (and should be fixed in FLTK), or TigerVNC is not using the FLTK 1.3.5 API correctly (which should be fixed in TigerVNC).

We have in Homebrew a some other widely-used FLTK-based formulas, which seem to be working fine, so I would suggest maybe it's the later.

In any case, we are not switching back to an older FLTK. If a patch is created for either formula, we will consider using it.

fxcoudert on 27 Oct 2019

Was this page helpful?

0 / 5 - 0 ratings