Open redspot opened 6 months ago
I don't know why all of the Markdown blocks got flipped around.
Here are the related issues and comment:
patchelf.rb
bughttps://github.com/Homebrew/homebrew-core/issues/132852#issuecomment-1579977482
This issue seems related: https://github.com/Homebrew/homebrew-core/issues/136432
I think the root cause related to many homebrew Linux segmentation faults is the homebrew build bot.
The build bot making the bottles is still somehow using an older patchelf.rb
which causes elf binaries to be generated with improper segments causing memory map collisions.
Latest patchelf updates in brew: https://github.com/Homebrew/brew/pull/16694 https://github.com/Homebrew/brew/pull/14094
Most issues have been fixed with version 1.4.0 in Nov. 2022.
Why do you think it's still using an old patchelf.rb version?
In your config:
Core tap last commit: 3 months ago
This looks old. Can you update first?
Latest patchelf updates in brew: Homebrew/brew#16694 Homebrew/brew#14094
Most issues have been fixed with version 1.4.0 in Nov. 2022.
Why do you think it's still using an old patchelf.rb version?
It's not an issue with patchelf.rb
. It's an issue with the pre built bottles.
See above the part with brew reinstall --force-bottle ssdeep
which segfaults, but works fine when built from source.
In your config:
Core tap last commit: 3 months ago
This looks old. Can you update first?
How do I do that?
I ran brew update --auto-update
with no output given.
How do I do that?
HOMEBREW_NO_INSTALL_FROM_API=1 brew update
should do the necessary.
Don't worry about the 3 months old update message: you are now using the API to get the latest version, so I guess no need to update the git repo on your computer to get the latest version. I think that message is confusing, I'll have a look into it later.
I think I know what happened.
patchelf
was updated in Nov 2022, but I did not realise patchelf was only updated 1 week ago in brew ...
We will have to rebuild these bottles.
I have triggered a ssdeep
rebuild: https://github.com/Homebrew/homebrew-core/actions/runs/8060846410
Once this is done, you can brew update
, and the brew reinstall ssdepp
and try the new bottle.
Sounds great. There are several other bottles with crashes, such as golang.
👋 Been quietly watching this and previous issues.
In WSL Ubuntu this is pretty wide spread from packages built with go and those that are built with gcc. I believe I saw less issues when I tested in a Ubuntu VM.
What could be an effective way forward for the project maintainers? I imagine as the underlying packages upgrade, they'll be rebuilt, so as users, should we just wait? Would the repo owners find a list of affected packages be helpful? I'd be happy to send along the packages I've had issues with and help UAT rebuilds.
@redspot a new ssdeep
bottle has been added. Can you brew update && brew reinstall ssdepp
to confirm that this fixes it for you.
I imagine as the underlying packages upgrade, they'll be rebuilt, so as users, should we just wait? Would the repo owners find a list of affected packages be helpful?
Yes, if you have a list, we can at least rebuild all of these. Most packages get updates / rebuilds at least once per year, but some others will take time to get update. Let's fix what is known to be broken.
Here's a list from my bash/zsh history, though I think I had an issue with every package that uses go
as a build dependency.
see this comment for more potentially broken bottles https://github.com/Homebrew/homebrew-core/issues/132852#issuecomment-1579977482
I definitely had issues with these formulas:
but, there could have been others. It's not that I would like you to fix a specific formula. It's that you most likely have many broken bottles that need a rebuild.
I guess you could come up with a way to find bottles that are:
readelf -l
Can just someone confirm that brew update && brew reinstall ssdepp
fixes it before I start rebottling stuff?
Note: we probably won't rebottle everything, I'll go through the lists above, for anything else users will have to open an issue or post here.
Sure, I'll test out the new bottle on Monday.
I could always solve the problem building from source. This ticket was just to give the project and other users a heads up.
@iMichka I installed ssdeep
and it does not segfault as the OP describes with ssdeep -V
.
==> Fetching ssdeep
==> Downloading https://ghcr.io/v2/homebrew/core/ssdeep/blobs/sha256:d62ce2005fd901e4a363b3f6592dee0388e9114d323a058499d16e8dba9c4d38
######################################################################################################################################### 100.0%
==> Reinstalling ssdeep
==> Installing ssdeep
==> Pouring ssdeep--2.14.1.x86_64_linux.bottle.1.tar.gz
🍺 /home/linuxbrew/.linuxbrew/Cellar/ssdeep/2.14.1: 16 files, 217.2KB
==> Running `brew cleanup ssdeep`...
$ ssdeep -V
2.14.1
Yes, it works from the bottle.
I've launched a couple of rebottles for formulas that were listed above and where the rebottling won't erase any old bottle (for previous macOS versions). In those cases, there is no downside to rebottling. Then, we can confirm whether the issues are all fixed, and decide how to proceed next.
I've launched: act docker docker-compose fzf gawk gh go-task k6 k9s pandoc xz yq
Once this is all done (I'd say in a few hours, but you can check progress there: https://github.com/Homebrew/homebrew-core/actions/workflows/dispatch-rebottle.yml) please reinstall, test, and report success or failure (if you were seeing the bug before).
:x: @fxcoudert bottle request for gh failed.
:x: @fxcoudert bottle request for k9s failed.
@fxcoudert I've tried a few of these (act
, k6
, gh
, yq
) and they still segfault. Looking at the GH Actions, it appears they depend on the Homebrew go
package which is affected on my system. Could an order of operation be affecting the built bottles?
I don't know enough about how go executables are built & linked to be able to answer that. go is being rebuilt as part of this PR https://github.com/Homebrew/homebrew-core/pull/165116 so we'll know soon.
@pdelre perhaps you could brew install -s golang
first.
@redspot Yes, that's how I resolve the builds locally.
the root cause is with the CGO_ENABLED for go build, we should turn it all for all affected formulae.
see https://github.com/grafana/k6/blob/master/release%20notes/v0.26.0.md?plain=1#L127 (for k6 for example)
:x: @fxcoudert bottle request for go-task failed.
The problem is (or was) specific to the RHEL kernel which is why no maintainer was able to reproduce the issue. Ubuntu does work fine, as evidenced by it being the platform we use for CI. The issue also cannot be reproduced on our systems under Docker, even on a RHEL/CentOS image.
This bug isn't new - it's been around for years. The patchelf.rb
update in 2022 wasn't anything to do with fixing RHEL. If anything, it probably made the problem worse for RHEL.
I'll look into this but it might take a few days to get back to you as I need to set up a special dev environment just to test this.
In WSL Ubuntu this is pretty wide spread from packages built with go
Is this WSL1 or WSL2? Note that we do not support WSL1 because of bugs on WSL's side that won't be fixed as it's not updated much anymore. If's WSL2: that's useful information as that might be easier for me to test.
the root cause is with the CGO_ENABLED for go build
This disables glibc entirely FWIW. Upstreams often use it for Alpine support but we don't support Alpine.
the root cause is with the CGO_ENABLED for go build
This disables glibc entirely FWIW. Upstreams often use it for Alpine support but we don't support Alpine.
that is true, I wonder if we should just disable for the linux build to ease the installation for the linux world.
@Bo98
Is this WSL1 or WSL2?
WSL2 Ubuntu. I am able to reproduce under my default Ubuntu distro and a freshly created one. I was able able to reproduce in a Ubuntu docker image (running WSL2 docker distro).
the root cause is with the CGO_ENABLED for go build
I'm outside my area of expertise here but if it was CGO_ENABLED
, wouldn't brew install -s
also result in a failing binary? If so, that is not the case for me.
WSL2 Ubuntu. I am able to reproduce under my default Ubuntu distro and a freshly created one. I was able able to reproduce in a Ubuntu docker image (running WSL2 docker distro).
Yeah Docker just uses the host kernel so if it's under WSL2 then that makes sense. I'll try WSL2 as that's an easier setup for me and will make this significantly easier to fix if I can reproduce the issue there.
I can't reproduce the issue under this setup:
> wsl.exe --version
WSL version: 2.1.4.0
Kernel version: 5.15.146.1-2
WSLg version: 1.0.60
MSRDC version: 1.2.5105
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.22631.3155
$ brew config
HOMEBREW_VERSION: 4.2.11
ORIGIN: https://github.com/Homebrew/brew
HEAD: d7d4c8266210c024b93a450a7d357cec0b46a1bb
Last commit: 2 days ago
Core tap JSON: 05 Mar 23:13 UTC
HOMEBREW_PREFIX: /home/linuxbrew/.linuxbrew
HOMEBREW_CASK_OPTS: []
HOMEBREW_DISPLAY: :0
HOMEBREW_MAKE_JOBS: 12
Homebrew Ruby: 3.1.4 => /home/linuxbrew/.linuxbrew/Homebrew/Library/Homebrew/vendor/portable-ruby/3.1.4/bin/ruby
CPU: dodeca-core 64-bit unknown_0x6_0xa5
Clang: N/A
Git: 2.34.1 => /bin/git
Curl: 7.81.0 => /bin/curl
Kernel: Linux 5.15.146.1-microsoft-standard-WSL2 x86_64 GNU/Linux
OS: Ubuntu 22.04.4 LTS (jammy)
WSL: 2 (Microsoft Store)
Host glibc: 2.35
/usr/bin/gcc: 11.4.0
/usr/bin/ruby: N/A
glibc: N/A
gcc@11: N/A
gcc: N/A
xorg: N/A
$ act --version
act version 0.2.60
$ gh version
gh version 2.45.0 (2024-03-04)
https://github.com/cli/cli/releases/tag/v2.45.0
$ curl -o test.zip -sL https://github.com/Homebrew/install/archive/refs/heads/master.zip
$ unzip test.zip
Archive: test.zip
aceed88a4a062e2b41dc40a7428c71309fce14c9
creating: install-master/
creating: install-master/.github/
inflating: install-master/.github/ISSUE_TEMPLATE.md
creating: install-master/.github/ISSUE_TEMPLATE/
inflating: install-master/.github/ISSUE_TEMPLATE/bug.md
inflating: install-master/.github/ISSUE_TEMPLATE/config.yml
inflating: install-master/.github/dependabot.yml
creating: install-master/.github/workflows/
inflating: install-master/.github/workflows/tests.yml
inflating: install-master/.github/workflows/triage-issues.yml
inflating: install-master/LICENSE.txt
inflating: install-master/README.md
inflating: install-master/install.sh
inflating: install-master/uninstall.sh
$ pkg-config --cflags --libs bzip2
-I/home/linuxbrew/.linuxbrew/opt/bzip2/include -L/home/linuxbrew/.linuxbrew/opt/bzip2/lib -lbz2
$ k6 --version
k6 v0.49.0 (go1.22.0, linux/amd64)
Hmm...there is a major kernel (5.x vs 4.x) difference depending on how WSL2 is installed (more).
I will eventually try and upgrade to the latest kernel but want to first check if the maintainers would like me to test any fixes on the 4.x kernel as IDK if it's still generally available.
>wsl.exe --version
Invalid command line option: --version
>wsl.exe --status
Default Distribution: Ubuntu
Default Version: 2
Windows Subsystem for Linux was last updated on Mon, 6/8/2020
The Windows Subsystem for Linux kernel can be manually updated with 'wsl --update', but automatic updates cannot occur due to your system settings.
To receive automatic kernel updates, please enable the Windows Update setting: 'Receive updates for other Microsoft products when you update Windows'.
For more information please visit https://aka.ms/wsl2kernel.
Kernel version: 4.19.104
$ brew config
HOMEBREW_VERSION: 4.2.11
ORIGIN: https://github.com/Homebrew/brew
HEAD: d7d4c8266210c024b93a450a7d357cec0b46a1bb
Last commit: 2 days ago
Core tap JSON: 05 Mar 19:23 UTC
HOMEBREW_PREFIX: /home/linuxbrew/.linuxbrew
HOMEBREW_BAT_THEME: ansi
HOMEBREW_CASK_OPTS: []
HOMEBREW_MAKE_JOBS: 8
Homebrew Ruby: 3.1.4 => /home/linuxbrew/.linuxbrew/Homebrew/Library/Homebrew/vendor/portable-ruby/3.1.4/bin/ruby
CPU: octa-core 64-bit zen
Clang: N/A
Git: 2.43.0 => /home/linuxbrew/.linuxbrew/bin/git
Curl: 7.81.0 => /bin/curl
Kernel: Linux 4.19.104-microsoft-standard x86_64 GNU/Linux
OS: Ubuntu 22.04.4 LTS (jammy)
WSL: 2
Host glibc: 2.35
/usr/bin/gcc: 11.4.0
/usr/bin/ruby: N/A
glibc: 2.35_1
gcc@11: N/A
gcc: 13.2.0
xorg: N/A
That'll indeed be the key difference then. Things work as expected on a modern kernel (we have CI on 6.5 currently, but we did test 5.15 before fine), so I guess we have some compatibility issues with 4.x that I can try look into.
RHEL historically has probably one of the slowest lifecycles (6 years between RHEL 7 and 8), which is probably why it's always been seen as a "RHEL-specific" issue as most other distros switched to 5.x years ago. WSL did too in October 2020 (well prior to our move to a newer glibc - we were still using Ubuntu 16.04 at this point), but it seems you're stuck on a June/August(?) 2020 version. I'm guessing RHEL 9 has similarly improved things.
I'll try set up a VM with an old kernel and see what I can do.
I found these additional packages that segfault:
[1275831.645595] 16586 (pcretest): Uhuuh, elf segment at 0000000000401000 requested but the memory is mapped already
[1275847.669209] 16642 (m4): Uhuuh, elf segment at 0000000000401000 requested but the memory is mapped already
[1275858.270300] 16692 (gdbmtool): Uhuuh, elf segment at 0000000000401000 requested but the memory is mapped already
[1275875.685829] 16749 (source-highligh): Uhuuh, elf segment at 0000000000402000 requested but the memory is mapped already
$ uname -rv
4.18.0-513.11.1.el8_9.x86_64 #1 SMP Thu Dec 7 03:06:13 EST 2023
$ cat /etc/os-release
NAME="Red Hat Enterprise Linux"
VERSION="8.9 (Ootpa)"
ID="rhel"
ID_LIKE="fedora"
VERSION_ID="8.9"
PLATFORM_ID="platform:el8"
PRETTY_NAME="Red Hat Enterprise Linux 8.9 (Ootpa)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:redhat:enterprise_linux:8::baseos"
HOME_URL="https://www.redhat.com/"
DOCUMENTATION_URL="https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Red Hat Enterprise Linux 8"
REDHAT_BUGZILLA_PRODUCT_VERSION=8.9
REDHAT_SUPPORT_PRODUCT="Red Hat Enterprise Linux"
REDHAT_SUPPORT_PRODUCT_VERSION="8.9"
My work requires RHEL.
@Bo98 @pdelre Any updates?
How can I help?
@redspot
Any updates?
if there was an update it would be posted here, that's how it works.
How can I help?
Take one failure, for example the m4
one, and debug it. It should fail with brew install m4
and work with brew install -s m4
(build from source). What is the difference in the ELF sections, and what is the section that is triggering this error message:
[1275847.669209] 16642 (m4): Uhuuh, elf segment at 0000000000401000 requested but the memory is mapped already
Glad that I could help.
By the way, I used the readelf
/ grep
technique that I initially posted to this issue to find the additional packages.
I can repro this issue on latest patchelf.rb (1.5.0) on my aarch64 centos 7.2 setup.
brew install --build-bottle xz # This will build from source, and no patchelf will be called
./bin/xz # works
brew bottle xz # this will call the patchelf
./bin/xz # segmentation fault
I manually patched Library/Homebrew/os/linux/elf.rb
, and replace the patchelf library with system patchelf:
def save_using_patchelf_rb(new_interpreter, new_rpath)
patcher = patchelf_patcher
# patcher.interpreter = new_interpreter if new_interpreter.present?
patch_interpreter_cmd = "patchelf --set-interpreter #{new_interpreter} #{patcher.in_file}"
puts patch_interpreter_cmd if new_interpreter.present?
system patch_interpreter_cmd if new_interpreter.present?
# patcher.rpath = new_rpath if new_rpath.present?
patch_rpath_cmd = "patchelf --set-rpath #{new_rpath} #{patcher.in_file}"
puts patch_rpath_cmd if new_rpath.present?
system patch_rpath_cmd if new_rpath.present?
# patcher.save(patchelf_compatible: true)
end
The reinstall xz and bottle it, the xz still works.
Hi, can you try the following patch:
diff --git a/Library/Homebrew/vendor/bundle/ruby/3.1.0/gems/patchelf-1.5.0/lib/patchelf/alt_saver.rb b/Library/Homebrew/vendor/bundle/ruby/3.1.0/gems/patchelf-1.5.0/lib/patchelf/alt_saver.rb
index 7937d14e6e..d7caf39e54 100644
--- a/Library/Homebrew/vendor/bundle/ruby/3.1.0/gems/patchelf-1.5.0/lib/patchelf/alt_saver.rb
+++ b/Library/Homebrew/vendor/bundle/ruby/3.1.0/gems/patchelf-1.5.0/lib/patchelf/alt_saver.rb
@@ -561,11 +561,12 @@ module PatchELF
if needed_space > start_offset
needed_space += seg_num_bytes # new load segment is required
- needed_pages = Helper.alignup(needed_space - start_offset, page_size) / page_size
+ extra_bytes = needed_space - start_offset
+ needed_pages = Helper.alignup(extra_bytes, page_size) / page_size
Logger.debug "needed pages is #{needed_pages}"
raise PatchError, 'virtual address space underrun' if needed_pages * page_size > first_page
- shift_file(needed_pages, start_offset)
+ shift_file(needed_pages, start_offset, extra_bytes)
first_page -= needed_pages * page_size
start_offset += needed_pages * page_size
@@ -776,7 +777,7 @@ module PatchELF
end
# rubocop:enable Metrics/PerceivedComplexity
- def shift_file(extra_pages, start_offset)
+ def shift_file(extra_pages, start_offset, extra_bytes)
raise PatchError, "start_offset(#{start_offset}) < ehdr.num_bytes" if start_offset < ehdr.num_bytes
oldsz = @buffer.size
@@ -799,8 +800,8 @@ module PatchELF
p_offset: split_phdr.p_offset - split_shift - shift,
p_vaddr: split_phdr.p_vaddr - split_shift - shift,
p_paddr: split_phdr.p_paddr - split_shift - shift,
- p_filesz: split_shift + shift,
- p_memsz: split_shift + shift,
+ p_filesz: split_shift + extra_bytes,
+ p_memsz: split_shift + extra_bytes,
p_flags: ELFTools::Constants::PF_R | ELFTools::Constants::PF_W,
p_align: page_size
)
It seems to fix things for me on a x86_64 CentOS 8 machine.
@Bo98 That patch works on my WSL2 Ubuntu, Kernel 4.
Kernel: Linux 4.19.104-microsoft-standard x86_64 GNU/Linux
OS: Ubuntu 22.04.4 LTS (jammy)
WSL: 2
Hi, can you try the following patch:
diff --git a/Library/Homebrew/vendor/bundle/ruby/3.1.0/gems/patchelf-1.5.0/lib/patchelf/alt_saver.rb b/Library/Homebrew/vendor/bundle/ruby/3.1.0/gems/patchelf-1.5.0/lib/patchelf/alt_saver.rb index 7937d14e6e..d7caf39e54 100644 --- a/Library/Homebrew/vendor/bundle/ruby/3.1.0/gems/patchelf-1.5.0/lib/patchelf/alt_saver.rb +++ b/Library/Homebrew/vendor/bundle/ruby/3.1.0/gems/patchelf-1.5.0/lib/patchelf/alt_saver.rb @@ -561,11 +561,12 @@ module PatchELF if needed_space > start_offset needed_space += seg_num_bytes # new load segment is required - needed_pages = Helper.alignup(needed_space - start_offset, page_size) / page_size + extra_bytes = needed_space - start_offset + needed_pages = Helper.alignup(extra_bytes, page_size) / page_size Logger.debug "needed pages is #{needed_pages}" raise PatchError, 'virtual address space underrun' if needed_pages * page_size > first_page - shift_file(needed_pages, start_offset) + shift_file(needed_pages, start_offset, extra_bytes) first_page -= needed_pages * page_size start_offset += needed_pages * page_size @@ -776,7 +777,7 @@ module PatchELF end # rubocop:enable Metrics/PerceivedComplexity - def shift_file(extra_pages, start_offset) + def shift_file(extra_pages, start_offset, extra_bytes) raise PatchError, "start_offset(#{start_offset}) < ehdr.num_bytes" if start_offset < ehdr.num_bytes oldsz = @buffer.size @@ -799,8 +800,8 @@ module PatchELF p_offset: split_phdr.p_offset - split_shift - shift, p_vaddr: split_phdr.p_vaddr - split_shift - shift, p_paddr: split_phdr.p_paddr - split_shift - shift, - p_filesz: split_shift + shift, - p_memsz: split_shift + shift, + p_filesz: split_shift + extra_bytes, + p_memsz: split_shift + extra_bytes, p_flags: ELFTools::Constants::PF_R | ELFTools::Constants::PF_W, p_align: page_size )
It seems to fix things for me on a x86_64 CentOS 8 machine.
This works on my aarch64, CentOS 7, linux 4.19.91.
@Bo98 Ok, I'll give that patch a try.
First, I'll make sure everything is up-to-date:
$ brew update
==> Updating Homebrew...
Already up-to-date.
$ brew upgrade
==> Auto-updating Homebrew...
Adjust how often this is run with HOMEBREW_AUTO_UPDATE_SECS or disable with
HOMEBREW_NO_AUTO_UPDATE. Hide these hints with HOMEBREW_NO_ENV_HINTS (see `man brew`).
$ brew doctor
Your system is ready to brew.
$ brew config
HOMEBREW_VERSION: 4.2.15-4-g966f819
ORIGIN: https://github.com/Homebrew/brew
HEAD: 966f819deb81796a1b9ea91abc65ab433c70362b
Last commit: 2 hours ago
Core tap HEAD: f74275618b8a99822357df93e75e86934b2620df
Core tap last commit: 3 minutes ago
Core tap JSON: 25 Mar 13:39 UTC
HOMEBREW_PREFIX: /home/linuxbrew/.linuxbrew
HOMEBREW_CASK_OPTS: []
HOMEBREW_DISPLAY: :0
HOMEBREW_EDITOR: vim
HOMEBREW_GITHUB_API_TOKEN: set
HOMEBREW_MAKE_JOBS: 8
HOMEBREW_SORBET_RUNTIME: set
SUDO_ASKPASS: /home/wmartin45/bin/askpass-kdewallet
Homebrew Ruby: 3.1.4 => /home/linuxbrew/.linuxbrew/Homebrew/Library/Homebrew/vendor/portable-ruby/3.1.4/bin/ruby
CPU: octa-core 64-bit skylake
Clang: 17.0.6
Git: 2.44.0 => /home/linuxbrew/.linuxbrew/bin/git
Curl: 7.61.1 => /bin/curl
Kernel: Linux 4.18.0-513.18.1.el8_9.x86_64 x86_64 GNU/Linux
OS: Red Hat Enterprise Linux release 8.9 (Ootpa)
Host glibc: 2.28
/usr/bin/gcc: 8.5.0
/usr/bin/ruby: N/A
glibc: 2.35_1
gcc@11: N/A
gcc: 13.2.0
xorg: N/A
$ cd $(brew --repo) && pwd
/home/linuxbrew/.linuxbrew/Homebrew
$ git apply --check patchelf.patch && git apply --summary patchelf.patch
$ # no output
So, it seems like the patch is already applied upstream.
Next, I'll try the steps suggested by @Shaloc :
$ brew uninstall --ignore-dependencies xz
Uninstalling /home/linuxbrew/.linuxbrew/Cellar/xz/5.6.1... (167 files, 2.8MB)
$ brew install --build-bottle xz
==> Auto-updating Homebrew...
Adjust how often this is run with HOMEBREW_AUTO_UPDATE_SECS or disable with
HOMEBREW_NO_AUTO_UPDATE. Hide these hints with HOMEBREW_NO_ENV_HINTS (see `man brew`).
==> Fetching xz
==> Downloading https://raw.githubusercontent.com/Homebrew/homebrew-core/14af31c6a3799ffe63a6cd74c6f738d48f549ef4/Formula/x/xz.rb
######################################################################################################################################### 100.0%
==> Downloading https://github.com/tukaani-project/xz/releases/download/v5.6.1/xz-5.6.1.tar.gz
==> Downloading from https://objects.githubusercontent.com/github-production-release-asset-2e65be/553665726/20b30ac5-c91c-4dc7-85a1-2b41dd49d6cb
######################################################################################################################################### 100.0%
==> ./configure --disable-silent-rules --disable-nls
==> make check
==> make install
==> Not running 'post_install' as we're building a bottle
You can run it manually using:
brew postinstall xz
🍺 /home/linuxbrew/.linuxbrew/Cellar/xz/5.6.1: 167 files, 2.7MB, built in 29 seconds
==> Running `brew cleanup xz`...
Disable this behaviour by setting HOMEBREW_NO_INSTALL_CLEANUP.
Hide these hints with HOMEBREW_NO_ENV_HINTS (see `man brew`).
$ brew postinstall xz
==> Postinstalling xz
Warning: xz: no `post_install` method was defined in the formula!
Let's check xz
before bottling:
$ readlink -f $(brew --prefix)/opt/xz/bin/xz
/home/linuxbrew/.linuxbrew/Cellar/xz/5.6.1/bin/xz
$ /home/linuxbrew/.linuxbrew/Cellar/xz/5.6.1/bin/xz --version # before brew bottle
xz (XZ Utils) 5.6.1
liblzma 5.6.1
No segfault. Now, we try bottling:
$ brew bottle xz
==> Determining xz bottle rebuild...
==> Bottling xz--5.6.1.x86_64_linux.bottle.1.tar.gz...
./xz--5.6.1.x86_64_linux.bottle.1.tar.gz
bottle do
rebuild 1
sha256 cellar: :any_skip_relocation, x86_64_linux: "e519149ba6e96fc972118e41fcb49f3aabfa3b290c911fdf969044ac78ec78e8"
end
$ /home/linuxbrew/.linuxbrew/Cellar/xz/5.6.1/bin/xz --version # after brew bottle
xz (XZ Utils) 5.6.1
liblzma 5.6.1
Also no segfault.
And, finally let's check the virtual address maps from the ELF header:
$ readelf -l /home/linuxbrew/.linuxbrew/Cellar/xz/5.6.1/bin/xz \
| awk '/(\s0x[[:xdigit:]]{16}){3}/{print $3}'
0x0000000000000040
0x0000000000000000
0x0000000000000000
0x0000000000004000
0x000000000000f000
0x00000000000129a0
0x0000000000015230
0x0000000000015230
0x0000000000015db0
0x000000000001c000
0x000000000001c378
0x000000000001c398
0x000000000001c398
0x000000000001d000
0x000000000001e000
0x000000000001f000
0x000000000001f828
$ readelf -l /home/linuxbrew/.linuxbrew/Cellar/xz/5.6.1/bin/xz \
| awk '/(\s0x[[:xdigit:]]{16}){3}/{print $3}' \
| cut -c 12-
0000040
0000000
0000000
0004000
000f000
00129a0
0015230
0015230
0015db0
001c000
001c378
001c398
001c398
001d000
001e000
001f000
001f828
No segments match virtual address 0x400000-0x4fffff
.
and, here's some kernel info:
$ dnf info kernel-core-4.18.0-513.18.1.el8_9
Not root, Subscription Management repositories not updated
Red Hat CodeReady Linux Builder for RHEL 8 x86_64 (RPMs) 165 kB/s | 4.5 kB 00:00
Installed Packages
Name : kernel-core
Version : 4.18.0
Release : 513.18.1.el8_9
Architecture : x86_64
Size : 71 M
Source : kernel-4.18.0-513.18.1.el8_9.src.rpm
Repository : @System
From repo : rhel-8-for-x86_64-baseos-rpms
Summary : The Linux kernel
URL : http://www.kernel.org/
License : GPLv2 and Redistributable, no modification permitted
Description : The kernel package contains the Linux kernel (vmlinuz), the core of any
: Linux operating system. The kernel handles the basic functions
: of the operating system: memory allocation, process allocation, device
: input and output, etc.
@Bo98 Thank you for your patch solution as it's continued to work through multiple upgrades (including xz
😬)!
It appears an upstream contribution must be made to https://github.com/david942j/patchelf.rb and that you were the author of the NixOS alt_saver.rb
bugfixes port the Ruby library. Is there anything you could use assistance with so the solution is available in the Homebrew mainline?
Yes, I will be getting things moving this weekend. There was a patch for a rustfmt
-specific issue that I was preparing as well.
the mingw-w64
bottle also segfaults. while trying to build mingw-w64
from source, bottle m4
also segfaulted.
$ brew info mingw-w64
==> mingw-w64: stable 11.0.1 (bottled)
Minimalist GNU for Windows and GCC cross-compilers
https://sourceforge.net/projects/mingw-w64/
Not installed
From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/m/mingw-w64.rb
License: ZPL-2.1
==> Dependencies
Build: texinfo ✘
Required: gmp ✔, isl ✔, libmpc ✔, mpfr ✔, gcc ✔, glibc ✔
==> Analytics
install: 3,952 (30 days), 12,579 (90 days), 67,741 (365 days)
install-on-request: 1,770 (30 days), 6,139 (90 days), 29,420 (365 days)
build-error: 71 (30 days)
$ brew install mingw-w64
==> Auto-updating Homebrew...
Adjust how often this is run with HOMEBREW_AUTO_UPDATE_SECS or disable with
HOMEBREW_NO_AUTO_UPDATE. Hide these hints with HOMEBREW_NO_ENV_HINTS (see `man brew`).
==> Downloading https://ghcr.io/v2/homebrew/core/mingw-w64/manifests/11.0.1
######################################################################################################################################### 100.0%
==> Fetching mingw-w64
==> Downloading https://ghcr.io/v2/homebrew/core/mingw-w64/blobs/sha256:ed0e3ad639d4c7754beb5943b5b5dc0e806005a14c2aee5230cd5d114dc4f9a8
######################################################################################################################################### 100.0%
==> Pouring mingw-w64--11.0.1.x86_64_linux.bottle.tar.gz
🍺 /home/linuxbrew/.linuxbrew/Cellar/mingw-w64/11.0.1: 7,870 files, 1GB
==> Running `brew cleanup mingw-w64`...
Disable this behaviour by setting HOMEBREW_NO_INSTALL_CLEANUP.
Hide these hints with HOMEBREW_NO_ENV_HINTS (see `man brew`).
[551043.099975] 259846 (i686-w64-mingw3): Uhuuh, elf segment at 0000000000401000 requested but the memory is mapped already
[551474.392061] 298031 (m4): Uhuuh, elf segment at 0000000000401000 requested but the memory is mapped already
Is there a way to trigger patchelf.rb
on a precompiled bottle, like brew postinstall
? @Shaloc @pdelre @Bo98
I just migrated a Centos 8 Stream to Rocky Linux, and encountered the Segmentation fault
problem.
...another problem is that I had not touched brew
for a while, so knowing when the problem hit is an issue, but I removed brew entirely and re-installed, and got the same problem.
While debugging I started with the rockylinux:8
docker image to try and replicate, but was not able to replicate, akà everything works.
But I'm dropping this here in case it can help the debugging and/or reproducing efforts.
docker run \ # ...or nerdctl
-ti \
--rm \
--platform amd64 \
-v $HOME/.docker/certs.d:/etc/pki/ca-trust/source/anchors \ # My env requires a trust CA, remove at will
rockylinux:8 bash -c '
update-ca-trust # My env requires a trust CA, remove at will
dnf -y install git procps sudo
dnf -y groupinstall "Development Tools"
echo "brewtest ALL=(ALL) NOPASSWD: ALL" > /etc/sudoers.d/brewtest
useradd -m brewtest
sudo su - brewtest -c /bin/bash -c "NONINTERACTIVE=1 $(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
(echo; echo "eval \"$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)\"") >> /home/brewtest/.bashrc
sudo su - brewtest -c /bin/bash -c "brew install gcc"
sudo su - brewtest -c /bin/bash -c "brew install gh"
sudo su - brewtest -c /bin/bash -c "gh"
'
Now, in my server env the gh
command fails, but in this docker env it works.
If possible I'll update if I find a way to reproduce the error.
Bump to make sure this is still alive
After recently upgrading brew
, gcc-14.1.0
crashes.
[627937.886892] 590828 (collect2): Uhuuh, elf segment at 0000000000401000 requested but the memory is mapped already
recompiling gcc
from source is rather time-consuming. But, I guess that's the only fix for now.
After recently upgrading
brew
,gcc-14.1.0
crashes.[627937.886892] 590828 (collect2): Uhuuh, elf segment at 0000000000401000 requested but the memory is mapped already
recompiling
gcc
from source is rather time-consuming. But, I guess that's the only fix for now.
==> make
Last 15 lines from ~/.cache/Homebrew/Logs/gcc/02.make:
yes
configure: updating cache ./config.cache
configure: creating ./config.status
config.status: creating Makefile
config.status: creating testsuite/Makefile
config.status: creating config.h
config.status: executing default commands
config.status: creating Makefile
config.status: creating testsuite/Makefile
config.status: creating config.h
config.status: executing default commands
make[2]: Leaving directory '/tmp/gcc-20240514-616152-651wxv/gcc-14.1.0/build'
make[1]: *** [Makefile:25452: stage1-bubble] Error 2
make[1]: Leaving directory '/tmp/gcc-20240514-616152-651wxv/gcc-14.1.0/build'
make: *** [Makefile:1100: all] Error 2
It seems to effect the treesit support (e.g. rust-ts-mode) of emacs.
$ emacs main.rs
Fatal error 11: Segmentation fault
zsh: segmentation fault emacs main.rs
SEGV $
brew gist-logs <formula>
link ORbrew config
ANDbrew doctor
outputVerification
brew doctor
output" saysYour system is ready to brew.
and am still able to reproduce my issue.brew update
and am still able to reproduce my issue.brew doctor
and that did not fix my problem.What were you trying to do (and why)?
I was attempting to use several formulae installed via
brew
.There are several related issues:
137991 related to old
patchelf.rb
bug132852 bottles crashing on Centos
116841 bottles crashing on RHEL
What happened (include all command output)?
Note the segment that causes the problem,
0x0000000000401000
Now, take a look at the on-disk segments:
Note the segment
0x00000000004012ae
Also, of interest, when run using
brew
's interpreter, programs seem to work:Here is the results when built from source:
What did you expect to happen?
I expect the upstream pre-built bottles to not have lingering issues with
patchelf.rb
.Now, the issues with
patchelf.rb
have been fixed, and maybe those Centos/RHEL related issues as well.It's that the bottles still have the problem.
Step-by-step reproduction instructions (by running
brew
commands)As mentioned in this comment: https://github.com/Homebrew/homebrew-core/issues/132852#issuecomment-1579977482
Some formulas work:
Some formulas fail:
Note the kernel reporting the same segment,
0x0000000000401000
, and readelf showing that segment. And, it strangely works when run withbrew
's interpreter.when building from source:
It also seems reliable to detect the bad packages by looking for a segment that matches the regex
0x0000000000401...
.