-
Notifications
You must be signed in to change notification settings - Fork 183
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
hangs on Debian ppc64el #415
Comments
Thanks for the report, that's intriguing. If you wish to debug this further, I'd suggest trying to get a Ruby backtrace from these sub processes. A cheap way to do this is to spawn a thread that periodically dump the main thread backtrace: Thread.new { loop { File.write("/tmp/ruby-#{$$}.log", Thread.main.backtrace.join("\n")); sleep 1 } } If you inject this right after the I'll see if I find time to do this myself, but no promises. Also it's quite likely that you just uncovered a bug in Ruby. |
I tried a slight variation, to be able to see progress from each process: Thread.new { loop { File.write("/tmp/ruby-#{$$}.log", "================\n" + Thread.main.backtrace.join("\n") + "\n", mode: "a"); sleep 1 } } But I think looping did't work, because each file has only a single backtrace. I think the processes get stuck right after the
I also tried running that one test under
|
something else that feels weird is that temporary directories left over from those tests look quite big:
I don't know if this data point is useful, as I didn't study the bootsnap internals yet, I'm just trying to handle the fallout from a new ruby version. :) But when I run the full test suite on my local machine (x86_64), all of those temporary directories are a few hundred KB. |
Ok, so most workers are stuck on One however is stuck on As a next step I'd suggest to add some print in there to see which file it's trying to compile, if it's consistent that should allow to reduce the reproduction step to just
Yes, what's way too much, that's another indication that it might be a bug in |
When running the bootsnap test suite on the Debian ppc64el architecture, some tests will cause bootsnap to hang forever. One can reproduce this with, for example,
Bootsnap::CLITest#test_precompile_gemfile
. I can reproduce this with both ruby3.0 and ruby3.1, but only on ppc64el. No other official Debian architecture is affected.Steps to reproduce
qemu-system-ppc64le -machine pseries -cpu power9 -m 4G -smp 2 -drive file=image.qcow2 -device e1000,netdev=net -netdev user,id=net,hostfwd=tcp::2222-:22 -kernel kernel -initrd initrd -nographic -append "root=LABEL=rootfs console=hvc0"
apt-get update && apt-get install -qy ruby-dev git
git clone https://github.com/Shopify/bootsnap.git
cd bootsnap
bundle install
bundle exec rake TESTOPTS='-v -ntest_precompile_gemfile'
(ruby3.0 is currently the default. to reproduce with ruby3,1, install
ruby3.1-dev
, and usebundle3.1
instead of justbundle
in the command lines above).the output looks like this:
(and stays there forever, until I interrupt with a control-c; but even then there are multiple processed left behind that I need to kill manually)
Bootsnap version: from git
Ruby version: 3.0 or 3.1
The text was updated successfully, but these errors were encountered: