Fix issues preventing railsbench from running.

[maximecb]

There's a segfault in bundler preventing the required gems from installing.

# To install microjit
./configure cppflags=-DRUBY_DEBUG --prefix=$HOME/.rubies/ruby-microjit --with-opt-dir=$(brew --prefix openssl):$(brew --prefix readline):$(brew --prefix libyaml):$(brew --prefix gdbm)

https://github.com/Shopify/microjit-bench

[flavorjones]

OK, I've reproduced this error:

NoMethodError: undefined method `gsub' for 72:Integer
  /home/flavorjones/local/lib/ruby/3.1.0/bundler/cli.rb:836:in `remembered_negative_flag_deprecation'
  /home/flavorjones/local/lib/ruby/3.1.0/bundler/cli.rb:255:in `install'
  /home/flavorjones/local/lib/ruby/3.1.0/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
  /home/flavorjones/local/lib/ruby/3.1.0/bundler/vendor/thor/lib/thor/invocation.rb:127:in `invoke_command'
  /home/flavorjones/local/lib/ruby/3.1.0/bundler/vendor/thor/lib/thor.rb:392:in `dispatch'
  /home/flavorjones/local/lib/ruby/3.1.0/bundler/cli.rb:30:in `dispatch'
  /home/flavorjones/local/lib/ruby/3.1.0/bundler/vendor/thor/lib/thor/base.rb:485:in `start'
  /home/flavorjones/local/lib/ruby/3.1.0/bundler/cli.rb:24:in `start'
  /home/flavorjones/local/lib/ruby/gems/3.1.0/gems/bundler-2.3.0.dev/libexec/bundle:49:in `block in <top (required)>'
  /home/flavorjones/local/lib/ruby/3.1.0/bundler/friendly_errors.rb:130:in `with_friendly_errors'
  /home/flavorjones/local/lib/ruby/gems/3.1.0/gems/bundler-2.3.0.dev/libexec/bundle:37:in `<top (required)>'
  /home/flavorjones/.gem/ruby/3.1.0/bin/bundle:23:in `load'
  /home/flavorjones/.gem/ruby/3.1.0/bin/bundle:23:in `<main>'

running:

• ruby 3.1.0dev (2021-02-08T20:40:36Z microjit 54c9cb051e) [x86_64-linux]
• Bundler version 2.3.0.dev (2021-02-08 commit unknown)

[flavorjones]

@maximecb Is this the error you were seeing? It's not a segfault. If not, can you help me reproduce?

[flavorjones]

Ah - I see that this sometimes segfaults. Will keep going.

[flavorjones]

This error/segfault does not happen if I comment-out any one of the following lines from ujit_init_codegen:

• ujit_reg_op(BIN(nop), gen_nop, false);
• ujit_reg_op(BIN(getlocal_WC_0), gen_getlocal_wc0, false);
• ujit_reg_op(BIN(getinstancevariable), gen_getinstancevariable, false);
• ujit_reg_op(BIN(opt_send_without_block), gen_opt_send_without_block, true);

Conversely, the bug occurs if I comment out everything except those four calls.

My conclusion is that these four opcodes' generated code is interacting to cause this bug.

[maximecb]

I was trying to update bundler to fix the gsub error, and that's when I encountered the segfault (in the bundler update process).

Good idea to comment out opcodes. It's probably not an interaction per-se. It's just that uJIT stops compiling iseqs when it finds opodes it doesn't know, so commenting out some opcodes might lead to other instructions not getting compiled.

It's most likely not nop or getlocal, I think we can be fairly confident about those. That leaves getinstancevariable and opt_send_without_block.

If you uncomment this line it will print out the opcodes getting executed:
https://github.com/Shopify/ruby/blob/microjit/ujit_codegen.c#L199

[flavorjones]

When I uncomment those lines, here's the output from a run that ended with the exception:

...
getlocal_WC_0
opt_send_without_block
nop
getlocal_WC_0
opt_send_without_block
nop
getlocal_WC_0
opt_send_without_block
nop
getlocal_WC_0
opt_send_without_block
putself
opt_send_without_block
putself
opt_send_without_block
putself
nop
nop
compiling 0: putnil
compiling 1: setlocal_WC_0
compiling 3: getlocal_WC_0
compiling 5: branchif
--- ERROR REPORT TEMPLATE -------------------------------------------------------
# Error Report

## Questions

Please fill out answers to these questions, it'll help us figure out
why things are going wrong.

- **What did you do?**

  I ran the command `/home/flavorjones/.gem/ruby/3.1.0/bin/bundle install`

- **What did you expect to happen?**

  I expected Bundler to...

- **What happened instead?**

  Instead, what happened was...

- **Have you tried any solutions posted on similar issues in our issue tracker, stack overflow, or google?**

  I tried...

- **Have you read our issues document, https://github.com/rubygems/rubygems/blob/master/bundler/doc/contributing/ISSUES.md?**

  ...

## Backtrace

NoMethodError: undefined method `gsub' for 72:Integer
  /home/flavorjones/local/lib/ruby/3.1.0/bundler/cli.rb:836:in `remembered_negative_flag_deprecation'
  /home/flavorjones/local/lib/ruby/3.1.0/bundler/cli.rb:255:in `install'
  /home/flavorjones/local/lib/ruby/3.1.0/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
  /home/flavorjones/local/lib/ruby/3.1.0/bundler/vendor/thor/lib/thor/invocation.rb:127:in `invoke_command'
  /home/flavorjones/local/lib/ruby/3.1.0/bundler/vendor/thor/lib/thor.rb:392:in `dispatch'
  /home/flavorjones/local/lib/ruby/3.1.0/bundler/cli.rb:30:in `dispatch'
  /home/flavorjones/local/lib/ruby/3.1.0/bundler/vendor/thor/lib/thor/base.rb:485:in `start'
  /home/flavorjones/local/lib/ruby/3.1.0/bundler/cli.rb:24:in `start'
  /home/flavorjones/local/lib/ruby/gems/3.1.0/gems/bundler-2.3.0.dev/libexec/bundle:49:in `block in <top (required)>'
  /home/flavorjones/local/lib/ruby/3.1.0/bundler/friendly_errors.rb:130:in `with_friendly_errors'
  /home/flavorjones/local/lib/ruby/gems/3.1.0/gems/bundler-2.3.0.dev/libexec/bundle:37:in `<top (required)>'
  /home/flavorjones/.gem/ruby/3.1.0/bin/bundle:23:in `load'
  /home/flavorjones/.gem/ruby/3.1.0/bin/bundle:23:in `<main>'

and here's one that ends with a segfault:

...
getinstancevariable
getlocal_WC_0
opt_send_without_block
getinstancevariable
getinstancevariable
dup
branchif
leave
nop
getinstancevariable
getlocal_WC_0
opt_send_without_block
getinstancevariable
getinstancevariable
dup
branchif
leave
nop
getinstancevariable
getlocal_WC_0
opt_send_without_block
getinstancevariable
getinstancevariable
dup
branchif
leave
/home/flavorjones/local/lib/ruby/3.1.0/bundler/vendor/thor/lib/thor/parser/options.rb:50: [BUG] Segmentation fault at 0x000000000000000
0
ruby 3.1.0dev (2021-02-08T20:40:36Z microjit 54c9cb051e) [x86_64-linux]

-- Control frame information -----------------------------------------------
c:0019 p:0012 s:0133 e:000129 BLOCK  /home/flavorjones/local/lib/ruby/3.1.0/bundler/vendor/thor/lib/thor/parser/options.rb:50 [FINISH]
c:0018 p:---- s:0126 e:000125 CFUNC  :each
c:0017 p:0069 s:0122 e:000121 METHOD /home/flavorjones/local/lib/ruby/3.1.0/bundler/vendor/thor/lib/thor/parser/options.rb:49 [FINISH]
c:0016 p:---- s:0113 e:000112 CFUNC  :new
c:0015 p:0125 s:0105 e:000104 METHOD /home/flavorjones/local/lib/ruby/3.1.0/bundler/vendor/thor/lib/thor/base.rb:78
c:0014 p:0058 s:0089 E:000810 METHOD /home/flavorjones/local/lib/ruby/3.1.0/bundler/vendor/thor/lib/thor/invocation.rb:26
c:0013 p:0022 s:0081 e:000080 METHOD /home/flavorjones/local/lib/ruby/3.1.0/bundler/vendor/thor/lib/thor/shell.rb:45
c:0012 p:0008 s:0074 e:000073 METHOD /home/flavorjones/local/lib/ruby/3.1.0/bundler/cli.rb:55 [FINISH]
c:0011 p:---- s:0065 e:000064 CFUNC  :new
c:0010 p:0183 s:0058 e:000057 METHOD /home/flavorjones/local/lib/ruby/3.1.0/bundler/vendor/thor/lib/thor.rb:388
c:0009 p:0008 s:0045 e:000044 METHOD /home/flavorjones/local/lib/ruby/3.1.0/bundler/cli.rb:30
c:0008 p:0066 s:0040 e:000039 METHOD /home/flavorjones/local/lib/ruby/3.1.0/bundler/vendor/thor/lib/thor/base.rb:485
c:0007 p:0008 s:0033 e:000032 METHOD /home/flavorjones/local/lib/ruby/3.1.0/bundler/cli.rb:24
c:0006 p:0108 s:0028 e:000027 BLOCK  /home/flavorjones/local/lib/ruby/gems/3.1.0/gems/bundler-2.3.0.dev/libexec/bundle:49
c:0005 p:0014 s:0022 e:000021 METHOD /home/flavorjones/local/lib/ruby/3.1.0/bundler/friendly_errors.rb:130
c:0004 p:0160 s:0017 E:001f18 TOP    /home/flavorjones/local/lib/ruby/gems/3.1.0/gems/bundler-2.3.0.dev/libexec/bundle:37 [FINISH]
c:0003 p:---- s:0013 e:000012 CFUNC  :load
c:0002 p:0112 s:0008 E:001890 EVAL   /home/flavorjones/.gem/ruby/3.1.0/bin/bundle:23 [FINISH]
c:0001 p:0000 s:0003 E:000d40 (none) [FINISH]

