incompatible with armv7l about bootsnap HOT 16 CLOSED

Confirmed today, bug still evident in Ruby 2.5.1
Ruby bugtracker updated

Environment:

ARMv7 Processor rev 4 (v7l), (RaspberryPi 3)
Linux raspberrypi 4.9.35-v7+ #1014 SMP Fri Jun 30 14:47:43 BST 2017 armv7l GNU/Linux
ruby 2.5.1p57 (2018-03-29 revision 63029) [armv7l-linux-eabihf]
bootsnap (1.3.0)
Rails 5.2.0

Rails adds bootsnap to a new app by default as of version 5.2.0
any call to rails (rails console, rails server, rails credentials:edit, etc) produces

bootsnap-1.3.0/lib/bootsnap/compile_cache/iseq.rb:18: [BUG] Bus Error at 0x55ae31f7

Temporary fix for Rails >= 5.2.0

edit config/boot.rb
comment out or remove the following line:

# config/boot.rb
require 'bootsnap/setup' # Speed up boot time by caching expensive operations.

from bootsnap.

Hello @mrohnstock, seeing as you're using ALARM, you should recognize me.

I wanted to drop a line and let everyone on this ticket know that this is not strictly an Arch Linux ARM issue, but indeed a problem in Ruby itself. I work for GitLab, building the various vendor packages. I have seen this failure on Raspbian, and a few others. We (GitLab) are following the issue and looking for a workaround at this time.

from bootsnap.

Is this still an issue? @WarheadsSE did you get any further?

from bootsnap.

Confirmed issue remains with Ruby 2.5.1

This is the dmesg after crash.

[ 3322.842162] Alignment trap: not handling instruction ed920b01 at [<006406f4>]
[ 3322.842177] Unhandled fault: alignment exception (0x001) at 0xb5ba70e3
[ 3322.842182] pgd = d81c8000
[ 3322.842186] [b5ba70e3] *pgd=5a4d9835, *pte=5530055f, *ppte=55300c7e

from bootsnap.

Funny, it looks like this error is actually in ruby code where it's trying to load the serialized binary.

from bootsnap.

It would be interesting to see if you can reproduce this in isolation by capturing the data passed into storage_to_output in iseq.rb and seeing if that predicably blows up in RubyVM::InstructionSequence.load_from_binary.

from bootsnap.

Hm, I don't know, if I've done it right, but I've captured the data of binary before it get's applied to load_from_binary to a file by modifing the code of iseq.rb in the following way:

      def self.storage_to_output(binary)
        File.write('/home/git/gitlab/demo.bin', binary)
        RubyVM::InstructionSequence.load_from_binary(binary)
      rescue RuntimeError => e

You can find the file here.

from bootsnap.

Well, it looks like it's valid, insofar as it starts with YARB and then specifies the architecture.

darmok:burke ⚬ > hexdump -Cn64 demo.bin
00000000  59 41 52 42 02 00 00 00  03 00 00 00 4b a6 00 00  |YARB........K...|
00000010  00 00 00 00 45 00 00 00  a2 00 00 00 34 01 00 00  |....E.......4...|
00000020  20 88 00 00 34 89 00 00  7b a1 00 00 61 72 6d 76  | ...4...{...armv|
00000030  37 6c 2d 6c 69 6e 75 78  2d 65 61 62 69 68 66 00  |7l-linux-eabihf.|
00000040
darmok:burke ⚬ > hexdump -Cn64 good.bin
00000000  59 41 52 42 02 00 00 00  03 00 00 00 ed 01 00 00  |YARB............|
00000010  00 00 00 00 01 00 00 00  02 00 00 00 05 00 00 00  |................|
00000020  5c 01 00 00 60 01 00 00  d9 01 00 00 78 38 36 5f  |\...`.......x86_|
00000030  36 34 2d 64 61 72 77 69  6e 31 36 00 2a 00 00 00  |64-darwin16.*...|
00000040

Maybe it's a ruby bug? 2.3.4 is pretty modern, but armv7l is a somewhat fringe architecture.

from bootsnap.

I've reported this on their bugtracker :)

from bootsnap.

I confirmed today that this bug still occurs: /usr/local/lib/ruby/gems/2.4.0/gems/bootsnap-1.1.7/lib/bootsnap/compile_cache/iseq.rb:18: [BUG] Bus Error at 0x1a1e7cf

Environment:

H3 SoC (armv7l), specifically NanoPI
Linux Lobohub 3.4.113-sun8i #18 SMP PREEMPT Thu Jun 15 02:16:06 CEST 2017 armv7l GNU/Linux
ruby 2.4.1p111 (2017-03-22 revision 58053) [armv7l-linux-eabihf]

from bootsnap.

I was helping a coworker debug issues around this earlier today. @fig's recommendation helped, but we also needed to disable spring using the DISABLE_SPRING=true env var. Just in case anyone else runs into this!

from bootsnap.

Is it still a problem in more recent rubies? Anyway, this is definitely not a bootsnap issue and is rather stale anyway, so I'm going to close.

from bootsnap.

It is funny, because at the Ruby bug-tracker they are thinking it is a bootsnap issue: https://bugs.ruby-lang.org/issues/14789

Also I wonder how much this efforts will help with the ARM issues: https://bugs.ruby-lang.org/issues/15903

from bootsnap.

I just installed bootsnap v1.4.4 and Rails 5.2.3 on a Ruby 2.6.3 Docker image and had no trouble setting up a simple Rails app!

# ruby --version
ruby 2.6.3p62 (2019-04-16 revision 67580) [arm-linux-eabihf]

from bootsnap.

@stanhu Thank you for checking in / your feedback, very helpful!

from bootsnap.

I ran into this when migrating an app to a Raspberry Pi 3. I'm running Rails 5.1.7 and Ruby 2.5.7.

Disabling bootsnap in production fixes the issue, which is a good enough solution for my humble personal project.

from bootsnap.