Writing a link_to method in helper and a URL with request parameter under certain "if else" statement crashes Rails sever with Abort trap: 6

[y4m4p]

This is a very very specific bug and should not be much of a problem when using Rails normally, but I have encountered this problem somehow, and narrowed down the problem a bit, so I will give some examples and the outcome of it. Hope this helps fix some weird bugs out there maybe.

Steps to reproduce

In any rails application,

1. create any helper method that satisfies the following conditions under app/helpers.

• Write a condition with if true ... else ... OR if false ... else ...
• Write the process under the statement that will never be used. For example, if you write it with if true then you must write your process under the else statement and vice versa.
• Write a path using the link_to helper and a url_helper which contains a request parameter.

For example I will create a helper method like below.

# app/helpers/application_helper.rb

def helper_method
  if true
  else
    link_to 'somewhere', web_pages_some_view_path(foo: 'false')
  end
end

OR you can write it like this.

def helper_method
  if false
    link_to 'somewhere', web_pages_some_view_path(foo: 'true')
  else
  end
end

2. use the helper method inside any view files under app/views/.... Create a controller and route it if necessary.
   For this example I will create some_view erb template and a WebPagesController, and route it accordingly.

# app/views/web_pages/some_view.html.erb

<%= helper_method %>

# app/controllers/web_pages_controller.rb

class WebPagesController < ApplicationController
  def some_view
  end
end

# app/config/routes.rb

get 'web_pages_some_view'

3. start your rails server.

4. Access the view.
   For this instance, localhost:3000/web_pages/some_view

Expected behavior

It should not crash, but instead, should render the process under either if or else depending on the true or false condition that you have specified.

Actual behavior

The server will crash with a log similar to the one below.

Started GET "/web_pages/some_view?foo=bar" for 127.0.0.1 at 2018-07-28 19:20:33 +0900
/Users/***/vendor/bundle/ruby/2.5.0/gems/bootsnap-1.3.0/lib/bootsnap/compile_cache/iseq.rb:12: [BUG] Segmentation fault at 0x0000000000000000
ruby 2.5.1p57 (2018-03-29 revision 63029) [x86_64-darwin14]

...(skip)...

[NOTE]
You may have encountered a bug in the Ruby interpreter or extension libraries.
Bug reports are welcome.
For details: http://www.ruby-lang.org/bugreport.html

[IMPORTANT]
Don't forget to include the Crash Report log file under
DiagnosticReports directory in bug reports.

Abort trap: 6

System configuration

Rails version: Rails 5.2.0

Ruby version: ruby 2.5.1p57 (2018-03-29 revision 63029) [x86_64-darwin14]

Side Note

This bug will not occur in the following conditions. So the following program will work correctly.

1. Write the true false condition statement in any variable like the following.

def helper_method
  condition = true (instance variable or Constants is OK too.)
  if condition
    link_to ...
  else 
    link_to ...
  end
end

2. Do not write the process under the statement that will never be used.

def helper_method
  if true
    link_to 'somewhere', web_pages_some_view_path(foo: 'true')
  else
    # link_to 'somewhere', web_pages_some_view_path(foo: 'false')  #<= comment out
  end
end

3. Do not give the url_helper with a request parameter.

def helper_method
  if true
    link_to 'somewhere', web_pages_some_view_path
  else
    link_to 'somewhere', web_pages_some_other_view_path
  end
end

4. Writing the method's process directly in the view template.

# app/view/web_pages/some_view.html.erb

<%=  if true
       link_to 'somewhere', web_pages_some_view_path(foo: 'true')
      else
        link_to 'somewhere', web_pages_some_view_path(foo: 'false')
      end %>

Status update

• 7/31/2018 21:00 JST
  It seems that when you start up the server (which loads the helper method), and this specific method is not commented out, it will crash the server when you try to render any views. Even if that view does not invoke the said method.
  On the other hand, if you write the helper method after you have started up your server(like you would normally when developing the application), it is possible to explore other pages, until you try to access the said method in a view, causing it to reload the helper, thus wiping the application.

[y-yagi]

Thanks for your report, but I can't reproduce your issue.
Can you create a reproduce application your issue?

[y4m4p]

@y-yagi Thank you for your reply.
I'll make a sample application, ASAP.

[y4m4p]

@y-yagi
I have created a reproduction application for this issue.
I'm sorry it took some time. Please follow the README for more instructions. Thank you for your time.

https://github.com/y4m4p/rails_issue_33460

[y4m4p]

I have updated some information about this issue. See Status update in the bottom of the ticket.

[sikachu]

@y4m4p what happen if you comment out "bootsnap" from your Gemfile? The backtrace you posted make it looks like it came from Bootsnap, which is not actually part of Rails but is in default Gemfile.

[y4m4p]

@sikachu
Commenting out "bootsnap" did the trick. It does not crash whenever the helper is there or not.
I should've done that myself... 🤦‍♂️ Thank you for your wise comment :)

Anyways, we have narrowed down that the problem lies within the "bootsnap" gem, so I should go create an issue over there as well, and closing this one since it's not a pure "rails" gem issue?

Or should I leave this issue as an Rails application issue, because seems like when you create a Rails application, it comes with and uses "bootsnap" gem in the first place?

Sorry about the confusion. I haven't caught up with how things work here..

[sikachu]

No problem at all. I'm glad that you've found out the source of the error.

What we usually do around here is to close this issue and open an issue on the underlying gem. Since I see that you already open an issue on Shopify/bootsnap, I'll close this issue. If people run into the same issue and search rails/rails they will still be able to find this and know that they have to follow through to Shopify/bootsnap.

Once that issue is fixed and released in Shopify/bootsnap, please feel free to come back and open up a PR to bump minimum version on the generate Gemfile as that'd be how we ensure people don't run into the issue once it's fix.

Thank you for your report!

[y4m4p]

Seems like the problem was not in the bootsnap gem, but in the ruby vm itself.
Will update stats if something happens.