[maximecb]

I'm guessing the exception is because bundler is expecting some method that's been deprecated in the bleeding edge Ruby. There's probably nothing we can do about that (except maybe update bundler or manually modify its code). We could try asking around if other people are having that problem.

Segfault in leave is a little strange :O

We have two codegen functions that might help, you can place some print_str(cb, "string constant"); statements inside gen_leave. There is also print_int(cb, int_operand) and print_ptr(cb, operand). Those will generate code that prints output without disrupting anything.

gen_leave:
https://github.com/Shopify/ruby/blob/microjit/ujit_codegen.c#L1405

For example, adding print_ptr(cb, REG_CFP) on this line:
https://github.com/Shopify/ruby/blob/microjit/ujit_codegen.c#L1431

Would print the current value of the REG_CFP pointer.

[flavorjones]

I don't think this is a Ruby deprecation, because it runs fine with --disable-ujit set.

I'm pattern matching based on my past experience, but this looks like it may be an object being freed, and then the slot getting re-used sometimes. So on occasion an unexpected object gets gsub called on it; other times it's a use-after-free segfault. I'd like to confirm this by running valgrind, but I'm also having problems running valgrind (see my slack message from this morning).

[maximecb]

I'm guessing valgrind doesn't like our executable memory allocation.

This is the code that allocates executable memory: https://github.com/Shopify/ruby/blob/microjit/ujit_asm.c#L127

You could try either removing the position hint (make first argument NULL), or changing some of the flags?

[flavorjones]

Passing NULL as the address does allow this to run a bit further under valgrind, but it then fails in a new way that I don't know how to fix:

compiling 0: nop
compiling 1: putnil
nop

vex: priv/guest_amd64_toIR.c:20628 (dis_ESC_NONE): Assertion `sz == 2 || sz == 4' failed.
vex storage: T total 1463532320 bytes allocated
vex storage: P total 512 bytes allocated

valgrind: the 'impossible' happened:
   LibVEX called failure_exit().

host stacktrace:
==65967==    at 0x58046FFA: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
==65967==    by 0x58047127: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
==65967==    by 0x58047390: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
==65967==    by 0x580473C0: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
==65967==    by 0x5805E3DA: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
==65967==    by 0x58140040: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
==65967==    by 0x581AC288: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
==65967==    by 0x581D4FD7: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
==65967==    by 0x581D5850: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
==65967==    by 0x5815B13A: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
==65967==    by 0x5813D916: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
==65967==    by 0x5813E20D: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
==65967==    by 0x58060E47: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
==65967==    by 0x580A68C5: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
==65967==    by 0x580F5FD4: ??? (in /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)

sched status:
  running_tid=1

Thread 1: status = VgTs_Runnable (lwpid 65967)
==65967==    at 0x8A78081: ???
==65967==    by 0x3: ???
client stack range: [0x1FFE802000 0x1FFF000FFF] client SP: 0x1FFEFFC070
valgrind stack range: [0x1002CB6000 0x1002DB5FFF] top usage: 16264 of 1048576

[maximecb]

Not sure what to do about this. Maybe valgrind can't cope with the generated code.

Maybe we should wait until Alan merges his GC PR. If we're lucky it might fix this issue. If not, we should probably look for a simpler failing test.